Databricks执行OPTIMIZE优化Delta表后出现事务日志报错如何处理

两个报错均为Delta表事务日志（存储于表路径下_delta_log目录）损坏或缺失导致，具体触发原因如下：

• 你的单表数据量达110亿行，执行OPTIMIZE + ZORDER操作时需要重写全表数据并生成新的事务日志版本，若集群资源不足（内存/CPU不够、并行度设置不合理）导致优化任务异常中断，Delta的原子提交逻辑未完成，会出现事务日志写入不完整、甚至原有日志被损坏的情况：f_em表的事务日志整体丢失，f_dial表的事务日志缺失必要的版本文件。
• 若执行优化操作期间有并发的表写操作（如overwrite、删表操作），或者手动/自动清理脚本误删了_delta_log目录下的文件，也会触发同类报错。你提到的日志保留策略触发截断的概率极低，因为新写入的表远未达到默认30天的日志保留周期。

分两种场景处理：

场景1：仍保留写入两张表的原始源数据（即代码中的f_em、f_dial数据集） #

这是最稳妥的修复方案，操作步骤如下：

1. 先删除已损坏的表及对应存储路径文件：

# 删表
spark.sql("DROP TABLE IF EXISTS rens.f_em")
spark.sql("DROP TABLE IF EXISTS rens.f_dial")
# 删存储路径残留文件
dbutils.fs.rm("dbfs:/user/hive/warehouse/rens.db/f_em", recurse=True)
dbutils.fs.rm("dbfs:/user/hive/warehouse/rens.db/f_dial", recurse=True)

2. 重新执行原始Delta表写入代码，写入完成后再执行优化操作，优化前需确保集群配置足够资源（加大Executor内存、核数，调整并行度），避免任务异常中断。

场景2：无原始源数据，需基于现有存储文件修复 #

修复f_dial表 #

• 首先检查是否有_delta_log目录的备份，若有，将缺失的00000000000000000000.json文件放回对应目录即可恢复。
• 无备份的情况下执行Delta表修复命令：

-- 先执行 dry run 检查可修复的文件
FSCK REPAIR TABLE rens.f_dial DRY RUN
-- 确认无问题后执行实际修复，会扫描全表数据文件重建事务日志
FSCK REPAIR TABLE rens.f_dial

修复f_em表 #

该表无可用事务日志，可通过扫描路径下的Parquet数据文件重建Delta表：

# 读取路径下所有parquet文件
df = spark.read.format("parquet").load("dbfs:/user/hive/warehouse/rens.db/f_em")
# 覆盖写入为Delta表
df.write.format("delta").mode("overwrite").saveAsTable("rens.f_em")

• 大表执行OPTIMIZE前先备份_delta_log目录
• 超大表优先按分区分批执行优化，避免全表重写压力过大
• 优化操作执行期间禁止对表执行其他写操作，不要手动删除_delta_log下的任何文件

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