當一家公司的日均處理的數據流量在PB級別時，巨大的任務量和數據量會對消息隊列（MQ）dump的穩定性和準確性帶來極大的挑戰。

【資料圖】

針對這一問題，火山引擎數智平臺推出的大數據研發治理套件DataLeap，可以為企業提供完整解決方案，幫助解決MQ dump在極端場景中遇到的數據丟失問題。

例如，當HDFS（一種分布式文件系統）集群某個元數據節點由于硬件故障而宕機。那么在該元數據節點終止半小時后，運維工程師雖然可以通過手動運維操作將 HDFS 切到主 backup 節點，使得HDFS 恢復服務。但故障恢復后， MQ dump 在故障期間可能有數據丟失，產出的數據與 MQ 中的數據不一致的情況。

此時，技術人員可以在收到數據不一致的反饋后，立即借助火山引擎DataLeap進行故障排查。目前，火山引擎DataLeap基于開源Flink，已經實現了流批一體的數據集成服務。通過Flink Checkpoint的功能，Flink 在數據流中注入 barriers 將數據拆分為一段一段的數據，在不終止數據流處理的前提下，讓每個節點可以獨立創建 Checkpoint 保存自己的快照。

圖：Flink Checkpoint 基于 Chandy-Lamport 算法保障數據的一致性

據介紹，每個 barrier 都有一個快照 ID ，在該快照 ID 之前的數據都會進入這個快照，而之后的數據會進入下一個快照。在排查過程中，火山引擎DataLeap基于對Flink 日志查看以及HDFS 元數據查看，可以率先定位癥結所在：刪除操作的重復執行造成數據丟失。進一步解釋就是，在故障期間，寫入數據前的刪除操作在 HDFS NameNode 上重復執行，將寫入的數據刪除造成最終數據的丟失。

圖：使用文件State 前后處理流程對比

溯源后，用戶可以通過火山引擎DataLeap選擇使用文件State（當前的 Checkpoint id 和 task id）解決該問題。據悉，使用文件 State 后，企業在 Notify 階段與 HDFS 交互的 metrics（打點監控系統）的平均處理時間減少了一半。

目前，企業可以通過火山引擎DataLeap體驗到上述Flink Checkpoint實踐與優化方案，提升數據價值交付中的效率和質量。（作者：韓江）

關鍵詞：