Driver HA
由於流計算系統是長期運行、且不斷有數據流入，因此其Spark守護進程（Driver）的可靠性至關重要，它決定了Streaming程序能否一直正確地運行下去。
Driver實現HA的解決方案就是將元數據持久化，以便重啓後的狀態恢復。如圖一所示，Driver持久化的元數據包括：
Block元數據（圖1中的綠色箭頭）：Receiver從網絡上接收到的數據，組裝成Block後產生的Block元數據；
Checkpoint數據（圖1中的橙色箭頭）：包括配置項、DStream操作、未完成的Batch狀態、和生成的RDD數據等；
Driver失敗重啓後：
恢復計算（圖2中的橙色箭頭）：使用Checkpoint數據重啓driver，重新構造上下文並重啓接收器。
恢復元數據塊（圖2中的綠色箭頭）：恢復Block元數據。
恢復未完成的作業（圖2中的紅色箭頭）：使用恢復出來的元數據，再次產生RDD和對應的job，然後提交到Spark集羣執行。
通過如上的數據備份和恢復機制，Driver實現了故障後重啓、依然能恢復Streaming任務而不丟失數據，因此提供了系統級的數據高可靠。
可靠的上下游IO系統
流計算主要通過網絡socket通信來實現與外部IO系統的數據交互。由於網絡通信的不可靠特點，發送端與接收端需要通過一定的協議來保證數據包的接收確認和失敗重發機制。
不是所有的IO系統都支持重發，這至少需要實現數據流的持久化，同時還要實現高吞吐和低時延。在SparkStreaming官方支持的data source裏面，能同時滿足這些要求的只有Kafka，因此在最近的SparkStreaming release裏面，也是把Kafka當成推薦的外部數據系統。
除了把Kafka當成輸入數據源（inbound data source）之外，通常也將其作爲輸出數據源（outbound data source）。所有的實時系統都通過Kafka這個MQ來做數據的訂閱和分發，從而實現流數據生產者和消費者的解耦。
一個典型的企業大數據中心數據流向視圖如圖3所示：
除了從源頭保證數據可重發之外，Kafka更是流數據Exact Once語義的重要保障。Kafka提供了一套低級API，使得client可以訪問topic數據流的同時也能訪問其元數據。SparkStreaming每個接收的任務都可以從指定的Kafka topic、partition和offset去獲取數據流，各個任務的數據邊界很清晰，任務失敗後可以重新去接收這部分數據而不會產生“重疊的”數據，因而保證了流數據“有且僅處理一次”。
可靠的接收器
在Spark 1.3版本之前，SparkStreaming是通過啓動專用的Receiver任務來完成從Kafka集羣的數據流拉取。
Receiver任務啓動後，會使用Kafka的高級API來創建topicMessageStreams對象，並逐條讀取數據流緩存，每個batchInerval時刻到來時由JobGenerator提交生成一個spark計算任務。
由於Receiver任務存在宕機風險，因此Spark提供了一個高級的可靠接收器-ReliableKafkaReceiver類型來實現可靠的數據收取，它利用了Spark 1.2提供的WAL（Write Ahead Log）功能，把接收到的每一批數據持久化到磁盤後，更新topic-partition的offset信息，再去接收下一批Kafka數據。萬一Receiver失敗，重啓後還能從WAL裏面恢復出已接收的數據，從而避免了Receiver節點宕機造成的數據丟失（以下代碼刪除了細枝末節的邏輯）：
啓用WAL後，雖然Receiver的數據可靠性風險降低了，但卻由於磁盤持久化帶來的開銷，系統整體吞吐率會明顯下降。因此，最新發布的Spark 1.3版本，SparkStreaming增加了使用Direct API的方式來實現Kafka數據源的訪問。
引入了Direct API後，SparkStreaming不再啓動常駐的Receiver接收任務，而是直接分配給每個Batch及RDD最新的topic partition offset。job啓動運行後Executor使用Kafka的simple consumer API去獲取那一段offset的數據。
這樣做的好處不僅避免了Receiver宕機帶來數據可靠性的風險，也由於避免使用ZooKeeper做offset跟蹤，而實現了數據的精確一次性（以下代碼刪除了細枝末節的邏輯）：
預寫日誌 Write Ahead Log
Spark 1.2開始提供預寫日誌能力，用於Receiver數據及Driver元數據的持久化和故障恢復。WAL之所以能提供持久化能力，是因爲它利用了可靠的HDFS做數據存儲。
SparkStreaming預寫日誌機制的核心API包括：
管理WAL文件的WriteAheadLogManager
讀/寫WAL的WriteAheadLogWriter和WriteAheadLogReader
基於WAL的RDD：WriteAheadLogBackedBlockRDD
基於WAL的Partition：WriteAheadLogBackedBlockRDDPartition
以上核心API在數據接收和恢復階段的交互示意圖如圖4所示。
從WriteAheadLogWriter的源碼裏可以清楚看到，每次寫入一塊數據buffer到HDFS後都會調用flush方法去強制刷入磁盤，然後纔去取下一塊數據。因此receiver接收的數據是可以保證持久化到磁盤了，因而做到較好的數據可靠性。
結束語
得益於Kafka這類可靠的data source以及自身的checkpoint/WAL等機制，SparkStreaming的數據可靠性得到了很好的保證，數據能保證“至少一次”（at least once）被處理。但由於其outbound端的一致性實現還未完善，因此Exact once語義仍然不能端到端保證。SparkStreaming社區已經在跟進這個特性的實現（SPARK-4122），預計很快將合入trunk發佈。