请阐述 Flink 增量 Checkpoint 的实现机制，并说明其相比全量 Checkpoint 的优势以及适用的业务场景。

回答思路

1. 【回答框架 1】增量 Checkpoint 基于 RocksDB 状态后端实现，核心是记录自上次 Checkpoint 以来发生变更的 SST 文件。实现依赖 RocksDB 的 Backend 支持的 Checkpoint 机制，通过持久化当前状态中新增或修改的 SST 文件，并引用之前 Checkpoint 中未变化的文件，从而减少传输和存储数据量。
2. 【回答框架 2】优势在于大幅减少 Checkpoint 期间需要持久化的数据量，缩短 Checkpoint 时长，降低对作业延迟的影响；同时减少网络和存储 I/O，特别适用于状态量巨大、变化较少的作业。
3. 【回答框架 3】应用场景包括状态规模大但更新频率相对较低的场景，如长时间运行的窗口聚合、复杂事件处理中的模式匹配，或需要频繁进行 Checkpoint 以保证恢复点的流处理作业。
4. 【回答框架 4】需注意增量 Checkpoint 依赖 RocksDB，且可能存在多次增量累积导致恢复时需回溯较多文件的问题，需要结合配置文件合理设置 Checkpoint 策略。
5. 【关键点 1】增量 Checkpoint 仅保存自上次 Checkpoint 后变更的 SST 文件。
6. 【关键点 2】实现基础是 RocksDB 状态后端及其文件合并机制。
7. 【关键点 3】优势是减少 Checkpoint 数据量，降低对作业的暂停影响。
8. 【关键点 4】适合状态大、变更频率低的长周期作业。
9. 【关键点 5】依赖 RocksDB，配置和调优需针对性处理。
10. 【易错点 1】误以为增量 Checkpoint 适用于所有状态后端，实际必须以 RocksDB 为后端。
11. 【易错点 2】忽略增量 Checkpoint 可能导致恢复时需要读取多个历史文件，应权衡恢复时间。
12. 【易错点 3】未考虑状态变化频繁时增量 Checkpoint 收益下降甚至不如全量 Checkpoint。