背景：通过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的大部分反压原因是因为业务代码导致的，所以要仔细考虑业务代码