如何处理分析 Flink 作业反压的问题？

​​摘要： 反压是 Flink 应用运维中常见的问题，它不仅意味着性能瓶颈还可能导致作业的不稳定性。

本文分享自华为云社区《一个Flink作业反压的问题分析》，原文作者：Yunz Bao 。

反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。

问题场景

客户作业场景如下图所示，从 DMS kafka 通过 DLI Flink 将业务数据实时清洗存储到 DWS。

​其中，DMS Kafka 目标 Topic 6 个分区，DLI Flink 作业配置 taskmanager 数量为 12，并发数为 1。

问题现象

客户在 DLI 服务共有三个相同规格的队列，该作业在其中 003 号队列上运行正常，在 001 和 002 号队列上都存在严重的反压导致数据处理缓慢。作业列表显示如下图，可以看到 Sink 反压状态正常，Souce 和 Map 反压状态为 HIGH。

问题分析

根据反压情况分析，该作业的性能瓶颈在 Sink，由于 Sink 处理数据缓慢导致上游反压严重。

该作业所定义的 Sink 类型为 DwsCsvSink，该 Sink 的工作原理如下图所示：Sink 将结果数据分片写入到 OBS，每一分片写入完成后，调用 DWS insert select sql 将 obs 路径下该分片数据 load 到 dws。

因此性能瓶颈出现在分片数据写入到 OBS 这一步。但问题来了，写同一个桶，为什么在不同队列上的表现不一致？

为此，我们排查了各个队列的 CPU、内存和网络带宽情况，结果显示负载都很低。

这种情况下，只能继续分析 FlinkUI 和 TaskManager 日志。

数据倾斜？

然后我们在 FlinkUI 任务情况页面，看到如下情况：Map 阶段的 12 个 TaskManager 并不是所有反压都很严重，而是只有一半是 HIGH 状态，难道有数据倾斜导致分配到不同 TaskManager 的数据不均匀？

然后看 Source subTask 详情，发现有两个 TaskManager 读取的数据量是其他几个的几十倍，这说明源端 Kafka 分区流入的数据量不均匀。难道就是这么简单的问题？

很不幸并不是，通过进一步分析源端数据我们发现 Kafka6 个分区数据流入记录数相差并不大。这两个 Task 只是多消费了部分存量数据，接收数据增长的速度各 TaskManager 保持一致。

时钟同步

进一步分析 TaskManager 日志，我们发现单个分片数据写入 OBS 竟然耗费 3min 以上。这非常异常，要知道单个分片数据才 500000 条而已。

进一步通过分析代码发现如下问题：在写 OBS 数据时，其中一个 taskmanager 写分片目录后获取该目录的最后修改时间，作为处理该分片的开始时间，该时间为 OBS 服务端的时间。

后续其他 taskmanager 向该分片目录写数据时，会获取本地时间与分片开始时间对比，间隔大于所规定的转储周期才会写分片数据。

如果集群节点 NTP 时间与 OBS 服务端不同步，本地时间晚于 OBS 服务端时间，则会造成写入 OBS 等待。

后续排查集群节点，发现 6 个节点中一半时间同步有问题，这也和只有一半 taskmanager 反压严重的现象相对应。

问题修复

在集群节点上执行如下命令，强制时间同步。

systemctl stop ntpntpdate ntp.myhuaweicloud.comsystemctl start ntpsystemctl status ntpdate

NTP 同步后，作业反压很快消失，故障恢复。

点击关注，第一时间了解华为云新鲜技术~