一、數(shù)據(jù)傾斜是個啥？別被它唬住

簡單來說，數(shù)據(jù)傾斜就是數(shù)據(jù)分布不均勻。在 Flink 中，這會導(dǎo)致某些子任務(wù)（Subtask）被大量工作塞滿，而其他子任務(wù)卻無所事事。這種情況可不是小問題，它會讓作業(yè)效率直線下降，甚至導(dǎo)致系統(tǒng)崩潰。就好比在流水線上干活，某個工位堆滿了貨物，其他工位卻空蕩蕩的，效率自然高不起來。

數(shù)據(jù)傾斜的 “罪狀” 清單

• 單點瓶頸：某個 Subtask 忙不過來，拖慢了整條流水線。
• 垃圾回收（GC）噩夢：數(shù)據(jù)量一大，內(nèi)存壓力飆升，GC 頻繁運行。
• 吞吐量暴跌：系統(tǒng)處理速度跟不上，數(shù)據(jù)堆積如山。
• 延遲飆升：實時性難以保證。
• 系統(tǒng)崩盤：極端情況下，TaskManager 直接失聯(lián)，作業(yè)失敗。

它長啥樣？

在 Flink 任務(wù)里，數(shù)據(jù)傾斜會有以下表現(xiàn)：

• 反壓（Backpressure）：某個 Subtask 處理不過來，上游數(shù)據(jù)開始擁堵。
• 內(nèi)存溢出（OOM）：數(shù)據(jù)扎堆的地方，內(nèi)存不堪重負(fù)，直接報錯。
• 任務(wù)失聯(lián)：GC 暫停時間過長，TaskManager 被 Flink 認(rèn)為 “掛掉”。
• 吞吐量和延遲雙殺：性能指標(biāo)急劇惡化。

想要發(fā)現(xiàn)數(shù)據(jù)傾斜，可以在代碼里添加自定義日志，記錄每個 Subtask 處理的數(shù)據(jù)量，或者對數(shù)據(jù)進(jìn)行采樣，查看鍵值分布。例如，在處理網(wǎng)絡(luò)流量時，每隔 1000 條記錄查看一下源 IP 的頻率，如果有幾個 IP 出現(xiàn)頻率過高，很可能就是數(shù)據(jù)傾斜了。

二、數(shù)據(jù)傾斜的 “元兇” 是誰？

要解決問題，得先找到根源。Flink 里的數(shù)據(jù)傾斜，通常由業(yè)務(wù)數(shù)據(jù)的天然不均勻和算子操作失誤這兩個主要因素導(dǎo)致。下面我們逐一分析。

業(yè)務(wù)數(shù)據(jù)：天生不公平

現(xiàn)實世界的數(shù)據(jù)往往不是均勻分布的。業(yè)務(wù)場景決定了數(shù)據(jù)的分布情況，很多時候數(shù)據(jù)傾斜是 “命中注定” 的。

• 源數(shù)據(jù)分布的冪律魔咒：以社交媒體為例，實時統(tǒng)計話題熱度時，80% 的討論量可能集中在幾個熱門話題上，比如 “明星八卦”，而剩下的長尾話題加起來才占 20%。這種冪律分布會讓處理熱門話題的 Subtask 壓力巨大。

• 熱點數(shù)據(jù)的 “突發(fā)襲擊”：在電商場景中，新品發(fā)布或促銷活動時，某個商品的瀏覽量可能瞬間激增。所有數(shù)據(jù)都針對同一個商品 ID，F(xiàn)link 的分組操作就會陷入困境，處理該熱點的 Subtask 會不堪重負(fù)。
• 時間序列的周期性 “脾氣”：訂單數(shù)據(jù)具有明顯的周期性波動，白天高峰期數(shù)據(jù)猛增，凌晨卻非常冷清。這種周期性變化使得處理高峰時段的 Subtask 壓力山大，低谷時段則閑置。
• 地域偏好的 “地方口味”：在線教育平臺的數(shù)據(jù)，可能一線城市用戶晚上學(xué)習(xí)活躍，中小城市用戶周末才活躍。地域差異導(dǎo)致某些 Subtask 承擔(dān)了大部分工作。

這些業(yè)務(wù)特性難以改變，但了解它們有助于在設(shè)計 Flink 作業(yè)時提前做好規(guī)劃。

算子操作：自己挖的坑

Flink 的強(qiáng)大在于其豐富的算子，但使用不當(dāng)就會引發(fā)問題。不合理的 keyBy、groupBy 或者窗口設(shè)置，都可能導(dǎo)致數(shù)據(jù)傾斜。

• keyBy 和 groupBy 的 “偏心眼”：按鍵分組是 Flink 的基本操作，但如果鍵選擇不當(dāng)，很容易出現(xiàn)問題。比如，統(tǒng)計電商商品銷量時，直接按商品 ID 使用 keyBy，熱門商品（10 萬條記錄）和冷門商品（100 條記錄）的巨大差距會使 Subtask 不堪重負(fù)。
• 窗口設(shè)置的 “失策”：窗口操作是流處理的核心，但窗口設(shè)置不合理也會引發(fā)問題。例如下面這段 SQL：

sql

SELECT TUMBLE_END(proc_time, INTERVAL '1' MINUTE) AS winEnd,
       plat,
       COUNT(*) AS pv
FROM source_kafka_table
GROUP BY TUMBLE(proc_time, INTERVAL '1' MINUTE), plat

這段代碼用于統(tǒng)計每分鐘各終端的 PV，如果微信小程序的數(shù)據(jù)量遠(yuǎn)超 PC 端，所有小程序數(shù)據(jù)都會集中到一個 Subtask，從而導(dǎo)致數(shù)據(jù)傾斜。

三、偵查數(shù)據(jù)傾斜：Flink Web UI 和日志的 “火眼金睛”

發(fā)現(xiàn)問題才能解決問題。Flink 提供了 Web UI 和日志分析這兩個工具，幫助我們找出數(shù)據(jù)傾斜的所在。

Flink Web UI：全局視角

Flink 的 Web UI 就像一個監(jiān)控大屏，關(guān)鍵指標(biāo)一目了然。

• Overview 選項卡：檢查點的完成、失敗次數(shù)，可以讓我們對作業(yè)健康狀況有初步了解。如果失敗率高，可能是數(shù)據(jù)傾斜打亂了節(jié)奏。
• History 選項卡端到端持續(xù)時間：檢查點從觸發(fā)到完成所花費的時間，如果某個 Subtask 總是拖后腿，很可能是數(shù)據(jù)傾斜的嫌疑對象。檢查點數(shù)據(jù)大小：每個 Subtask 的狀態(tài)大小差異過大，說明數(shù)據(jù)分布存在問題。