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

【資料圖】

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

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

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

圖：Flink Checkpoint 基于 Chandy-Lamport 算法保障數(shù)據(jù)的一致性

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

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

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

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

關鍵詞：