標籤:
Spark Streaming交易處理徹底掌握
感謝DT大資料夢工廠支援提供以下內容,DT大資料夢工廠專註於Spark發行版定製。
內容概括:
1Exactly once
2 輸出不重複
1 正如銀行轉賬業務一樣,如果你給一個朋友轉賬一次,銀行的系統必須保證此次的轉賬資料有且只能處理一次,不能出現另外的情況。事務的意思就是保證資料有且只能處理一次。
而Spark Streaming流處理在交易處理方面也是做得非常好的,並且這一部分內容也是非常重要的。
所謂一圖勝千言,我們就來畫一張圖吧。
整個資料在Driver和Executor上的分布如下
總體上講是:Driver儲存資料中繼資料資訊,Executor上儲存具體的資料。
Executor上儲存具體的資料的具體過程如所示
Executor 通過BlockManager寫入記憶體+磁碟通過WAL來保證資料的安全性 (Receiver)需要注意的是:WAL仍然不能100%保證資料的安全性。當log沒有積累到閾值的時候如果崩潰。
這是接收資料的角度來理解,當然Spark Streaming能工作起來,核心還是SparkContext。
Spark Streaming簡單的說就倆點:一是接收資料 而是作業執行。
從資料恢複的角度來看。Spark StreamingContext可以通過checkpoint的檔案系統中將中繼資料讀進來,從而恢複資料。再通過SparkContext將作業提交給叢集。
接下來在以上的基礎上我們再來談談資料一致性的事務問題。
儘管如此,資料還是有可能會資料丟失,或者資料重複處理。那麼我們應該怎麼辦呢?
第一點:在Receiver收到資料且通過Driver調度,Executor開始計算資料時,Driver突然崩潰。將會導致Executor被kill掉,資料就會丟失,此時務必通過WAL的方式寫入HDFS進行備份來保證資料安全性。(丟失的資料可以通過WAL恢複過來)
對於資料有且只被處理一次。當資料被處理後,updataOffsets執行之前如果程式突然崩潰了,就還沒來得及更新offsets就很有可能導致資料重複處理(此時可以通過程式判斷中繼資料有沒有處理過,如果沒有就會導致資料重複處理)
當Receiver崩潰後重新啟動就會通過管理Kafka的zookeeper中的中繼資料再次重複讀取資料,但是此時的SparkStreaming認為是成功,但是kafka認為是失敗的(因為沒有成功執行updateOffsets)就會重複處理消費資料。
整個過程美中不足的是:效能會極大的損失
1 通過WAL的方式會極大的損失Spark Streaming中REeceiver接收資料的效能,因為要花時間先寫Log,然後再寫入資料。
2 如果通過kafka作為資料來源的話,kafka中有資料備份,然後通過Receiver接收資料的時候又會有副本(為資料安全性而存在的持久化備份),這個時候其實是對資源的極大的浪費。
十分幸運的是:spark 1.3的時候為解決這個效能的問題,支援了Kafka Direct API ,把kafka作為檔案儲存體系統!!!!
減少了資料重複多餘備份,又避免了WAL損耗Receiver的問題。
kafka即作為檔案儲存體系統,又作為一個檔案流,此時兼具有檔案流的優勢和檔案系統的優勢,至此之後,SparkStreaming加上Kafka就成為了相對非常完美的流處理最佳組合。
所有的Executor通過Kafka Direcit API直接消費讀取資料。同時也會自己儲存管理資料,自己管理自己消費。不會重複消費資料。此時就完美的解決了資料一定會處理,並且只會被處理一次。
二 關於資料輸出多次重寫及解決方案
關於引起此問題的原因有以下幾點
1 task重試
2 job重試
3 stage重試
4 慢任務推測執行
具體的解決辦法是設定總共執行次數為1
1 設定spark.task.maxFailures次數為1
2 設定 spark.speculation為關閉狀態,不推測執行(關閉後可以提高任務執行的效率)(少了一個步驟嘛!!!!)
3 spark streaming on kafka的話,job失敗後可以設定auto.offset.reset為largest的方式。
最後再次強調:可以通過transform和foreachRDD對RDD基於商務邏輯代碼進行邏輯控制來實現資料不重複消費和輸出不重複。後續會具體的代碼實現。敬請有興趣的朋友們關注動態。
詳細資料請查看
聯絡郵箱[email protected]
電話:18610086859
QQ:1740415547
號:18610086859
整個資料設定在Driver和Executor上的分
spark發行版筆記4Spark Streaming交易處理徹底掌握