Flink非对齐checkpoint原理（Flink Unaligned Checkpoint）

为什么提出Unaligned Checkpoint（UC）？

因为反压严重时会导致Checkpoint失败，可能导致如下问题

• 恢复时间长-服务效率低
• 非幂等和非事务会导致数据重复
• 持续反压导致任务加入死循环（可能导致数据丢失，例如超过kafka的过期时间无法重置offset）

UC的原理

UC有两个阶段（UC主要是快速超越buffer data）

1. 第一阶段：UC同步阶段（任意一个barrier加入缓冲区即开始UC，barrier 直接超越所有input和outputBuffer（算子暂停处理数据））

   • barrier超越
   • 对buffer进行引用
   • 调用算子snapshot state
   • 引用state

2. 第二阶段：异步阶段（等待所有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