生产环境踩坑记：如何优雅且安全地清理 Flink 过期 Checkpoint 目录？

在 Flink 生产环境的长期运维中，状态（State）的管理往往是最容易让人掉头发的地方。

为了保障任务在依赖组件（如 HDFS、Kafka）升级或任务逻辑微调时能快速恢复，我们通常会将 Flink 的 Checkpoint 保留策略配置为RETAIN_ON_CANCELLATION。相比于动辄耗时十几分钟的 Savepoint，Checkpoint 的恢复速度（通常在 1~2 分钟内）对线上高可用至关重要。

然而，这也引入了一个棘手的运维痛点：随着任务的重启和演进，HDFS 上会遗留大量不再使用的 Checkpoint 目录。对于动辄数百 GB 甚至 TB 级别的大状态任务，如果不加以清理，HDFS 的存储空间很快就会面临枯竭。

本文将从笔者在生产环境经历的一次“灵异”故障说起，带你深入剥开 Flink 基于 RocksDB 增量 Checkpoint 的黑盒，并给出一套彻底闭环的 Checkpoint 清理架构策略。

一、 案发现场：经验主义的“天真”清理策略

最初，为了节省 HDFS 空间，我们设计了一个看起来非常符合逻辑的定时清理脚本：

初代理论：基于时间衰减的启发式清理我们通过 HDFS API 扫描/user/flink/checkpoints目录。对于一个正在运行的任务，每次 Checkpoint 都会更新其所在 JobId 目录的Last Modified时间。 如果一个 JobId 目录的最后