flink checkpoint机制及非barrier对齐

注：本文部分内容为转载总结

在flink的世界观里，一切事物都可以视为数据流中的一个个珠子，在算子间不断的流动着，之前的watermark就可以看做数据流中的一个数据珠子，同样checkpoint也不例外。

在多个并行度的数据流经算子内联的barrier(检查点分界线)时，会将自己的位置保存进状态后端(state backend)，生产中一般将状态保存进hdfs，rocksdb中，如果数据源是kafka，那么稳定存储的就是kafka的offset，如下图所示，checkpoint流经keyby算子后保存了当前的位置，后面经过map算子时，保存了checkpoint流过算子时的数据状态，同样作为稳定存储进状态后端，当任务出现异常时，就可以从状态后端中将数据流还原到未出错前的样子：

但是，屏障对齐是阻塞式的，在作业出现反压时可能会成为不定时炸弹。我们知道，检查点屏障是从Source端产生并源源不断地向下游流动的。如果作业出现反压（哪怕整个DAG中的一条链路反压），数据流动的速度减慢，屏障到达下游算子的延迟就会变大，进而影响到检查点完成的延时（变大甚至超时失败）。如果反压长久不能得到解决，快照数据与实际数据之间的差距就越来越明显，一旦作业failover，势必丢失较多的处理进度。另一方面，作业恢复后需要重新处理的数据又会积压，加重反压，造成恶性循环。

为了规避风险，Flink 1.11引入了非对齐检查点（unaligned checkpoint）的feature。

非对齐检查点取消了屏障对齐操作：

1. 当算子的所有输入流中的第一个屏障到达算子的输入缓冲区时，立即将这个屏障发往下游（输出缓冲区）。
2. 由于第一个屏障没有被阻塞，它的步调会比较快，超过一部分缓冲区中的数据。算子会标记两部分数据：一是屏障首先到达的那条流中被超过的数据，二是其他流中位于当前检查点屏障之前的所有数据（当然也包括进入了输入缓冲区的数据），如下图中标黄的部分所示。
3. 将上述两部分数据连同算子的状态一起做异步快照。

不同检查点的数据都混在一起，非对齐检查点还是能保证exactly once。当任务从非对齐检查点恢复时，除了对齐检查点也会涉及到的Source端重放和算子的计算状态恢复之外，未对齐的流数据也会被恢复到各个链路，三者合并起来就是能够保证exactly once的完整现场了。

非对齐检查点主要缺点有二：

• 需要额外保存数据流的现场，总的状态大小可能会有比较明显的膨胀（文档中说可能会达到a couple of GB per task），磁盘压力大。当集群本身就具有I/O bound的特点时，该缺点的影响更明显。

• 从状态恢复时也需要额外恢复数据流的现场，作业重新拉起的耗时可能会很长。特别地，如果第一次恢复失败，有可能触发death spiral（死亡螺旋）使得作业永远无法恢复。

官方当前推荐仅将它应用于那些容易产生反压且I/O压力较小（比如原始状态不太大）的作业中。随着后续版本的打磨，非对齐检查点肯定会更加好用。