Delta Vacuum未清理超期数据：执行450小时保留策略后仍可访问版本22

开发者阿泽

2026-6-14

Delta表Vacuum后旧版本未被清理的原因及排查

以下是可能导致版本22未被Vacuum清理的核心原因及排查方向：

Checkpoint依赖限制
Delta表的Checkpoint文件会引用对应快照的所有数据文件。如果版本22的文件被最近的Checkpoint（默认保留3个）所引用，即使超出你设置的450小时保留期，Vacuum也不会删除这些文件——因为删除会导致Checkpoint失效，进而影响表的恢复和查询性能。你可以查看表的_delta_log目录下的Checkpoint文件（命名格式如000000000000000000XX.checkpoint.parquet），确认是否有Checkpoint包含版本22的文件引用。
版本创建时间计算误差
先确认版本22的实际创建时间：执行DESCRIBE HISTORY <你的表名>查看版本22的timestamp字段。450小时约等于18.75天，假设你在1月31日执行Vacuum，那么保留的是1月31日往前推18.75天（即1月12日左右）之后的版本。如果版本22的创建时间晚于这个时间点，那它本来就不在清理范围内。
活跃事务/查询引用
如果在执行Vacuum时，有正在运行的查询（比如时间旅行查询到版本22）、未提交的事务，或者其他会话持有版本22的文件锁，Vacuum会跳过这些文件的清理，以保证数据一致性。可以检查集群上的活跃任务，确认是否有相关操作在占用版本22的资源。
表级配置覆盖Vacuum参数
Delta表的delta.retentionDuration配置项会覆盖Vacuum命令中的保留时长设置。执行DESCRIBE EXTENDED <你的表名>查看该配置值，如果它设置的时长大于450小时，Vacuum会遵循表级配置，不会清理版本22。
共享数据文件被后续版本引用
若版本22中的某些数据文件被后续版本（比如版本23及之后）复用（例如Merge/Update操作未重写这些文件），只要后续版本在保留期内，这些文件就不会被删除，你自然还能通过版本22访问到这些数据。