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