Flink反压排查及解决方案

一、Flink反压

1、反压的理解

处理速度小于生产速度，然后数据逐级向上游进行传递阻塞，最后传到source端。

2、反压的危害

数据积压导致网络延迟越来越高，影响到checkpoint 时长和 state 大小，导致资源耗尽甚至系统崩溃。

3、反压的定位

最早通过Flink的监控框架prometheus(监控)+grafana（可视化、配置告警）发现反压。 ​ 然后先把operator chain禁用，方便定位到具体算子。利用 Flink Web UI 定位，通过查看subtask的反压监控，反压状态为HIGH红色的subtask即处于反压。 ​ 还可以利用Metrics定位，根据指标分析反压，进一步分析数据传输。

4、反压算子的分析

原因一：该节点的发送速率跟不上它的生产速率。（例如：flatmap）那么该节点是反压的根源节点。 ​ 原因二：下游的节点接受速率较慢，通过反压机制限制了该节点的发送速率。此时需要继续排查下游节点，一直找到第一个为OK的一般就是根源节点。（比较常见）

5、反压的原因和处理

如果通过Flink Web UI查看subtask的反压情况有红有绿 ----> 原因：数据倾斜。

如果通过Flink Web UI查看subtask的反压情况为全红： ​ 原因一：算子内部与第三方数据库交互。---->解决方法：旁路缓存+异步IO ​ 原因二：没有交互，是由于资源不足。----> 解决方法：加资源(内存 --> 分析GC情况、CPU -->使用火焰图分析)

二、Flink数据倾斜

1、问题发现

发现一：通过Flink Web UI 可以精确得看到每个Subtask处理的数据量，来判断Flink任务是否存在数据倾斜。 ​ 发现二：通过Flink Web UI查看任务的反压情况，如果只有个别Subtask呈现反压情况，有红有绿，可以推断出数据倾斜。

2、分析解决

情况一：keyby前数据倾斜。 ​ 原因：从source数据源读取到的数据本身就是倾斜的。 ​ 解决：消费到数据以后调用rebalance进行重分区将数据均匀分配。

情况二：keyby后数据倾斜。 ​ 解决： ​ 方法一：直接聚合。 ​ 通过状态+定时器进行预聚合（时效性会降低）。 ​ 方法二：开窗聚合。 ​ 加随机数打散实现双重聚合。 ​ 第一阶段聚合：key拼接随机数进行keyby、开窗、聚合 ​ 第二阶段聚合：key拼接窗口信息进行keyby、聚合

三、Flink SQL优化

1、设置空闲状态保留时间

使用到状态的时候就需要考虑这个状态能不能删，什么时候删，防止出现状态爆炸。

2、开启MiniBatch微批处理

先缓存一定的数据后再触发处理，以减少对State的访问，从而提升吞吐量并减少数据的输出量。 ​ 设置参数：开启MiniBatch，设置批量输出的间隔时间，设置每个批次最多缓存数据的条数（可以设置为两万条）。

3、开启LocalGlobal

即提前进行预聚合。LocalGlobal优化需要先开启MiniBatch。开启LocalGlobal需要UDAF实现Merge方法。

4、开启Split Distinct

要结合MiniBatch一起使用。 ​ 设置参数：开启Split Distinct，设置第一层打散的bucket数目。默认1024。

5、多维DISTINCT使用Filter

                        
原文链接：https://blog.csdn.net/2302_76749443/article/details/134250267