admin管理员组

文章数量:1618711

flink 出现反压场景，异常场景造成Exceeded checkpoint tolerable failure threshold.


监控反压情况

根据算子的InPool, OutPool 的比例， 可以看出是在哪个算子出现了反压

反压造成的原因：

具体的现象：

1：加载配置

现象： 有一次 flink KeyedBroadcastProcessFunction 类里的open 方法加载 全量hbase 配置信息时， 有一个function代码解析耗时10分支以上，超过了checkpoint时长， 导致 checkpoint失败，
整个数据流出现了反压现象， 不能往下走，
解决方案： 优化慢的function代码

2： flink 自定义写hdfs 的addsink 方法里 出现了挤压现象，

现象： flink 自定义写hdfs 的addsink 方法处理慢，出现了挤压现象；导致上游反压，后排查发现时 addsink 里面有一个解析rawtrace方法耗时很长， 同时RichSinkFunction 是和平行度一样的线程数， 导致出现了阻塞
解决方案： 把解析rawtrace代码放在了keyby， map里， keyby是按照traceId， 将解析rawtrace 放在procesfuntion里， 每来一条数据就解析一次， 而不是在最后写入的时候去解析，这样不会出现阻塞的现象

3： flink 写入hbase，

现象： 自定义addsink，开始是一条数据写入一次， 当高峰值时，大量的indicator数据需要写入， 导致反压严重， 最后消费写入时间超过了checkpoint， flink job 出现了checkpoint 超时现象。 job 内部重启

 解决方案： 自定义翻滚窗口触发器，按照条数和时间触发，批量写入hbase

4： flink job 处理业务逻辑长 run

现象： 比如24个小时的窗口数据，缓存，一个机台可能有1000个传感器，每个传感器一秒一条数据； keby机台，出现了数据倾斜的现象， 最后导致一个并行度处理， checkpoint超时， flink job 挂掉，
解决方案： 优化1： 自定义keby将1000个拆分到不同的分区， 比如按照50分成一组，解决数据倾斜， 优化2： 一个run 2

本文标签： 场景异常exceededFlinkfailure

版权声明：本文标题：flink 出现反压场景， 异常场景造成Exceeded checkpoint tolerable failure threshold. 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/xitong/1728782859a1172947.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。