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