Flink非对齐checkpoint原理(Flink Unaligned Checkpoint)
为什么提出Unaligned Checkpoint(UC)?
因为反压严重时会导致Checkpoint失败,可能导致如下问题
- 恢复时间长-服务效率低
- 非幂等和非事务会导致数据重复
- 持续反压导致任务加入死循环(可能导致数据丢失,例如超过kafka的过期时间无法重置offset)
UC的原理
UC有两个阶段(UC主要是快速超越buffer data)
-
第一阶段:UC同步阶段(任意一个barrier加入缓冲区即开始UC,barrier 直接超越所有input和outputBuffer(算子暂停处理数据))
- barrier超越
- 对buffer进行引用
- 调用算子snapshot state
- 引用state
-
第二阶段:异步阶段(等待所有input channel的barrier都到达)
- 写算子的state(同步阶段引用的state)
- 同步阶段引用的input&output buffer
- 写其它inputChannel Barrier之前的buffer(如下图中蓝色f和G)
- 汇报给jobmanager
UC已进行的优化
Task原理
Task处理逻辑如下,线程可能卡在结果输出影响UC
优化一
优化:判断有空闲output buffer再处理数据
需要多个buffer时还是会卡住,比如flatmap操作
优化二
优化:使用OverDraft Buffer透支Buffer,一旦透支buffer则不能处理数据(1.16已有透支Buffer功能)
其它优化
优化:Legacy Source(Legacy Source 是 Flink 中的一种数据源,它是在 Flink 1.0 版本中引入的,并在后续版本中被视为过时的来源)兼容UC
小结
- 等待空闲Buffer+引入透支overdraft Buffer解决卡顿问题
- Legacy source兼容等待空闲Buffer逻辑
UC风险
- 序列化不兼容,无法重启
- 算子连接变化UC无法恢复
- Data Buffer会写大量小文件,导致DataNode压力过大
- 使用Task共享文件(execution.checkpointing.channel-state.number-of-tasks-share-file)
- 会出现死锁或内存泄漏
UC&AC对比
优化:在AC超时自动切换到UC(1.11版本开始)
配置方法(1.11以后版本)
execution.checkpointing.aligned-checkpoint.timeout: 10m
execution.checkpointing.unaligned-checkpoint.enabled: true
参考文档
https://www.bilibili.com/video/BV1tR4y1y7gQ/?spm_id_from=…search-card.all.click&vd_source=a52a4a5afaf8d47cb48d828c7e22e5f1