摘要：反壓是 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 。
點選關注，第一時間了解華為雲新鮮技術~