Flink 常见问题汇总：反压积压，checkpoint报错，窗口计算，作业报错，无产出，流批不一致，调优等。

本文链接：https://blog.csdn.net/Direction_Wind/article/details/141101567

Flink 常见问题汇总

0 如何分析日志
1 Flink 作业积压排查流程及解决思路
2 Flink checkpoint失败排查流程
3 Flink 窗口计算问题排查
4 flink内存问题
5 调优
6 Flink 依赖冲突排查
7 常见报错问题
回撤流异常情况

0 如何分析日志

0.1作业内部重启异常，作业正常运行

在 Flink UI 的 Exceptions 页面，直接查看 Root Exception
2. 查看 Flink 的 jobManager 的日志，查看失败的原因
搜索关键字：RUNNING to FAILED 这段关键日志下面就是导致作业失败或者重启的原因(由于 commit 时出现了 io exception 导致)

0.2 作业内部重启，但作业已经手动 kill 整个 yarn-application

当作业发生了重启，但已经手动操作 kill，这样的情况下，Flink 无法将作业的运行信息写入到 HDFS，则无法通过 HistoryServer 查看。

进入 Yarn 的 AppMaster 界面
点击查看 jobManager 所在 container 的日志（如下所示，点击 here 展开全量的日志）

tips:
当并发较多时，jobManager 会产生较多的日志文件，此时在浏览器查看会比较卡，可以有两种方式进行查看。

可以通过 wget 将整个网页直接下载下来，如下所示，去掉 “&start.time=0&end.time=9223372036854775”，结尾为 start=0

wget “http:///container_e36_1638340655551_0550_01_000001/container_e36_1638340655551_0550_01_000001/h_data_platform/jobmanager.log/?start=0”

修改日志 URL 的后缀，然后访问，可以只查看末尾的日志，方便快速查看。

“http:///jobhistory/logs/.bj:22700/container_e36_1638340655551_0550_01_000001/container_e36_1638340655551_0550_01_000001/h_data_platform/jobmanager.log/?start=-1024000”

0.3 作业失败，整个 yarn application 结束运行

进入 Yarn 的 AppMaster 界面, 点击 Tracking URL
2. 通过 HistoryServer 查看 Root Exception
HistoryServer 进入可能比较慢，遇到这种情况可以直接参考上面的日志查看方式。

1 Flink 作业积压排查流程及解决思路

1 反压原因

积压产生的原因可能多种多样，排查作业积压出现的原因，可以参考下面的步骤.
反压其实就是 task 处理不过来，算子的 sub-task 需要处理的数据量 > 能够处理的数据量，比如：

当前某个 sub-task 只能处理 1w qps 的数据，但实际上到来 2w qps 的数据，但是实际只能处理 1w 条，从而反压
常见原因有：

数据倾斜：数据分布不均，个别task 处理数据过多
算子性能问题：可能某个节点逻辑很复杂，比如sink节点很慢，lookup join 热查询慢
流量陡增，比如大促时流量激增，或者使用了数据炸开的函数

2 反压的危害

任务处理性能出现瓶颈：以消费 Kafka 为例，大概率会出现消费 Kafka Lag
Checkpoint 时间长或者失败：因为某些反压会导致 barrier 需要花很长时间才能对齐，任务稳定性差
整个任务完全卡住。比如在 TUMBLE 窗口算子的任务中，反压后可能会导致下游算子的 input pool 和上游算子的 output pool 满了，这时候如果下游窗口的 watermark 一直对不齐，窗口触发不了计算的话，下游算子就永远无法触发窗口计算了，整个任务卡住

3. 定位反压节点

查看WebUI

作业图的 UI 展示，会通过不同颜色和数值代表繁忙和反压的程度，红色表示busy，灰色表示积压，一般是红色的算子处理能力不足。
在这里插入图片描述
作业图的 UI 展示，会通过不同颜色和数值代表繁忙和反压的程度可以通过BackPressure查看 subtask 反压情况

在这里插入图片描述
还可以查看Flink 任务的 Metrics

在这里插入图片描述
我这个是并行度是 4 ，所以会有 0、1、2、3 代表是哪个 subTask（task 下每个并行task），其中看到的比较多的是这两个，outPutUsage 代表发送端 Buffer 的使用率，inPutusage 代表的接收端 Buffer 的使用率

在这里插入图片描述

4. 排查反压原因

我们生产环境中，会遇到负载高峰、CheckPoint、作业重启引起的数据积压而导致反压，这种情况反压如果是暂时的，我们可以忽略它

除了定位反压节点，还需要排查原因

4.1 数据倾斜

我们可以用 Web UI 查看该节点每个 SubTask 的 Record Send 和 Record Received 来看是否数据倾斜，也可以通过 Checkpoint 每个 Subtask 的 state 的 size 大小
在这里插入图片描述

4.2 火焰图

在代码提交时设置开启火焰图，然后可以在 Web UI 里面查看,

rest.flamegraph.enabled: true #默认 false

在这里插入图片描述
纵向是调用链，从下往上，顶部就是正在执行的函数

不是用颜色代表的，而是横向长度，代表出现次数或者说执行时长，某个函数过宽，出现了平顶，那这个函数可能有性能问题

4.3 分析 GC

也可能是 TaskManager 的内存引起的 GC 问题，也会导致反压，我们一般使用 G1 回收机制，有可能是 TaskManager JVM 各区内存分配不合理导致频繁的 Full GC

我们可以提交任务时设置打印 GC 日志然后查看Web UI GC 情况或者直接看日志

-Denv.java.opts=“-XX:+PrintGCDetails -XX:+PrintGCDateStamps”

在这里插入图片描述

4.4 在 Metric 页面，查看 Source 的流入量，可以直观体现作业的处理速度

如果处理速度下降，则说明出现性能瓶颈，或其他原因导致速度下降
如果处理速度不变或是有上涨，说明上游的数据在持续增长

5. 常见处理方案

5.1 常见原因：

是否紧急: 线上作业/测试作业
上游是否有增长: 有增长/无增长
作业 GC 情况： GC 正常/GC非常频繁/GC一般频繁(类似: 15min GC 5min)
是否数据倾斜: 无倾斜/有倾斜/有倾斜但不是核心原因，重点关注空值与空字符串关联
作业的反压task和慢 task: 反压task名+满task名/无明显反压或者慢 task
慢 Task 对应的执行栈: 有明显的慢的线程栈/无明显的线程栈
是否有异常日志: 有异常日志(贴身对应的日志和日志链接)/无异常日志

5.2 常见解决策略

很多时候反压就是资源不足导致的，给任务加资源
如果是数据倾斜、算子性能问题之类，那就去解决这些问题
如果确实是流量过大消费不过来，就调大并行度（如果是kafka，需要同时调大kafka分区数）
限制数据源的消费数据速度。比如在事件时间窗口的应用中，可以自己设置在数据源处加一些限流措施，让每个数据源都能够够匀速消费数据，避免出现有的 Source 快，有的 Source 慢，导致窗口 input pool 打满，watermark 对不齐导致任务卡住
关闭 Checkpoint。关闭 Checkpoint 可以将 barrier 对齐这一步省略掉，促使任务能够快速回溯数据。然后等数据回溯完成之后，再将 Checkpoint 打开，或开启非对其ck：set execution.checkpointing.unaligned=true;
拆分算子链接

SET pipeline.operator-chaining=false;

开启mini-batch:

set table.exec.mini-batch.enabled=true;
set table.exec.mini-batch.allow-latency=1000;
set table.exec.mini-batch.size=200;

设置合理的ttl和ck设置：

–state ttl机制
set state.retention.time.min=3d;
set state.retention.time.max=4d;
set execution.checkpointing.mode=exactly_once;
set execution.checkpointing.interval=6min;
– 超时时间
set execution.checkpointing.timeout=80min;
set execution.checkpointing.min-pause=0ms;
10.set table.exec.source.cdc-events-duplicate=true;

2 Flink checkpoint失败排查流程

排查作业 checkpoint 失败的原因，可以参考下面的步骤.

找到第一次失败的 checkpoint
找到未能完成 checkpoint 的 task 以及对应的 subtask
找到未能 100% 完成 checkpoint 的 task

展开找到未完成的 subtask
找到对应 task 所在的 TaskManager
在 FlinkUI找到对应的 subtask 所在的 TaskManager
点 View TaskManager Log 即可跳转至对应的 TaskManager
结合执行栈找到相应的卡点
具体的解决方案与常见原因，可以参考本人的另一篇帖子：
《Flink checkpoint操作流程详解与报错调试方法汇总，增量checkpoint原理及版本更新变化，作业恢复和扩缩容原理与优化》

2. 如何查看各个taskmanager的checkpoint的执行情况？

查看JobManger日志，有以下日志代表开始执行checkpoint:

2020-09-11 18:56:25.275 INFO  org.apache.flink.runtime.checkpoint.CheckpointCoordinator    - Triggering checkpoint 1 @ 1599821785269 for job e1d818d210f40700760e893cdef96f11.

查看TaskManager日志，有以下日志代表接收到barrier，开始执行checkpoint

2020-09-11 18:56:25.280 INFO  org.apache.flink.streaming.runtime.tasks.StreamTask          - Starting checkpoint (1) CHECKPOINT on task Source: Custom Source -> Flat Map (1/2)
2020-09-11 18:56:25.295 INFO  org.apache.flink.streaming.runtime.tasks.StreamTask          - Starting checkpoint (1) CHECKPOINT on task Keyed Aggregation -> Sink: Print to Std. Out (