Flink调优----反压处理

在 Flink 大数据处理架构中，网络流控及反压机制犹如交通指挥系统，对于保障数据流畅通无阻、系统稳定高效运行起着至关重要的作用。当数据在 Flink 任务的各个节点间流动时，一旦出现反压现象，若不能及时察觉与妥善处理，将会如连锁反应般对整个数据处理流程产生诸多负面影响，从 checkpoint 的时长增加、状态大小膨胀，到资源的过度消耗乃至系统的崩溃瘫痪。因此，深入理解 Flink 网络流控及反压的原理、熟练掌握定位反压节点的方法以及明晰反压产生的原因与对应的处理策略，是每一位致力于优化 Flink 作业性能的开发者和运维人员的必备技能，能够帮助其在面对复杂多变的数据处理场景时，提前预防或迅速解决反压问题，确保 Flink 系统始终保持高效、稳定的运行状态，为业务提供持续可靠的数据支持与服务。

概述

Flink 网络流控及反压的介绍：
Apache Flink学习网

1.1 反压的理解

简单来说，Flink 拓扑中每个节点（Task）间的数据都以阻塞队列的方式传输，下游来不及消费导致队列被占满后，上游的生产也会被阻塞，最终导致数据源的摄入被阻塞。

反压（BackPressure）通常产生于这样的场景：短时间的负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或遇到大促、秒杀活动导致流量陡增。

1.2 反压的危害

反压如果不能得到正确的处理，可能会影响到 checkpoint 时长和 state 大小，甚至可能会导致资源耗尽甚至系统崩溃。

影响 checkpoint 时长：barrier 不会越过普通数据，数据处理被阻塞也会导致 checkpoint barrier 流经整个数据管道的时长变长，导致 checkpoint 总体时间（End to End Duration）变长。
影响 state 大小：barrier 对齐时，接受到较快的输入管道的 barrier 后，它后面数据会被缓存起来但不处理，直到较慢的输入管道的 barrier 也到达，这些被缓存的数据会被放到 state 里面，导致 checkpoint 变大。

这两个影响对于生产环境的作业来说是十分危险的，因为 checkpoint 是保证数据一致性的关键，checkpoint 时间变长有可能导致 checkpoint 超时失败，而 state 大小同样可能拖慢 checkpoint 甚至导致 OOM （使用 Heap-based StateBackend）或者物理内存使用超出容器资源（使用 RocksDBStateBackend）的稳定性问题。

因此，我们在生产中要尽量避免出现反压的情况。

定位反压节点

解决反压首先要做的是定位到造成反压的节点，排查的时候，先把 operator chain 禁用，方便定位到具体算子。

提交 UvDemo:

bash 复制代码

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \
-Drest.flamegraph.enabled=true \
-Dyarn.application.queue=test \
-Djobmanager.memory.process.size=1024mb \
-Dtaskmanager.memory.process.size=2048mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

2.1 利用 Flink Web UI 定位

Flink Web UI 的反压监控提供了 SubTask 级别的反压监控，1.13 版本以前是通过周期性对 Task 线程的栈信息采样，得到线程被阻塞在请求 Buffer（意味着被下游队列阻塞）的频率来判断该节点是否处于反压状态。默认配置下，这个频率在 0.1 以下则为 OK，0.1 至 0.5 为 LOW，而超过 0.5 则为 HIGH。

Flink 1.13 优化了反压检测的逻辑（使用基于任务 Mailbox 计时，而不在再于堆栈采样），并且重新实现了作业图的 UI 展示：Flink 现在在 UI 上通过颜色和数值来展示繁忙和反压的程度。

通过 WebUI 看到 Map 算子处于反压：

分析瓶颈算子

如果处于反压状态，那么有两种可能性：该节点的发送速率跟不上它的产生数据速率。这一般会发生在一条输入多条输出的 Operator（比如 flatmap）。这种情况，该节点是反压的根源节点，它是从 Source Task 到 Sink Task 的第一个出现反压的节点。

下游的节点接受速率较慢，通过反压机制限制了该节点的发送速率。这种情况，需要继续排查下游节点，一直找到第一个为 OK 的一般就是根源节点。
总体来看，如果我们找到第一个出现反压的节点，反压根源要么是就这个节点，要么是它紧接着的下游节点。
通常来讲，第二种情况更常见。如果无法确定，还需要结合 Metrics 进一步判断。

2.2 利用 Metrics 定位

监控反压时会用到的 Metrics 主要和 Channel 接受端的 Buffer 使用率有关，最为有用的是以下几个 Metrics:

Metris	描述
outPoolUsage	发送端 Buffer 的使用率
inPoolUsage	接收端 Buffer 的使用率
floatingBuffersUsage（1.9 以上）	接收端 Floating Buffer 的使用率
exclusiveBuffersUsage（1.9 以上）	接收端 Exclusive Buffer 的使用率

其中 inPoolUsage = floatingBuffersUsage + exclusiveBuffersUsage。

根据指标分析反压

分析反压的大致思路是：如果一个 Subtask 的发送端 Buffer 占用率很高，则表明它被下游反压限速了；如果一个 Subtask 的接受端 Buffer 占用很高，则表明它将反压传导至上游。反压情况可以根据以下表格进行对号入座 (1.9 以上):

|-------------------------------|--------------------------------------------|--------------------------------|
| | outPoolUsage 低 | outPoolUsage 高 |
| inPoolUsage 低 | 正常 | 被下游反压，处于临时情况（还没传递到上游） |
| inPoolUsage 低 | 正常 | 可能是反压的根源，一条输入多条输出的场景 |
| inPoolUsage 高 | 如果上游所有outPoolUsage都是低，有可能最终可能导致反压（还没传递到上游） | 被下游反压 |
| inPoolUsage 高 | 如果上游的outPoolUsage是高，则为反压根源 | 被下游反压 |

可以进一步分析数据传输

Flink 1.9 及以上版本，还可以根据 floatingBuffersUsage/exclusiveBuffersUsage 以及其上游 Task 的 outPoolUsage 来进行进一步的分析一个 Subtask 和其上游 Subtask 的数据传输。

在流量较大时，Channel 的 Exclusive Buffer 可能会被写满，此时 Flink 会向 Buffer Pool 申请剩余的 Floating Buffer。这些 Floating Buffer 属于备用 Buffer。

exclusiveBuffersUsage 低	exclusiveBuffersUsage 高
floatingBuffersUsage 低所有上游 outPoolUsage 低	正常
floatingBuffersUsage 低上游某个 outPoolUsage 高	潜在的网络瓶颈
floatingBuffersUsage 高所有上游 outPoolUsage 低	最终对部分 inputChannel 反压（正在传递）	最终对大多数或所有 inputChannel 反压（正在传递）
floatingBuffersUsage 高上游某个 outPoolUsage 高	只对部分 inputChannel 反压	对大多数或所有 inputChannel 反压

总结：

floatingBuffersUsage 为高，则表明反压正在传导至上游
同时 exclusiveBuffersUsage 为低，则表明可能有倾斜
比如，floatingBuffersUsage 高、exclusiveBuffersUsage 低为有倾斜，因为少数 channel 占用了大部分的 Floating Buffer。

反压的原因及处理

注意：反压可能是暂时的，可能是由于负载高峰、CheckPoint 或作业重启引起的数据积压而导致反压。如果反压是暂时的，应该忽略它。另外，请记住，断断续续的反压会影响我们分析和解决问题。

定位到反压节点后，分析造成原因的办法主要是观察 Task Thread。按照下面的顺序，一步一步去排查。

3.1 查看是否数据倾斜

在实践中，很多情况下的反压是由于数据倾斜造成的，这点我们可以通过 Web UI 各个 SubTask 的 Records Sent 和 Record Received 来确认，另外 Checkpoint detail 里不同 SubTask 的 State size 也是一个分析数据倾斜的有用指标。

（关于数据倾斜的详细解决方案，会在下一章节详细讨论）

3.2 使用火焰图分析

如果不是数据倾斜，最常见的问题可能是用户代码的执行效率问题（频繁被阻塞或者性能问题），需要找到瓶颈算子中的哪部分计算逻辑消耗巨大。

最有用的办法就是对 TaskManager 进行 CPU profile，从中我们可以分析到 Task Thread 是否跑满一个 CPU 核：如果是的话要分析 CPU 主要花费在哪些函数里面；如果不是的话要看 Task Thread 阻塞在哪里，可能是用户函数本身有些同步的调用，可能是 checkpoint 或者 GC 等系统活动导致的暂时系统暂停。

开启火焰图功能

Flink 1.13 直接在 WebUI 提供 JVM 的 CPU 火焰图，这将大大简化性能瓶颈的分析，默认是不开启的，需要修改参数：

bash 复制代码

rest.flamegraph.enabled: true #默认 false

也可以在提交时指定：

bash 复制代码

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \
-Drest.flamegraph.enabled=true \
-DYarn.application.queue=test \
-Drest.flamegraph.enabled=true \
-Djobmanager.memory.process.size=1024mb \
-Dtaskmanager.memory.process.size=2048mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

WebUI 查看火焰图

火焰图是通过对堆栈跟踪进行多次采样来构建的。每个方法调用都由一个条形表示，其中条形的长度与其在样本中出现的次数成正比。

On-CPU: 处于 [RUNNABLE, NEW] 状态的线程
Off-CPU: 处于 [TIMED_WAITING, WAITING, BLOCKED] 的线程，用于查看在样本中发现的阻塞调用。

分析火焰图

颜色没有特殊含义，具体查看：

纵向是调用链，从下往上，顶部就是正在执行的函数
横向是样本出现次数，可以理解为执行时长。

看顶层的哪个函数占据的宽度最大。只要有 "平顶"（plateaus），就表示该函数可能存在性能问题。

如果是 Flink 1.13 以前的版本，可以手动做火焰图：

如何生成火焰图：如何生成 Flink 作业的交互式火焰图？ | zhisheng的博客

3.3 分析 GC 情况

TaskManager 的内存以及 GC 问题也可能会导致反压，包括 TaskManager JVM 各区内存不合理导致的频繁 Full GC 甚至失联。通常建议使用默认的 G1 垃圾回收器。

可以通过打印 GC 日志（-XX:+PrintGCDetails），使用 GC 分析器（GCViewer 工具）来验证是否处于这种情况。

在 Flink 提交脚本中，设置 JVM 参数，打印 GC 日志：

bash 复制代码

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \
-Drest.flamegraph.enabled=true \
-Denv.java.opts="-XX:+PrintGCDetails -XX:+PrintGCDateStamps" \
-DYarn.application.queue=test \
-Djobmanager.memory.process.size=1024mb \
-Dtaskmanager.memory.process.size=2048mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

下载 GC 日志的方式：

因为是 on yarn 模式，运行的节点一个一个找比较麻烦。可以打开 WebUI，选择 JobManager 或者 TaskManager，点击 Stdout，即可看到 GC 日志，点击下载按钮即可将 GC 日志通过 HTTP 的方式下载下来。

分析 GC 日志：

通过 GC 日志分析出单个 Flink Taskmanager 堆总大小、年轻代、老年代分配的内存空间、Full GC 后老年代剩余大小等，相关指标定义可以去 Github 具体查看。

GCViewer 地址：https://github.com/chewiebug/GCViewer

Linux 下分析：

bash 复制代码

java -jar gcviewer_1.3.4.jar gc.log

Windows 下分析：

直接双击 gcviewer_1.3.4.jar，打开 GUI 界面，选择 gc 的 log 打开

扩展：

最重要的指标是 Full GC 后，老年代剩余大小这个指标，按照《Java 性能优化权威指南》这本书 Java 堆大小计算法则，设 Full GC 后老年代剩余大小空间为 M，那么堆的大小建议 3 ~ 4 倍 M，新生代为 1 ~ 1.5 倍 M，老年代应为 2 ~ 3 倍 M。

3.4 外部组件交互

如果发现我们的 Source 端数据读取性能比较低或者 Sink 端写入性能较差，需要检查第三方组件是否遇到瓶颈，还有就是做维表 join 时的性能问题。

例如：

Kafka 集群是否需要扩容，Kafka 连接器是否并行度较低
HBase 的 rowkey 是否遇到热点问题，是否请求处理不过来
ClickHouse 并发能力较弱，是否达到瓶颈

关于第三方组件的性能问题，需要结合具体的组件来分析，最常用的思路：

异步 io + 热缓存来优化读写性能
先攒批再读写

维表 join 参考：
Apache Flink学习网
 维度数据实时关联的实践（w/ Flink、Vert.x & Guava Cache） - 简书

总结

本文全面深入地探讨了 Flink 网络流控及反压相关内容。首先对反压进行了清晰的界定，明确其是由于下游消费速率跟不上上游生产速率，致使数据在节点间传输受阻而产生的现象，并阐述了其在诸如负载高峰、垃圾回收停顿、大促活动等场景下容易出现，以及对 checkpoint 时长和 state 大小可能造成的严重危害。接着详细介绍了定位反压节点的两大有效途径，一是借助 Flink Web UI，通过其反压监控功能在不同版本下对 SubTask 级别的反压状态进行判断，并依据相关频率或颜色数值信息确定反压程度，同时结合对瓶颈算子的分析思路进一步排查；二是利用 Metrics，主要依据与 Channel 接受端 Buffer 使用率相关的指标，如 outPoolUsage、inPoolUsage 等，通过分析这些指标的不同组合情况精准定位反压的位置与传导方向。在反压原因及处理方面，依次从数据倾斜、火焰图分析、GC 情况以及外部组件交互等多个维度展开论述。通过 Web UI 查看 SubTask 的 Records Sent 和 Record Received 以及 Checkpoint detail 里的 State size 可判断是否数据倾斜；利用 Flink 1.13 及以上版本在 WebUI 提供的 JVM CPU 火焰图或手动生成火焰图（1.13 以前版本）来分析用户代码执行效率问题；通过打印 GC 日志并借助 GCViewer 工具分析 TaskManager 的内存与 GC 问题；针对 Source 端或 Sink 端与第三方组件交互时出现的性能问题，如 Kafka 集群、HBase、ClickHouse 等，提出了异步 io + 热缓存、先攒批再读写等常用优化思路以及维表 join 的参考方案。通过对这些内容的深入研究与实践应用，能够有效提升 Flink 作业在网络流控及反压处理方面的能力，确保系统在复杂数据处理环境下的稳定性与高效性，为大数据处理任务的顺利完成奠定坚实基础。