admin管理员组文章数量:1618689
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://m.elefans.com/xitong/1728782859a1172947.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论