1.什么是事務？
? ? ? ?例如像銀行轉賬，A對B轉賬，B是否能收到多次轉賬，可能性不大；或者A轉給B的時候，A同樣費用被扣了多次，B只收到一次，這樣也不可能。也就是說我們要做的事務級別的處理，簡而言之這數據一定會被處理，且只被處理一次，能夠輸出且只能輸出一次。
2.Spark Streaming整個運行角度的基本的情況
? ? ? spark streaming寫程序基于Driver和Executor兩部分，Driver的核心是StreamingContext，Receiver接收到的數據匯報給Driver（把元數據給Driver，而且Driver生產的RDD只對元數據感興趣），Driver為了數據安全進行checkpoint（從數據角度講Block MeteData、DStreamGraph、Job），接下來在Executor上執行，當然也可能在多個Executor上執行。
3.接收數據的角度講
? ? ? ?數據不斷流進Executor（InputStream的產生是在Driver上的，屬于框架調度層面的，Executor中只有數據和RDD，實際上講也沒有所謂的RDD，只有怎么算這件事,InputStream：只是從邏輯層面上講）。數據流進了receiver，不斷接受這個數據，為了保證這個數據安全性，默認情況下把數據不斷通過容錯方式進行處理，容錯方式進行處理：寫進磁盤，內存同時有副本的形式，或者說wal。
? ? ? ?WAL機制：寫數據的時候，先通過WAL寫入文件系統中，然后在存儲到Executor，Executor存儲到內存或磁盤中，這是storagelevel規定。假設前面沒寫成功，后面一定不會存儲到Executor中，不存儲到Executor中就不能匯報給Driver，這個數據不會被處理。
? ? ? 我們是否能一定確保數據的安全性呢？假如我有1G數據，在這次流的批次處理中需要處理，那我是否一定能處理這1G數據，其實不一定，wal確實能把要寫入磁盤的數據，就是進行wal的數據，能夠保證它的安全，我們現在不考慮wal失敗的可能，wal失敗的可能不大，因為他一般寫.hdfs之類的。其實Executor接受數據是一條一條接收的（從流的角度講）或者說從一個對象一個對象接收的，他會把數據在內存中，Receiver把數據積累到一定程度時候，才寫到wal或者寫到磁盤。還沒有積累到一定程度，Receiver（Executor）失敗了怎么辦，這時還是會有部分數據丟失一點（是的）。談不到備份，因為還沒有準備好數據塊，就是幾條數據
4.處理數據角度：
? ? ? 處理數據之前先checkpoint，checkpoint放到文件系統中，處理之后也會進行checkpoint，在保存一下自己狀態。spark streaming內部工作起來，絕對的核心是SparkContext；spark streaming就2點：就是StreamingContext，第一獲取數據，第二產生作業StreamingContext沒有解決執行問題，解決執行問還需要SparkContext；
? ? ? 假設出現崩潰的時候，需要數據恢復，從Driver的角度進行恢復，Driver先checkpoint文件系統讀取進來，而在內部重新啟動SparkContext。Driver里面恢復過數據，重新構建StreamingContext，其實也是構建SparkContext，恢復產生的元數據，再次產生RDD（恢復時候是基于上一次job或相對應的job）再次提交到spark集群，在提交集群時候再次執行，另外一方面包含了Receiver恢復，Receiver從新恢復在以前數據的基礎上接收數據，曾經接受的數據它會通過wal之類的機制從磁盤重新恢復回來。
5.ExactlyOnce的事務處理：
1.數據零丟失：必須有可靠的數據來源和可靠的Receiver，且整個應用程序的metadata必須進行checkpoint，且通過wal來保證數據安全；
2.Spark?Streaming 1.3的時候為了避免WAL的性能損失和實現Exactly -once而提供了Kafka Direct API，把Kafka作為文件存儲系統！！！此時兼具有流的優勢和文件系統優勢，至此，Spark Steaming + Kafka就構建了完美的流處理世界！！！所有的Executor通過KafkaAPI直接消費數據，直接管理offset，所以也不會重復消費數據；（此時可以保證數據一定會被處理且一定會被處理一次）事務實現啦！！！
備注：
資料來源于：DT_大數據夢工廠（Spark發行版本定制）
更多私密內容，請關注微信公眾號：DT_Spark
如果您對大數據Spark感興趣，可以免費聽由王家林老師每天晚上20：00開設的Spark永久免費公開課，地址YY房間號：68917580
