我們知道RDD本身是一個不可變的，可重新計算的、分散式的資料集。每一個RDD都會記住確定好的操作血緣關係。

如果因為某些原因，導致某個worker節點失敗，則導致RDD的某個partition資料丟失了，那麼那個partition可以通過對原始的容錯資料集應用操作血緣，來重新計算。因為HDFS本身是容錯檔案系統的，所以在HDFS的資料不會丟失，最壞情況無非重新計算而已。

但是對於SparkStreaming,在大多數情況下，都是通過網路接收的資料，要讓Spark Streaming程式中，所有生成的RDD,都達到與普通的Spark程式的RDD相同的容錯性，接受到的資料必須複製到多個Worker節點上的Executor記憶體中，預設複製因子是2.

# Worker節點的失敗：任何一個運行了Executor的Worker節點失敗，都會導致該節點上所有在記憶體中的資料丟失，如果有Receiver執行在該Worker節點的Executor中，那麼快取的、等待複製的資料，都會丟失

# Driver節點的失敗：SparkContext和StreamingContext就丟失，如果我們開啟Driver的checkpoint機制，這個時候該應用程式的所有Executor的資料都會丟失。

Spark Streaming容錯語義：

流式計算系統的容錯語義，通常是以一條記錄能夠被處理的多少次來衡量。有三種類型的語義：

1 最多一次：每一條記錄可能會處理一次，或者根本不處理，可能有資料丟失

2 至少一次：每一條記錄會被處理一次或者多次，這種語義比最多一次強點，他確保資料零丟失，但是會導致資料重複消費

3 一次僅且一次：每一條記錄只處理一次，沒有資料丟失

接收資料的容錯語義：

1 基於檔案的資料來源

如果所有輸入的資料都在一個容錯的檔案系統中，比如HDFS, Spark Streaming一定可以從失敗中進行恢復，並且處理所有資料，這就提供了一次僅且一次的語義。

2 基於Receiver的資料來源

對於基於Receiver的資料來源，容錯語義依賴於失敗場景和Receiver型別

可靠的Receiver: 這種Receiver會在接收了資料，並且將資料複製之後，對資料來源執行確認操作。如果Receiver在資料接收和複製完成之前就失敗了，那麼資料來源對於快取的資料會接收不到確認，此時Receiver重啟之後，資料來源會重新發送資料，沒有資料丟失

不可靠的Receiver: 這種Receiver不會發送確認操作，因此當worker或者driver節點失敗的時候，可能會導致資料丟失

針對不可靠的Receiver可能發生資料丟失問題，那麼Spark引入了預寫日誌的機制,這樣就可以保證資料零丟失。這種情況會提供至少一次保障。

計算資料容錯：所有接受的資料一定只會被計算一次，這是基於RDD基礎語義所保障的，即使有失敗，只要接收到的資料還是可以訪問的，最後一個計算出來的資料一定是相同的

推送資料容錯：output操作預設只能保證至少一次的語義，因為依賴於輸出型別以及底層的系統語義支援，比如是否有事務機制來確保一次僅且一次的語義