1. RDD Lineage容錯
分佈式系統中，常通過副本機制通過數據冗餘，來提供高可用性HA。個人認爲RDD主要是通過冗餘計算的方式來容錯的。
RDD並不提供副本機制。
RDD的分佈式是指，一個RDD可以切分多個分區（partition)，不同的分區可能在集羣的不同節點上。
RDD從HDFS讀出前，或者寫入到HDFS後，通過hadoop.dfs.replication實現數據冗餘。
RDD防止數據丟失的機制，是通過"血統重建"(lineage)實現的。spark在計算時，會對RDD應用不同的transformation操作。這一系列操作合併在一起並創建DAG，其中的邏輯執行計劃，就構成了RDD的lineage。這個過程中如果丟失了某些RDD，我們可以通過lineage的譜系圖來對原始數據重新應用相同的計算，這就是RDD的自我恢復（容錯）過程。
如果某個節點在操作過程中崩潰，spark會嘗試分配另一個節點該節點在RDD的相同分區上繼續處理，進行一系列操作。這樣，實際上沒有數據丟失。出現故障時需要恢復的兩種數據複製類型：
如果數據被複制到了其他節點上，就可以通過計算恢復RDD；
如果沒有複製到節點，就通過從源頭再次讀取它來重新恢復。
RDD的Lineage記錄的是粗顆粒度的特定數據Transformation操作（如filter、map、join等）行爲。當這個RDD的部分分區數據丟失時，它可以通過Lineage獲取足夠的信息來重新運算和恢復丟失的數據分區。
Spark的RDD使用日誌記錄數據集是如何產生的而不是去記錄數據本身，使得容錯變得高效。不需要數據備份，發生故障時無需從頭開始重新啓動應用程序。
2. RDD checkpoint容錯
一、窄依賴和寬依賴的概念主要用在兩個地方：一個是容錯中相當於Redo日誌的功能；另一個是在調度中構建DAG作爲不同Stage的劃分點。某些迭代運算裏，DAG中的Lineage過長，如果重算，則開銷太大。在最壞的情況下，Spark必須一直返回到原始數據。
二、在寬依賴情況下，丟失一個子RDD分區重算的每個父RDD的每個分區的所有數據並不是都給丟失的子RDD分區用的，會有一部分數據相當於對應的是未丟失的子RDD分區中需要的數據，這樣就會產生冗餘計算開銷，這也是寬依賴開銷更大的原因。在窄依賴中，在子RDD的分區丟失、重算父RDD分區時，父RDD相應分區的所有數據都是子RDD分區的數據，並不存在冗餘計算。
因此如果使用Checkpoint算子來做檢查點，尤其是在寬依賴上做Checkpoint，對於減少容錯過程的冗餘計算大有裨益。
Checkpoint通過將RDD寫入Disk做檢查點。Checkpoint是爲了對lineage做容錯提供輔助，lineage過長會造成容錯成本過高，這樣就不如在中間階段做檢查點容錯，如果之後有節點出現問題而丟失分區，從做檢查點的RDD開始重做Lineage，就會減少開銷。
3. streaming WAL容錯
Spark Streaming 是 Spark Core API 的擴展，它支持彈性的，高吞吐的，容錯的實時數據流的處理。數據可以通過多種數據源獲取，例如 Kafka，Flume，Kinesis 以及 TCP sockets。
基於Receivers的輸入源，容錯取決於故障情況和Receiver的類型。
故障場景：
- Driver故障
如果正在運行Spark Streaming應用程序的驅動程序節點發生故障，則SparkContent會丟失，所有執行程序都會丟失其內存中數據。 - Worker故障
執行程序的任何工作節點都可能發生故障，從而導致內存丟失。在故障節點上的Receiver，其緩衝區的數據將丟失。
數據源（如 Kafka 和 Flume）允許傳輸的數據被確認。如果系統從這些可靠的數據來源接收數據，並且被確認（acknowledges）正確地接收數據，它可以確保數據不會因爲任何類型的失敗而導致數據丟失。有
兩種類型的 receivers:
- Reliable Receiver（可靠的接收器） - 當數據被接收並存儲在 Spark 中並帶有備份副本時，一個可靠的接收器（reliable receiver）正確地發送確認（acknowledgment）給一個可靠的數據源（reliable source）。
- Unreliable Receiver（不可靠的接收器） - 一個不可靠的接收器（unreliable receiver）不發送確認（acknowledgment）到數據源。這可以用於不支持確認的數據源，或者甚至是可靠的數據源當你不想或者不需要進行復雜的確認的時候。
如果工作程序節點發生故障，並且接收器可靠，則不會丟失任何數據。但是，在Receiver不可靠的情況下，將會發生數據丟失。使用不可靠的Receiver，可能會丟失接收到但未複製的數據。
WAL(write ahead log)
如果驅動程序節點發生故障，則已接收並複製到內存中的所有數據都將丟失。這將影響有狀態轉換的結果。爲了避免數據丟失，Spark 1.2引入了預寫日誌，該日誌將接收到的數據保存到容錯存儲中。接收到的所有數據都將被寫入預寫日誌，然後才能處理到Spark Streaming。
預寫日誌的工作方式是：首先將操作意圖記錄在持久日誌中，之後再將操作應用於數據。
如果系統在操作過程中發生故障，則可以恢復丟失的數據。通過讀取日誌並重新應用其打算執行的數據來完成此操作。
Notes:
可以通過將配置參數 spark.streaming.receiver.writeAheadLog.enable 設置爲 true來啓用此功能。然而，這些更強的語義可能以單個 receiver 的接收吞吐量爲代價。通過 並行運行更多的 receiver 可以糾正這一點，以增加總吞吐量。另外，建議在啓用寫入日誌時，在日誌已經存儲在複製的存儲系統中時，禁用在 Spark 中接收到的數據的複製。這可以通過將輸入流的存儲級別設置爲 StorageLevel.MEMORY_AND_DISK_SER 來完成。
4. streaming checkpoint
streaming 應用程序必須 24*7 運行，因此必須對應用邏輯無關的故障（例如，系統故障，JVM 崩潰等）具有彈性。爲了可以這樣做，Spark Streaming 需要 checkpoint出足夠的信息到容錯存儲系統，以便可以從故障中恢復。checkpoint 有兩種類型的數據。
- Metadata checkpointing - 將定義 streaming 計算的信息保存到容錯存儲（如 HDFS）中。這用於從運行 streaming 應用程序的 driver 的節點的故障中恢復（稍後詳細討論）。
元數據包括:
-Configuration - 用於創建流應用程序的配置。
-DStream operations - 定義 streaming 應用程序的 DStream 操作集。
-未完成的batches - 批量的job 排隊但尚未完成。 - Data checkpointing - 將生成的 RDD 保存到可靠的存儲。這在一些將多個批次之間的數據進行組合的 狀態 變換中是必需的。在這種轉換中，生成的 RDD 依賴於先前批次的 RDD，這導致依賴鏈的長度隨時間而增加。爲了避免恢復時間的這種無限增加（與依賴關係鏈成比例），有狀態轉換的中間 RDD 會定期 checkpoint 到可靠的存儲（例如 HDFS）以切斷依賴關係鏈。
總而言之，元數據 checkpoint 主要用於從 driver 故障中恢復，而數據或 RDD checkpoint 對於基本功能（如果使用有狀態轉換的數據處理失敗情況）則是必需的。
spark streaming官方推薦checkpoint定時持久的刷新間隔一般爲批處理間隔的5到10倍是比較好的一個方式。Typically, a checkpoint interval of 5 - 10 sliding intervals of a DStream is a good setting to try.