分析&回答

Flink Web UI 自帶的反壓監(jiān)控 —— 直接方式

Flink Web UI 的反壓監(jiān)控提供了 Subtask 級(jí)別的反壓監(jiān)控。監(jiān)控的原理是通過Thread.getStackTrace() 采集在 TaskManager 上正在運(yùn)行的所有線程，收集在緩沖區(qū)請(qǐng)求中阻塞的線程數(shù)（意味著下游阻塞），并計(jì)算緩沖區(qū)阻塞線程數(shù)與總線程數(shù)的比值 rate。其中，rate < 0.1 為 OK，0.1 <= rate <= 0.5 為 LOW，rate > 0.5 為 HIGH。

Web UI 反壓監(jiān)控?

以下兩種場(chǎng)景可能導(dǎo)致反壓：

1. 該節(jié)點(diǎn)發(fā)送速率跟不上它的產(chǎn)生數(shù)據(jù)速率。該場(chǎng)景一般是單輸入多輸出的算子，例如FlatMap。定位手段是因?yàn)檫@是從 Source Task 到 Sink Task 的第一個(gè)出現(xiàn)反壓的節(jié)點(diǎn)，所以該節(jié)點(diǎn)是反壓的根源節(jié)點(diǎn)。
2. 下游的節(jié)點(diǎn)處理數(shù)據(jù)的速率較慢，通過反壓限制了該節(jié)點(diǎn)的發(fā)送速率。定位手段是從該節(jié)點(diǎn)開始繼續(xù)排查下游節(jié)點(diǎn)。

注意事項(xiàng)：

1. 因?yàn)?strong>Flink Web UI 反壓面板是監(jiān)控發(fā)送端的，所以反壓的根源節(jié)點(diǎn)并不一定會(huì)在反壓面板體現(xiàn)出高反壓。如果某個(gè)節(jié)點(diǎn)是性能瓶頸并不會(huì)導(dǎo)致它本身出現(xiàn)高反壓，而是導(dǎo)致它的上游出現(xiàn)高反壓。總體來看，如果找到第一個(gè)出現(xiàn)反壓的節(jié)點(diǎn)，則反壓根源是這個(gè)節(jié)點(diǎn)或者是它的下游節(jié)點(diǎn)。
2. 通過反壓面板無法區(qū)分上述兩種狀態(tài)，需要結(jié)合 Metrics 等監(jiān)控手段來定位。如果作業(yè)的節(jié)點(diǎn)數(shù)很多或者并行度很大，即需要采集所有 Task 的棧信息，反壓面板的壓力也會(huì)很大甚至不可用 。

Flink Task Metrics —— 間接方式

（1）回顧 Flink Credit-based 網(wǎng)絡(luò)

Flink Credit-Based 網(wǎng)絡(luò)

① TaskManager 之間的數(shù)據(jù)傳輸

不同的 TaskManager 上的兩個(gè) Subtask 通常情況下，channel 數(shù)量等于分組 key 的數(shù)量或者等于算子并發(fā)度。這些 channel 會(huì)復(fù)用同一個(gè) TaskManager 進(jìn)程的 TCP 請(qǐng)求，并且共享接收端 Subtask 級(jí)別的 Buffer Pool。

② 接收端

每個(gè) channel 在初始階段會(huì)被分配固定數(shù)量的獨(dú)享 Exclusive Buffer，用于存儲(chǔ)接收到的數(shù)據(jù)。算子 Operator 使用后再次釋放 Exclusive? Buffer。說明：channel 接收端空閑的 Buffer 數(shù)量稱為 Credit，Credit 會(huì)被定時(shí)同步給發(fā)送端，用于決定發(fā)送多少個(gè) Buffer 的數(shù)據(jù)。

③ 流量較大的場(chǎng)景

接收端，channel 寫滿 Exclusive Buffer 后，Flink 會(huì)向 Buffer Pool 申請(qǐng)剩余的 Floating Buffer。發(fā)送端，一個(gè) Subtask 所有的 Channel 會(huì)共享同一個(gè) Buffer Pool，因此不區(qū)分 Exclusive Buffer 和 Floating Buffer。

（2）Flink Task Metrics 監(jiān)控反壓

Network和?task I/Ometrics 是輕量級(jí)反壓監(jiān)視器，用于正在持續(xù)運(yùn)行的作業(yè)，其中一下幾個(gè) metrics 是最有用的反壓指標(biāo)。

metrics反壓指標(biāo)

采用 Metrics 分析反壓的思路：如果一個(gè) Subtask 的發(fā)送端 Buffer 占用率很高，則表明它被下游反壓限速了；如果一個(gè) Subtask 的接受端 Buffer 占用很高，則表明它將反壓傳導(dǎo)至上游。

inPoolUsage和outPoolUsage反壓分析表

解釋：

①?outPoolUsage 和 inPoolUsage 同為低表明當(dāng)前?Subtask 是正常的，同為高分別表明當(dāng)前 Subtask 被下游反壓。

②?如果一個(gè) Subtask 的 outPoolUsage 是高，通常是被下游 Task 所影響，所以可以排查它本身是反壓根源的可能性。

③?如果一個(gè) Subtask 的 outPoolUsage 是低，但其 inPoolUsage 是高，則表明它有可能是反壓的根源。因?yàn)橥ǔ７磯簳?huì)傳導(dǎo)至其上游，導(dǎo)致上游某些 Subtask 的 outPoolUsage 為高。

注意：反壓有時(shí)是短暫的且影響不大，比如來自某個(gè) channel 的短暫網(wǎng)絡(luò)延遲或者 TaskManager 的正常 GC，這種情況下可以不用處理。

下表把 inPoolUsage 分為?floatingBuffersUsage 和 exclusiveBuffersUsage，并且總結(jié)上游 Task?outPoolUsage 與?floatingBuffersUsage 、 exclusiveBuffersUsage 的關(guān)系，進(jìn)一步的分析一個(gè) Subtask 和其上游 Subtask 的反壓情況。

正在上傳…重新上傳取消

outPoolUsage 與?floatingBuffersUsage 、 exclusiveBuffersUsage 的關(guān)系表

1. floatingBuffersUsage 為高則表明反壓正在傳導(dǎo)至上游。
2. exclusiveBuffersUsage 則表明了反壓可能存在傾斜。如果floatingBuffersUsage 高、exclusiveBuffersUsage 低，則存在傾斜。因?yàn)樯贁?shù) channel 占用了大部分的 floating Buffer（channel 有自己的 exclusive buffer，當(dāng) exclusive buffer 消耗完，就會(huì)使用floating Buffer）。?

3 Flink 如何分析反壓

上述主要通過 TaskThread 定位反壓，而分析反壓原因類似一個(gè)普通程序的性能瓶頸。

（1）數(shù)據(jù)傾斜

通過 Web UI 各個(gè) SubTask 的 Records Sent 和 Record Received 來確認(rèn)，另外 Checkpoint detail 里不同 SubTask 的 State size 也是一個(gè)分析數(shù)據(jù)傾斜的有用指標(biāo)。解決方式把數(shù)據(jù)分組的 key 進(jìn)行本地/預(yù)聚合來消除/減少數(shù)據(jù)傾斜。

（2）用戶代碼的執(zhí)行效率

對(duì) TaskManager 進(jìn)行 CPU profile，分析 TaskThread 是否跑滿一個(gè) CPU 核：如果沒有跑滿，需要分析 CPU 主要花費(fèi)在哪些函數(shù)里面，比如生產(chǎn)環(huán)境中偶爾會(huì)卡在 Regex 的用戶函數(shù)（ReDoS）；如果沒有跑滿，需要看 Task Thread 阻塞在哪里，可能是用戶函數(shù)本身有些同步的調(diào)用，可能是 checkpoint 或者 GC 等系統(tǒng)活動(dòng)。

（3）TaskManager 的內(nèi)存以及 GC

TaskManager JVM 各區(qū)內(nèi)存不合理導(dǎo)致的頻繁 Full GC 甚至失聯(lián)?？梢约由?-XX:+PrintGCDetails 來打印 GC 日志的方式來觀察 GC 的問題。推薦TaskManager 啟用 G1 垃圾回收器來優(yōu)化 GC。

喵嗚面試助手：一站式解決面試問題，你可以搜索微信小程序 [喵嗚面試助手]?或關(guān)注 [喵嗚刷題] -> 面試助手?免費(fèi)刷題。如有好的面試知識(shí)或技巧期待您的共享！