flink checkpoints 默认是增量还是全量的？

Flink的checkpoints默认是增量的。

Flink作为一款流处理框架，其容错机制主要依赖于checkpoints。以下是关于Flink checkpoints的详细解释：

1. 增量备份：Flink在默认设置下执行的是增量备份。这意味着在每次checkpoint时，并不会保存所有状态的完整快照，而是只保存自上一次成功checkpoint之后发生变化的那部分数据。这可以显著减少每次checkpoint所需要的时间和存储空间。
2. RocksDB：Flink的增量checkpoint以RocksDB为基础，RocksDB是一个基于日志结构合并树（LSM）的键值存储系统。它通过将修改保存在内存中的可变缓存里，并在适当的时候将其写入磁盘，从而实现了高效的增量备份。
3. 配置选项：虽然Flink默认保留一个成功的checkpoint，但用户可以通过配置state.checkpoints.num-retained来保留多个checkpoints。这样做的好处是可以提供更多的恢复点，以防最新的几个checkpoints失败或损坏。
4. 故障恢复：如果作业发生异常，Flink的JobMaster会指示所有的task从上一个成功的checkpoint恢复状态。无论是全量还是增量checkpoint，这一过程对于用户来说是透明的。
5. 性能监控：在进行checkpointing时，可以监控当前checkpoint的状态大小以及在barrier对齐阶段缓冲了多少数据。这些信息有助于评估checkpoint的性能和效率。

综上所述，Flink的checkpoints在默认情况下是增量的，这有利于提高checkpoint的效率并减少对系统资源的影响。用户可以根据需要调整配置以满足不同的容错和恢复需求。

增量
--此回答整理自钉群“实时计算Flink产品交流群”

Flink的checkpoints默认是全量的。

在 Flink 中，checkpoint 是一种机制，用于保证应用程序状态的一致性和可恢复性。Flink 最初只支持全量 checkpoint，即每个 checkpoint 都包含应用程序的完整状态。这种模式对于状态规模较大的作业来说，会导致 checkpoint 操作耗时较长，对性能有一定影响。为了解决这个问题，Flink 引入了增量 checkpoint 的概念。

增量 checkpoint 仅记录两个连续 checkpoint 之间状态的变化，而不是每次 checkpoint 都保存全部状态。这大大减少了数据传输和存储的开销，提高了 checkpoint 的效率。用户反馈显示，在使用 TB 级别状态的作业中，增量 checkpoint 能够将 checkpoint 时间从几分钟减少到几十秒。

需要注意的是，增量 checkpoint 目前只能在 RocksDB StateBackend 上使用，并且需要通过设置构造函数的一个参数来启用。此外，Flink 会自动清理旧的 checkpoint 文件，以防止增量 checkpoint 的历史记录无限增长。

总的来说，虽然 Flink checkpoints 的默认行为是全量的，但增量 checkpoint 提供了一个性能更优的选择，特别是对于那些状态规模很大的作业。