本期內容：
1. Exactly once容錯
2. 數據輸出不重復
一. 事務場景 :
以銀行轉帳一次為例，A用戶轉賬給B用戶，如何保證事務的一致性，即A用戶能夠轉出且只能轉出一次，B用戶能夠收到且只能收到一次。
二. Exactly once容錯：
事務處理中如何保證能夠處理且只能處理一次，數據能夠輸出且只能輸出一次。
數據丟失的主要場景如下：
在Receiver收到數據且通過Driver的調度，Executor開始計算數據的時候如果Driver突然奔潰（導致Executor會被Kill掉），此時Executor會被Kill掉，那么Executor中的數據就會丟失。
1. 事務處理如下圖 :
事務處理過程解析 ：
01. InputStream ： 輸入數據 ；
02. Executor ： 通過Receiver接收數據，當接收到數據后向Driver 匯報 ；
03. Driver ： 通過StreamingContext接收到數據會啟動Job進行操作 ；
2. 解決事務源數據接收的安全性 ：
事務處理解析 ：
01. Executor ： 在Receiver接收來自Kafka數據首先通過BlockManager寫入內存+磁盤或者通過WAL來保證數據的安全性；
02. Executor ： 通過Replication完成后產生Ack信號；
03. Kafka ： 確定收信息並讀取下一條數據，Kafka才會進行updateOffsets操作 ；
04. 通過WAL機制讓所有的數據通過類似HDFS的方式進行安全性容錯處理，從而解決Executor被Kill掉后導致數據丟失可以通過WAL機制恢復回來。
3. 解決Driver數據輸出的安全性 ：
數據的處理怎么保證有且僅有被處理一次？
數據零丟失並不能保證Exactly Once，如果Receiver接收且保存起來后沒來得及更新updateOffsets時，就會導致數據被重復處理。
01. 通過StreamingContext接收數據通過CheckPoint進行容錯 ；
02. logging the updates ： 通過記錄跟蹤所有生成RDD的轉換（transformations）也就是記錄每個RDD的lineage（血統）來重新計算生成丟失的分區數據 ；
4. Exactly Once的事務處理 ：
01、 數據零丟失：必須有可靠的數據來源和可靠的Receiver，且整個應用程序的metadata必須進行checkpoint，且通過WAL來保證數據安全；
02、Spark Streaming 1.3的時候為了避免WAL的性能損失和實現Exactly Once而提供了Kafka Direct API，把Kafka作為文件存儲系統！！
03、此時兼具有流的優勢和文件系統的優勢，Spark Streaming+Kafka就構建了完美的流處理世界！！！
04、 數據不需要copy副本，不需要WAL性能損耗，不需要Receiver，所有的Executors直接通過kafka direct api直接消費數據，直接管理Offset，所以也不會重復消費數據；
三. Spark Streaming數據輸出多次重寫及解決方案：
1、 為什么會有這個問題，因為SparkStreaming在計算的時候基於SparkCore，SparkCore天生會做以下事情導致SparkStreaming的結果（部分）重復輸出:
1、Task重試；
2、慢任務推測；
3、Stage重復；
4、Job重試；
等會導致數據的丟失。
2、 對應的解決方案：
1、一個任務失敗就是job 失敗，設置spark.task.maxFailures次數為1；
2、設置spark.speculation為關閉狀態（因為慢任務推測其實非常消耗性能，所以關閉后可以顯著的提高Spark Streaming處理性能）
3、Spark streaming on kafka的話，假如job失敗后可以設置kafka的auto.offset.reset為largest的方式會自動恢復job的執行。
最后再次強調:
可以通過transform和foreachRDD基於業務邏輯代碼進行邏輯控制來實現數據不重復消費和輸出不重復！這二個方法類似於spark s的后門，可以做任意想象的控制操作！