Flink Checkpoint 中的通用增量Checkpoint

知识点

状态

算子需要记录之前数据处理的中间结果，把中间结果暂时缓存在算子的内部，这就是算子的状态。

为了避免算子挂掉，状态丢失，就需要重头开始进行Flink作业，这样效率太差，为了解决算子挂掉导致状态丢失无法恢复算子、算子状态的问题，周期性的对算子状态进行snapshot，这就是Flink的CheckPoint机制

Flink容错恢复

因为Checkpoint是频发的，所以Checkpoint过程要尽可能轻量、稳定且能够保证成功。

容错恢复过程有以下几个方面

周期性的 Checkpoint

错误检测 Failure Detected

如果某个节点挂了，就需要快速的发现这个失败节点，并完成相应的清理工作

重新调度 Re-scheduling

生成新的作业并重新调度，最后完成部署

状态恢复 State Recovery

作业重新调度起来以后，就需要从最新的快照中把算子的中间状态恢复起来

通用增量Checkpoint

Generic Log-based Incremental Checkpoints

算子在更新自身状态时，会将状态更新结果记录到状态表中

快照异步上传到DFS的时间和状态表的大小正相关，时间非常长并且不可控

为了解决这个问题引入了通用增量Checkpoint机制

解耦状态表和增量日志上传过程

在维护原有状态表的同时，记录一份增量状态更新日志（Change Log）

原有的算子状态快照的过程有两个部分
第一个部分是同步对算子进行快照，这个过程中内存的数据会刷写到磁盘，准备好上传到DFS的文件

第二个部分就是异步上传快照文件

存在的问题

1. 异步上传的文件大小严重依赖StateBackend的实现
2. 在同步快照结束前，是无法开始异步上传过程的，整个异步上传过程要等到同步过程结束后才能进行

对于第一个问题，以RocksDB为例，虽然说RocksDB支持增量快照，但是RocksDB因为自身的实现机制，需要对文件Compaction，每次Compaction都会产生新的比较大的文件，这种情况下即使是增量的Checkpoint也会时不时的使需要上传的Checkpoints文件变得比较大，如果并发比较大的情况下，上传文件时不时变大导致的问题就会很严重，因为只有等所有并发上传的文件都上传完毕，一个完整的算子状态才算是快照完成。

对于第二个问题，状态同步快照结束前无法开始异步上传过程，会导致较大的作业延迟

针对以上两个问题新的通用增量Checkpoint机制
算子状态更新时不仅会更新状态表，还会记录状态更新日志，这样的话状态表还是会周期性的刷新到DFS中，但是这个周期可以变得比较大，比如10分钟，状态表在后台慢慢的进行上传，这个过程称之为物化过程物化过程。同时这个状态更新日志也会不断的上传到远端DFS，并且在Checkpointing的时候Flush剩余的全部日志。

通过将状态快照过程和物化过程完全的独立开来，可以让异步上传的文件大小变得很稳定，同时因为状态更新是持续的，可以在快照之前就一直持续的上传、更新，所以在快照的时候实际上需要上传的数据量就会变得很小。物化过程结束后，相对应的更新日志可以被删除。

Change Log Storage ，DSTL（Durable Short-term Log）

DSTL的几个特性：
持久化
高频写
写延迟
一致性

待定…

资料：

Flink 1.15 新功能架构解析：高效稳定的通用增量 Checkpoint