共计 1441 个字符，预计需要花费 4 分钟才能阅读完成。
摘要： 反压是 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 分区流入的数据量不平均。难道就是这么简略的问题？
很可怜并不是，通过进一步剖析源端数据咱们发现 Kafka 6 个分区数据流入记录数相差并不大。这两个 Task 只是多生产了局部存量数据，接收数据增长的速度各 TaskManager 保持一致。
时钟同步
进一步剖析 TaskManager 日志，咱们发现单个分片数据写入 OBS 居然消耗 3min 以上。这十分异样，要晓得单个分片数据才 500000 条而已。
进一步通过剖析代码发现如下问题：在写 OBS 数据时，其中一个 taskmanager 写分片目录后获取该目录的最初批改工夫，作为解决该分片的开始工夫，该工夫为 OBS 服务端的工夫。
后续其余 taskmanager 向该分片目录写数据时，会获取本地工夫与分片开始工夫比照，距离大于所规定的转储周期才会写分片数据。
如果集群节点 NTP 工夫与 OBS 服务端不同步，本地工夫晚于 OBS 服务端工夫，则会造成写入 OBS 期待。
后续排查集群节点，发现 6 个节点中一半工夫同步有问题，这也和只有一半 taskmanager 反压重大的景象绝对应。
问题修复
在集群节点上执行如下命令，强制工夫同步。
systemctl stop ntp
ntpdate ntp.myhuaweicloud.com
systemctl start ntp
systemctl status ntp
dateNTP 同步后，作业反压很快隐没，故障复原。
点击关注，第一工夫理解华为云陈腐技术~
