背景:通过flink程序消费kafka数据,然后数据经过flink-cdc读进来的维度数据做成状态数据,然后进行匹配,补齐字段后写入到clickhouse大宽表。
提交资源为:-yjm 8192m -ytm 16384m -ys 5 -p 10 ,其中kafka source的并行度设置的跟kafka的分区数一致为3个并行度
flink作业处理流程:
出现的现象:发现clickhouse的数据写入特别慢,使用kafka客户端命令查看kafka消费者组的数据偏移量情况
kafka-consumer-groups --bootstrap-server xxx:9092 --group first_group --describe
TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
first_topic 0 185710 1721891 1536181 - - -
first_topic 2 1721901 1721901 0 - - -
first_topic 1 1721898 1721898 0 - - -
发现 first_topic 主题 中的0号分区出现大量挤压(LAG指标就是挤压数据量)
然后查看flink web作业界面,发现在kafka Source和Filter算子处出现反压,BackPressure 指标显示大部分subTask 都 为 1 - High,在 Co-Process-Broadcast 处是正常的,那么原因就定位到了,是因为 Co-Process-Broadcast 处的操作引起的;
解决方案:
1、禁用掉作业链 ,重新打包作业,观察是哪个算子引起的反压;
2、在 Co-Process-Broadcast 处的是
BroadcastProcessFunction 函数的调用,里面是针对业务逻辑的处理,在处理的时候因为要读取一个外部资源文件(ip地域库),之前的逻辑是每来一条数据都要读一次资源文件,发现问题后修改为读取一次,然后重新提交作业后,flink反压问题解决了,kakfa的数据挤压也就解决了。
总结:
flink的大部分反压原因是因为业务代码导致的,所以要仔细考虑业务代码