摘要：反压是 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 ntpntpdate ntp.myhuaweicloud.comsystemctl start ntpsystemctl status ntpdateNTP同步后，作业反压很快隐没，故障复原。
点击关注，第一工夫理解华为云陈腐技术~