📚 课程目录第4章数据清理原理

数据清理原理：VACUUM如何删除旧版本文件、保留策略与清理机制

核心原理：VACUUM的本质是“文件回收”而非“数据删除”

Delta Lake 的 ACID 事务日志（Transaction Log）记录了每一次提交产生的数据文件版本。当一个表执行 UPDATE、DELETE 或 MERGE 操作时，Delta Lake 并不会修改原始数据文件，而是写入一组新的 Parquet 文件，并在日志中标记旧文件为“逻辑不可见”。这种机制保证了读写隔离与时间旅行能力，但也带来了存储膨胀问题——旧版本文件仍然占据磁盘空间。

VACUUM 命令的核心作用，是物理删除那些已经不再被任何事务版本引用的数据文件。它并不理解行级数据内容，而是基于事务日志中的文件清单，找出“孤儿文件”（即未被当前或保留期内任何快照引用的文件），然后将其从文件系统中移除。因此，VACUUM 是存储层面的垃圾回收器，而非数据清洗工具。

关键认知：VACUUM 永远不会触碰事务日志本身。即使文件被物理删除，日志中仍然保留着对应的提交记录。这意味着，如果尝试通过时间旅行读取一个已被 VACUUM 清理的版本，系统会报错 File not found，而不是返回空结果。

保留策略：VACUUM 的时间窗口与参数控制

VACUUM 默认只清理超过保留期（retention period）的旧版本文件。保留期的默认值为 7 天，这意味着任何小于 7 天的历史版本都可以通过时间旅行访问。这个设计是为了平衡存储成本与数据恢复能力：太短的保留期可能导致无法回滚到较早的版本，太长的保留期则让存储膨胀问题难以缓解。

保留策略的核心参数通过 VACUUM 命令的 RETAIN 子句控制：

-- 清理超过 7 天（默认）的旧文件
VACUUM events_table

-- 清理超过 3 天的旧文件（需谨慎）
VACUUM events_table RETAIN 3 HOURS

-- 清理超过 14 天的旧文件
VACUUM events_table RETAIN 14 DAYS

-- 清理前预览将要删除的文件（不实际执行）
VACUUM events_table DRY RUN

VACUUM 的保留期判断基于文件最后一次被引用的时间，而非文件创建时间。Delta Lake 通过检查事务日志中每个版本的时间戳，确定哪些文件在保留期内仍然“活跃”。如果某个文件在保留期内被任何版本引用，它就不会被删除。

参数/场景	默认值	推荐设置	风险说明
保留期（RETAIN）	7 天	生产环境 7~14 天	过短会导致无法回滚到早期版本
DRY RUN	关闭	首次执行务必开启	直接执行可能误删重要文件
执行频率	手动触发	每日低峰期执行	过于频繁增加元数据扫描开销
时间旅行查询	支持保留期内	与业务审计需求匹配	超出保留期后查询报错

清理机制：VACUUM 的执行流程与文件判定逻辑

VACUUM 的执行过程可以拆解为四个阶段，理解每个阶段有助于排查清理异常或性能问题：

扫描事务日志：从 Delta 日志目录读取所有 checkpoint 和 commit 文件，构建一个“版本 → 文件列表”的映射关系。此阶段需要扫描整个日志目录，表的历史版本越多，耗时越长。
构建活跃文件集合：从最新版本开始向前回溯，收集所有在保留期内被引用的文件路径。这些文件被视为“活跃文件”，不会被删除。
对比文件系统：列出表目录下所有实际存在的 Parquet 文件，与活跃文件集合做差集。差集中的文件即为“孤儿文件”，是 VACUUM 的候选删除对象。
执行删除：对候选文件逐个执行文件系统删除操作。删除是物理性的，文件一旦移除便无法通过任何方式恢复（除非有外部备份）。

实操建议：在生产环境中，建议先执行 VACUUM table_name DRY RUN 查看将要删除的文件列表，确认无误后再执行正式清理。同时，可以结合 DESCRIBE HISTORY table_name 查看表的版本历史，评估保留期设置是否合理。

案例场景：一个真实的 VACUUM 清理过程

假设有一个用户行为日志表 user_events，每天新增约 200 万条记录，并频繁执行 UPDATE 操作修正数据。表运行 10 天后，存储占用从初始的 5GB 膨胀到 42GB。通过 DESCRIBE HISTORY 发现，大量旧版本文件堆积，其中 80% 的文件已超过 7 天未被引用。

执行清理操作：

-- 第一步：预览将要删除的文件
VACUUM user_events DRY RUN

-- 输出示例（截取部分）：
-- +-------------------------------------------------+
-- | file                                             |
-- +-------------------------------------------------+
-- | /data/user_events/part-00001-abc.snappy.parquet |
-- | /data/user_events/part-00002-def.snappy.parquet |
-- | ... (共 1,245 个文件)                            |
-- +-------------------------------------------------+

-- 第二步：确认无误后执行正式清理
VACUUM user_events RETAIN 7 DAYS

-- 清理完成后，存储占用从 42GB 降至 9GB

清理后，存储占用下降了约 78%，同时所有 7 天内的历史版本仍然可以正常查询。这个案例说明，VACUUM 对于高频更新场景下的存储控制至关重要。

误区与复盘：VACUUM 使用中的常见陷阱

严重警告：VACUUM 删除的文件不可恢复。它不像关系型数据库的 DELETE 操作可以回滚，而是直接调用文件系统删除接口。任何误操作都可能导致数据永久丢失，务必在测试环境验证后再应用于生产。

误区一：认为 VACUUM 会清理事务日志。实际上，事务日志会持续增长，VACUUM 只清理数据文件。日志的瘦身需要依赖 checkpoint 机制，而非 VACUUM。
误区二：保留期设置越短越好。如果业务需要支持 30 天的数据回溯审计，而保留期设置为 3 天，那么超过 3 天的历史版本将无法访问，可能导致合规问题。
误区三：频繁执行 VACUUM 能解决所有存储问题。如果表持续进行小批量更新，VACUUM 只能清理已过期的文件，但无法阻止新孤儿文件的产生。根本的优化方向是合并小文件（如使用 OPTIMIZE）或调整写入频率。
误区四：VACUUM 执行期间表不可用。实际上，VACUUM 与读写操作可以并发执行，因为它只删除“孤儿文件”，不会影响当前活跃事务。但需注意，VACUUM 运行期间会占用一定的 I/O 和 CPU 资源。
误区五：DRY RUN 输出为空就代表没有文件可清理。DRY RUN 只显示超过保留期的文件。如果所有文件都在保留期内，输出为空是正常现象，不代表存储没有膨胀。

复盘一个典型事故：某团队将保留期从 7 天改为 1 小时，以快速释放存储空间。执行 VACUUM 后，所有超过 1 小时的历史版本全部被删除。随后业务方需要回溯 3 天前的数据用于故障分析，结果所有查询均报 File not found 错误，最终只能从冷备集群恢复数据，耗时 6 小时。这个案例警示我们：保留期的设置必须与业务的数据恢复需求对齐，而非单纯追求存储效率。