如何删除Databricks Delta历史文件行？VACUUM无日志问题排查

1. VACUUM本身不生成表版本记录 #

Delta Lake的VACUUM是物理清理类操作，仅负责删除不再被任何有效版本引用的物理数据文件和日志文件，不会生成新的表版本元数据，因此不会出现在DESCRIBE HISTORY的结果中，这是设计特性而非异常。

2. 5小时保留期未触发清理条件 #

VACUUM仅清理满足以下两个条件的文件：

• 文件对应的表版本已超过指定的保留时长（5小时）
• 没有活跃的会话、流作业或其他进程在引用该文件
  如果你的DELETE操作与VACUUM操作的间隔不足5小时，或者仍有流作业、未关闭的Spark会话依赖旧版本数据，VACUUM会跳过这些文件的清理。

3. 逻辑删除未生成可清理的物理文件 #

DELETE操作属于逻辑删除，仅在Delta元数据中生成删除向量（Delete Vectors）标记需要删除的行，不会立即删除物理数据文件。只有当这些文件不再被任何历史版本引用时，VACUUM才会执行物理删除。如果未执行文件合并操作，旧文件可能仍被标记为活跃状态。

• 调整保留时长并确认时间窗口：如果需要立即清理，可将保留时长设为0小时（需确保无其他依赖），命令如下：

  spark.conf.set("spark.databricks.delta.retentionDurationCheck.enabled", "false")
  spark.sql("VACUUM delta.`path_to_table` RETAIN 0 HOURS")
  

  若使用5小时保留期，需确保DELETE操作完成后至少间隔5小时再执行VACUUM。

• 先执行OPTIMIZE合并文件：通过OPTIMIZE操作合并小文件并应用删除向量，将逻辑删除转化为物理文件的替换，让旧文件更快进入可清理状态：

  OPTIMIZE delta.`path_to_table` WHERE code = 20
  

  执行后再运行VACUUM，能有效清理旧的物理文件。

• 验证VACUUM清理效果：使用DRY RUN参数查看VACUUM将清理的文件列表，确认是否有符合条件的文件：

  VACUUM delta.`path_to_table` RETAIN 5 HOURS DRY RUN
  

  也可直接查看表的物理存储路径，检查旧数据文件是否被删除。

• 确保无活跃依赖：暂停引用该表的流作业，关闭所有未使用的Spark会话，避免旧版本数据被持续引用导致无法清理。

• 手动记录审计日志：由于VACUUM不会写入表历史，若需审计该操作，可在脚本中添加自定义日志记录逻辑，将操作时间、执行用户、参数等信息写入指定的审计存储（如另一张Delta表或日志文件）。

内容的提问来源于stack exchange，提问作者Dreekun