定位反压节点 要解决反压首先要做的是定位到造成反压的节点,这主要有两种办法 :
1. 通过 Flink Web UI 自带的反压监控面板;
2. 通过 Flink Task Metrics。
如果处于反压状态,那么有两种可能性:
1. 该节点的发送速率跟不上它的产生数据速率。这一般会发生在一条输入多条 输出的 Operator(比如 flatmap)。
2. 下游的节点接受速率较慢,通过反压机制限制了该节点的发送速率。
如果是第一种状况,那么该节点则为反压的根源节点,它是从 Source Task 到 Sink Task 的第一个出现反压的节点。
如果是第二种情况,则需要继续排查下游节点。
值得注意的是,反压的根源节点并不一定会在反压面板体现出高反压,面板监控的是发送端,如果某个节点是性能瓶颈并不会导致它本身出现高反压,而是 导致它的上游出现高反压。
总体来看,如果我们找到第一个出现反压的节点,那么反压根源要么是就这个节点,要么是它紧接着的下游节点。
分析反压的大致思路是:
如果一个 Subtask 的发送端 Buffer 占用率很高,则表 明它被下游反压限速了;
如果一个 Subtask 的接受端 Buffer 占用很高,则表明它将 反压传导至上游。
反压情况可以根据以下表格进行对号入座 ( 图片来自官网 ):
对于 Flink 1.9 及以上版本,除了上述的表格,我们还可以根据 floatingBuffersUsage/exclusiveBuffersUsage 以及其上游 Task 的 outPoolUsage 来进行进一 步的分析一个 Subtask 和其上游 Subtask 的数据传输。
通常来说,floatingBuffersUsage 为高则表明反压正在传导至上游,而 exclusiveBuffersUsage 则表明了反压是否存在倾斜(floatingBuffersUsage 高、exclusiveBuffersUsage 低为有倾斜,因为少数 channel 占用了大部分的 Floating Buffer)。
分析具体原因及处理
在实践中,很多情况下的反压是由于数据倾斜造成的。
此外,最常见的问题可能是用户代码的执行效率问题(频繁被阻塞或者性能问 题)。
另外 TaskManager 的内存以及 GC 问题也可能会导致反压。