对于 Flink 增量检查点，如果我理解正确，它将首先创建一个完整的检查点，然后每次都会基于前一个创建一个增量检查点。
这条链会超长吗？恢复时，我们是否需要从第一个完整检查点开始申请？
我听说 Flink 会定期进行压缩/合并，这是否意味着它会定期创建一个完整的检查点，这样我们就不需要在恢复过程中转到非常旧的完整检查点？如果是这样，何时进行压缩/合并？
还有一个问题，Flink 是否保存所有检查点文件(包括完整和增量(？或者它会自动删除一些过期的？
谢谢。
背景：Flink 中的增量检查点目前仅由 RocksDB 状态后端支持，它完成了大部分繁重的工作。RocksDB 基于日志结构的合并树，自然而然地支持增量检查点。
有关 RocksDB 的介绍，请参阅 https://github.com/facebook/rocksdb/wiki/RocksDB-Basics。
现在回答您的问题：
链的长度受 RocksDB 中使用的级别数的限制。由于每个级别的大小通常是前一个级别大小的几倍，因此存储大量数据不需要很长的链。"原始检查点"不是一个整体 - 它包括保存在LSM树的多个级别中的状态，并存储在一组SST文件中 - 一旦压缩开始，原始检查点就不再以任何可识别的方式存在。
压缩只是 RocksDB 工作方式的一部分;它不是由 Flink 实现的，也不是为 Flink 实现的。压缩在后台或多或少地连续发生。
Flink 确实会注意自动删除不再有用的 SST 文件(检查点包含一组 SST 文件(。
请参阅在 Apache Flink 中管理大型状态：增量检查点简介了解更多信息。