(資料圖片)
當一家公司的日均處理的數(shù)據(jù)流量在PB級別時,巨大的任務(wù)量和數(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 恢復(fù)服務(wù)。但故障恢復(fù)后, MQ dump 在故障期間可能有數(shù)據(jù)丟失,產(chǎn)出的數(shù)據(jù)與 MQ 中的數(shù)據(jù)不一致的情況。
此時,技術(shù)人員可以在收到數(shù)據(jù)不一致的反饋后,立即借助火山引擎DataLeap進行故障排查。目前,火山引擎DataLeap基于開源Flink,已經(jīng)實現(xiàn)了流批一體的數(shù)據(jù)集成服務(wù)。通過Flink Checkpoint的功能,F(xiàn)link 在數(shù)據(jù)流中注入 barriers 將數(shù)據(jù)拆分為一段一段的數(shù)據(jù),在不終止數(shù)據(jù)流處理的前提下,讓每個節(jié)點可以獨立創(chuàng)建 Checkpoint 保存自己的快照。
圖:使用文件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ì)量。(作者:韓江)