摘要:反壓是 Flink 應用運維中常見的問題,它不僅意味着性能瓶頸還可能導緻作業的不穩定性。
反壓(backpressure)是實時計算應用開發中,特别是流式計算中,十分常見的問題。反壓意味着資料管道中某個節點成為瓶頸,處理速率跟不上上遊發送資料的速率,而需要對上遊進行限速。
問題場景
客戶作業場景如下圖所示,從DMS kafka通過DLI Flink将業務資料實時清洗存儲到DWS。
其中,DMS Kafka 目标Topic 6個分區,DLI Flink作業配置taskmanager數量為12,并發數為1。
問題現象
客戶在DLI服務共有三個相同規格的隊列,該作業在其中003号隊列上運作正常,在001和002号隊列上都存在嚴重的反壓導緻資料處理緩慢。作業清單顯示如下圖,可以看到Sink反壓狀态正常,Souce和Map反壓狀态為HIGH。
問題分析
根據反壓情況分析,該作業的性能瓶頸在Sink,由于Sink處理資料緩慢導緻上遊反壓嚴重。
該作業所定義的Sink類型為DwsCsvSink,該Sink的工作原理如下圖所示:Sink将結果資料分片寫入到OBS,每一分片寫入完成後,調用DWS insert select sql将obs路徑下該分片資料load到dws。
是以性能瓶頸出現在分片資料寫入到OBS這一步。但問題來了,寫同一個桶,為什麼在不同隊列上的表現不一緻?
為此,我們排查了各個隊列的CPU、記憶體和網絡帶寬情況,結果顯示負載都很低。
這種情況下,隻能繼續分析FlinkUI和TaskManager日志。
資料傾斜?
然後我們在FlinkUI任務情況頁面,看到如下情況:Map階段的12個TaskManager并不是所有反壓都很嚴重,而是隻有一半是HIGH狀态,難道有資料傾斜導緻配置設定到不同TaskManager的資料不均勻?
然後看Source subTask詳情,發現有兩個TaskManager讀取的資料量是其他幾個的幾十倍,這說明源端Kafka分區流入的資料量不均勻。難道就是這麼簡單的問題?
很不幸并不是,通過進一步分析源端資料我們發現Kafka 6個分區資料流入記錄數相差并不大。這兩個Task隻是多消費了部分存量資料,接收資料增長的速度各TaskManager保持一緻。
時鐘同步
進一步分析TaskManager日志,我們發現單個分片資料寫入OBS竟然耗費3min以上。這非常異常,要知道單個分片資料才500000條而已。
進一步通過分析代碼發現如下問題:在寫OBS資料時,其中一個taskmanager寫分片目錄後擷取該目錄的最後修改時間,作為處理該分片的開始時間,該時間為OBS服務端的時間。
後續其他taskmanager向該分片目錄寫資料時,會擷取本地時間與分片開始時間對比,間隔大于所規定的轉儲周期才會寫分片資料。
如果叢集節點NTP時間與OBS服務端不同步,本地時間晚于OBS服務端時間,則會造成寫入OBS等待。
後續排查叢集節點,發現6個節點中一半時間同步有問題,這也和隻有一半taskmanager反壓嚴重的現象相對應。
問題修複
在叢集節點上執行如下指令,強制時間同步。
systemctl stop ntp
ntpdate ntp.myhuaweicloud.com
systemctl start ntp
systemctl status ntp
date
NTP同步後,作業反壓很快消失,故障恢複。
本文分享自華為雲社群《一個Flink作業反壓的問題分析》,原文作者:Yunz Bao 。
點選關注,第一時間了解華為雲新鮮技術~