对于Flink增量检查点，如果我理解正确，它将首先创建一个完整的检查点，然后每次在前一个基础上创建一个增量检查点。
这条链会很长吗？恢复时是否需要从第一个完整检查点开始申请？
我听说Flink会定期进行压缩/合并，这是否意味着它将定期创建完整的检查点，因此在还原期间我们无需转到非常旧的完整检查点？如果是这样，什么时候进行压缩/合并？
还有一个问题，Flink是否保存所有检查点文件（包括完整和增量文件）？还是自动删除一些过期的？
谢谢。
答案 0 :(得分：0)
背景：Flink中的增量检查点目前仅受RocksDB状态后端支持，该功能完成了许多繁重的工作。 RocksDB基于日志结构的合并树，这些合并树自然适合于支持增量检查点。
有关RocksDB的简介，请参见https://github.com/facebook/rocksdb/wiki/RocksDB-Basics。
现在提出您的问题：
该链的长度受RocksDB中使用的级别数限制。由于每个级别的大小通常是上一个级别的大小的倍数，因此不需要花费很长的链就可以存储大量数据。 “原始检查点”不是一个整体，它包含在LSM树的多个级别中保存的状态，并存储在一组SST文件中，并且一旦压缩开始，原始检查点就不再以任何可识别的方式存在。
压缩只是RocksDB工作方式的一部分；它不是由Flink实现或为Flink实现的。压缩在后台或多或少地连续发生。
Flink确实会自动删除不再有用的SST文件（检查点包含一组SST文件）。
有关更多信息，请参见Managing Large State in Apache Flink: An Intro to Incremental Checkpointing。