增量checkpoint是否可以用来恢复flink作业

["casel.chen" <ca...@126.com>]

增量checkpoint是否可以用来恢复flink作业? 
增量checkpoint我理解是有一个base checkpoint + 若干个delta checkpoint (中间会做一次全量checkpoint以截断过长的血缘吗？），恢复的时候需要从base checkpoint开始一个个按时间顺序应用delta checkpoint。
按这样的话，每个delta checkpoint都需要保留才可以恢复状态，但现实并不是所有checkpoint都保留，所以我觉得增量checkpoint是不能用来恢复flink作业的，这样理解对吗？

Re: 增量checkpoint是否可以用来恢复flink作业

[liwei li <hi...@gmail.com>]

增量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 <ca...@126.com> 于2021年10月28日周四 上午10:48写道：

> 增量checkpoint是否可以用来恢复flink作业?
> 增量checkpoint我理解是有一个base checkpoint + 若干个delta checkpoint
> (中间会做一次全量checkpoint以截断过长的血缘吗？），恢复的时候需要从base checkpoint开始一个个按时间顺序应用delta
> checkpoint。
> 按这样的话，每个delta
> checkpoint都需要保留才可以恢复状态，但现实并不是所有checkpoint都保留，所以我觉得增量checkpoint是不能用来恢复flink作业的，这样理解对吗？