spark-steaming的exactly-once

spark实时计算中会存在数据丢失和数据重复计算的场景，

在receiver收到数据且经过driver的调度executor开始计算数据的时候若是driver忽然崩溃，则此时executor就会被杀掉，executor中的数据就会丢失，为了防止executor中的数据丢失，此时要经过WAL的方式让全部的数据经过例如hdfs的方式进行安全性容错处理，executor重启以后能够经过WAL进行恢复。这么作也会存在弊端，WAL会极大损伤spark steaming的receiver接收数据的性能，由于WAL也要容错性处理。第二个kafka自己是有副本的，receiver接收的时候也作了容错的副本，至关于容错了2次，形成资源的浪费。

receiver收到数据以后，进行了容错性处理，可是尚未来得及提交offset，此时receiver崩溃了，重启后经过管理kafka中元数据再次重启读取数据，可是此时spark认为读取成功了，kafka认为没有成功(offset没有提交)，此时就会再读一次，而以前失败的数据由于spark.task.maxFallures的值，若是大于1，会再次重试计算，若是计算成功了，就会计算2次，形成重复计算.

 

 

 

direct的方式是从kafka消费完数据以后直接封装成partition的数据提供给做业使用，而receiver是将消费到数据按照blockInterval切分红block，保存到blockManager中，在使用时会根据blockId获取该数据。

另外direct的方式rdd的partition与topic的partition是一一对应的，若是某个topic只有一个partition就很差了。而receiver的partition是根据blockInterval切分出来的，blockInterval的默认值是200ms