增量checkpoint是可以恢复作业的。 Flink 的增量 checkpoint 以 RocksDB 的 checkpoint 为基础。RocksDB 是一个 LSM 结构的 KV > 数据库,把所有的修改保存在内存的可变缓存中(称为 memtable),所有对 memtable 中 key 的修改,会覆盖之前的 value,当前 > memtable 满了之后,RocksDB 会将所有数据以有序的写到磁盘。当 RocksDB 将 memtable > 写到磁盘后,整个文件就不再可变,称为有序字符串表(sstable)。 > RocksDB 的后台压缩线程会将 sstable 进行合并,就重复的键进行合并,合并后的 sstable 包含所有的键值对,RocksDB > 会删除合并前的 sstable。 > 在这个基础上,Flink 会记录上次 checkpoint 之后所有新生成和删除的 sstable,另外因为 sstable 是不可变的,Flink > 用 sstable 来记录状态的变化。为此,Flink 调用 RocksDB 的 flush,强制将 memtable 的数据全部写到 > sstable,并硬链到一个临时目录中。这个步骤是在同步阶段完成,其他剩下的部分都在异步阶段完成,不会阻塞正常的数据处理。 > Flink 将所有新生成的 sstable 备份到持久化存储(比如 HDFS,S3),并在新的 checkpoint 中引用。Flink > 并不备份前一个 checkpoint 中已经存在的 sstable,而是引用他们。Flink 还能够保证所有的 checkpoint > 都不会引用已经删除的文件,因为 RocksDB 中文件删除是由压缩完成的,压缩后会将原来的内容合并写成一个新的 sstable。因此,Flink 增量 > checkpoint 能够切断 checkpoint 历史。 > 为了追踪 checkpoint 间的差距,备份合并后的 sstable 是一个相对冗余的操作。但是 Flink > 会增量的处理,增加的开销通常很小,并且可以保持一个更短的 checkpoint 历史,恢复时从更少的 checkpoint > 进行读取文件,因此我们认为这是值得的。
以上内容引用自:Apache Flink 管理大型状态之增量 Checkpoint 详解 <https://flink-learning.org.cn/article/detail/6636e468bc961f789f8d0ba8ffd51a95> 里面详细介绍了增量checkpoint的原理、容灾恢复以及性能,有兴趣可以参考一下。 casel.chen <casel_c...@126.com> 于2021年10月28日周四 上午10:48写道: > 增量checkpoint是否可以用来恢复flink作业? > 增量checkpoint我理解是有一个base checkpoint + 若干个delta checkpoint > (中间会做一次全量checkpoint以截断过长的血缘吗?),恢复的时候需要从base checkpoint开始一个个按时间顺序应用delta > checkpoint。 > 按这样的话,每个delta > checkpoint都需要保留才可以恢复状态,但现实并不是所有checkpoint都保留,所以我觉得增量checkpoint是不能用来恢复flink作业的,这样理解对吗?