天天看點

如何處理分析Flink作業反壓的問題?

摘要:反壓是 Flink 應用運維中常見的問題,它不僅意味着性能瓶頸還可能導緻作業的不穩定性。

反壓(backpressure)是實時計算應用開發中,特别是流式計算中,十分常見的問題。反壓意味着資料管道中某個節點成為瓶頸,處理速率跟不上上遊發送資料的速率,而需要對上遊進行限速。

問題場景

客戶作業場景如下圖所示,從DMS kafka通過DLI Flink将業務資料實時清洗存儲到DWS。

如何處理分析Flink作業反壓的問題?

其中,DMS Kafka 目标Topic 6個分區,DLI Flink作業配置taskmanager數量為12,并發數為1。

問題現象

客戶在DLI服務共有三個相同規格的隊列,該作業在其中003号隊列上運作正常,在001和002号隊列上都存在嚴重的反壓導緻資料處理緩慢。作業清單顯示如下圖,可以看到Sink反壓狀态正常,Souce和Map反壓狀态為HIGH。

如何處理分析Flink作業反壓的問題?

問題分析

根據反壓情況分析,該作業的性能瓶頸在Sink,由于Sink處理資料緩慢導緻上遊反壓嚴重。

該作業所定義的Sink類型為DwsCsvSink,該Sink的工作原理如下圖所示:Sink将結果資料分片寫入到OBS,每一分片寫入完成後,調用DWS insert select sql将obs路徑下該分片資料load到dws。

如何處理分析Flink作業反壓的問題?

是以性能瓶頸出現在分片資料寫入到OBS這一步。但問題來了,寫同一個桶,為什麼在不同隊列上的表現不一緻?

為此,我們排查了各個隊列的CPU、記憶體和網絡帶寬情況,結果顯示負載都很低。

這種情況下,隻能繼續分析FlinkUI和TaskManager日志。

資料傾斜?

然後我們在FlinkUI任務情況頁面,看到如下情況:Map階段的12個TaskManager并不是所有反壓都很嚴重,而是隻有一半是HIGH狀态,難道有資料傾斜導緻配置設定到不同TaskManager的資料不均勻?

如何處理分析Flink作業反壓的問題?

然後看Source subTask詳情,發現有兩個TaskManager讀取的資料量是其他幾個的幾十倍,這說明源端Kafka分區流入的資料量不均勻。難道就是這麼簡單的問題?

如何處理分析Flink作業反壓的問題?

很不幸并不是,通過進一步分析源端資料我們發現Kafka 6個分區資料流入記錄數相差并不大。這兩個Task隻是多消費了部分存量資料,接收資料增長的速度各TaskManager保持一緻。

時鐘同步

進一步分析TaskManager日志,我們發現單個分片資料寫入OBS竟然耗費3min以上。這非常異常,要知道單個分片資料才500000條而已。

如何處理分析Flink作業反壓的問題?

進一步通過分析代碼發現如下問題:在寫OBS資料時,其中一個taskmanager寫分片目錄後擷取該目錄的最後修改時間,作為處理該分片的開始時間,該時間為OBS服務端的時間。

如何處理分析Flink作業反壓的問題?

後續其他taskmanager向該分片目錄寫資料時,會擷取本地時間與分片開始時間對比,間隔大于所規定的轉儲周期才會寫分片資料。

如何處理分析Flink作業反壓的問題?

如果叢集節點NTP時間與OBS服務端不同步,本地時間晚于OBS服務端時間,則會造成寫入OBS等待。

後續排查叢集節點,發現6個節點中一半時間同步有問題,這也和隻有一半taskmanager反壓嚴重的現象相對應。

問題修複

在叢集節點上執行如下指令,強制時間同步。

systemctl stop ntp
ntpdate ntp.myhuaweicloud.com
systemctl start ntp
systemctl status ntp
date      

NTP同步後,作業反壓很快消失,故障恢複。

如何處理分析Flink作業反壓的問題?
 本文分享自華為雲社群《一個Flink作業反壓的問題分析》,原文作者:Yunz Bao 。

點選關注,第一時間了解華為雲新鮮技術~

繼續閱讀