分析Flink,源和算子并行度不一致时,运行一段时间后,看似不再继续消费的问题,提供解决思路。

文章目录


背景

之前有分析过一次类似问题,最终结论是在keyby之后,其中有一个key数量特别庞大,导致对应的subtask压力过大,进而使得整个job不再继续运作。在这个问题解决之后,后续又再次出现了积压的情况,针对这个问题进行排查分析。


分析

通过以下这张图,可以看到当前它是没有数据积压的。

可以看到source-map-map-sink/map都放在了同一个task中,因为Flink的operator chain(算子链)机制,数据是通过调用链接算子的processElement()方法,直接将数据推给下游处理了。这里有300个并行度,也就是有300个subtask,每个算子之间都是一一对应的,如果其中一个并行度的源一直没有消费到数据,那么它的下游就一样会是空闲的

通过这张图可以看到有的subtask根本就没有在处理数据,而有的处理的是大量的数据。那这种肯定不是我们想要的。这种情况,资源存在浪费。

在前后并行度不一致的时候,task之间就会默认采用rebalance做负载均衡

可以看到这种情况下,下游每个task处理的数据是比较平均的,在经过均衡之后

问题来了

到了这里就发现了个问题,竟然出现了严重的阻塞问题。

但仔细一看,并不是所有下游的subtask都是busy。

这种均衡之后部分阻塞的问题,经过代码,和实际的数据结合分析,我得出的结论是有一类数据,需要处理的时间是其他数据的几十倍。rebalance是轮询分配的,在某几个task接收到大量该类数据,导致它的运行压力直线上升,进而使得分配到此处时塞不进去了。即导致整体的阻塞。

比较一开始的情况

那么一开始为什么就没有阻塞呢,这一下就让人非常费解,明明rebalance负载均衡之后应该压力更小,更能够消费得过来才对,怎么现在就消费不来了呢。

在task中看到这样的日志,因为消费不来,很多该类topic的数据被丢弃了,因为没有阻塞,所以其他topic也就都能够正常消费。

解决方式

所以要解决这个问题的根本方式有两种

1、先把同一种数据需要耗费的时间与其他方式耗费时间差距较大的,进行缩小差距。

2、优化代码,让算子中的效率增加,处理每一条数据的时间减小

3、加大资源,增加并行度

相关推荐
Giser探索家1 小时前
无人机桥梁巡检:以“空天地”智慧之力守护交通生命线
大数据·人工智能·算法·安全·架构·无人机
北邮-吴怀玉2 小时前
6.1.2.2 大数据方法论与实践指南-离线任务SQL 任务开发规范
大数据·数据库·sql
笨蛋少年派5 小时前
使用hdfs命令报错:Unknown command:dfs(环境变量正确)
大数据·hadoop·hdfs
深兰科技6 小时前
东方财经报道|深兰科技落户张江,AI医疗与情感陪伴并进,拓展智能未来版图
大数据·人工智能·科技
Apache Flink6 小时前
理想汽车基于 Hologres + Flink 构建万亿级车联网信号实时分析平台
阿里云·flink·apache
格林威6 小时前
AOI在传统汽车制造领域中的应用
大数据·人工智能·数码相机·计算机视觉·ai·制造·aoi
kalvin_y_liu7 小时前
华为ACT三步走”实施路径,以推动行业智能化落地
大数据·人工智能·ai应用
涛思数据(TDengine)9 小时前
杨凌美畅用 TDengine 时序数据库,支撑 500 条产线 2 年历史数据追溯
大数据·时序数据库·tdengine
熊文豪9 小时前
时序数据库选型指南:从大数据视角看高效存储与分析
大数据·数据库·时序数据库
yumgpkpm9 小时前
CMP(类ClouderaCDP7.3(404次编译) )完全支持华为鲲鹏Aarch64(ARM)POC报告
大数据·hive·hadoop·python·elasticsearch·hbase·cloudera