在做流式計算過程中，最複雜最難做的莫過於數據冪等性修改操作的設計。先解釋一下概念【冪等性操作】，冪等性概念來源於數學專業表示對一個表達式做多次相同的操作，表達式不會改變。例如：邏輯迴歸中的Sigmod函數，n次求導之後依然堅挺。在流式計算中容錯設計也要求工程設計有數據冪等性設計，特別針對流式計算中對第三方存儲平臺的修改操作。以及更加逆天的場景：在一個業務線有多個點有批量的數值修改操作，只要有一個點沒有修改完成，而此時流式計算崩潰，下次重啓都要做所有點的數據恢復操作。
說到冪等性，不得不說一下spark中的一個優化操作---推測執行。推測執行設計的初衷是提高作業的執行效率，避免某一個任務因爲硬件問題卡死而拖慢整個計算任務。大致設計思想時，在任務完成達到某個百分比，開始檢查任務完成情況，如果發現某任務執行時間超過其他任務耗時均值的閾值倍數，就在其他節點重啓相同的計算任務，這樣可以有效避免因硬件問題造成的卡死現象。但是在流式計算中對於修改數值的操作或者在mappartion/foreachPartition中自定義數據持久化到非主鍵約束的平臺時，就會出現災難性後果。一旦出現數據傾斜，啓動備用線程執行當前任務，就會出現數據加倍等髒數據。所以在以上場景，無法保證操作冪等性的前提下，不要開啓推測執行。
今天着重分享對於hbase的冪等性修改的設計
因爲hbase數據有rowKey這種類似唯一主鍵的約束，數據覆蓋寫這種操作很很容易就能實現。即使出現一批數據沒有完全寫完，出現流式計算崩潰，這種場景也沒有問題，下次重啓再寫一次覆蓋就可以了，不會出現髒數據。但是對於修改操作，多個線程並行修改，只要有一個沒有完成，系統掛掉，在重啓之前需要將上個批次沒有修改完成的數據回覆到最後一次修改完成的狀態。
這個主要設計方案是：
1.在流式計算中設置並持久化 批次號(從0開始，每個批次完成是批次號加一)
2.在寫hbase時，除了正常修改的數據外，再寫一列附屬列用來保存當前批次號和當前批次修改的字段名稱
3.優化操作：（每個批次在修改hbase之前，將當前使用批次使用的所有rowkey持久化（hdfs或者kafka=>hdfs(爲了儘量減少直接寫hdfs影響執行速度)），寫成功後刪除上次保存的rowkey(如果通過kafka寫，rowkey+批次號，刪除小於當前批次號的數據)
4. 重啓流式計算前，讀取最後一次保存的rowkey。按照rowkey到hbase中查詢出相關的數據，根據附屬列中記錄的上一次批次修改的列，將相關的cell用上一個版本(hbase cell默認保存三個版本)的數據覆蓋當前的數據。這個操作可以和流式計算分開，也可以和流式計算寫到一起
5.然後開始開始啓動流式計算（接着從上次保存的offset+1的位置），接着處理數據
————————————————
版權聲明：本文爲CSDN博主「sunkl_」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u010990043/java/article/details/83144345