AWS环境下清理超大规模Delta Log checkpoint及小文件方案咨询

核心结论：优先选择重建新表，而非原地修复 #

原表日志极度膨胀且OPTIMIZE效率低下，直接重建新表是耗时最短、效果最彻底的方案，同时能一次性解决小文件和日志膨胀问题。

步骤1：创建优化后的新Delta表 #

利用Spark高效读写能力，按分区批量迁移数据，同时开启Delta自动优化特性从根源避免小文件：

• 先配置Spark会话参数，强制控制文件大小并开启自动优化：

spark.conf.set("spark.sql.files.maxRecordsPerFile", "1000000") // 按记录数控制文件大小，对应约100MB（单条记录100字节估算）
spark.conf.set("delta.autoOptimize.optimizeWrite", "true")
spark.conf.set("delta.autoOptimize.autoCompact", "true")

• 按utc_date分区批量写入，避免全表一次性写入的资源压力：

// 获取所有分区值
val partitions = spark.sql("SELECT DISTINCT utc_date FROM old_table").collect().map(_.getString(0))
// 逐个分区写入新表
partitions.foreach { date =>
  spark.sql(s"SELECT * FROM old_table WHERE utc_date = '$date'")
    .write
    .mode("append")
    .format("delta")
    .partitionBy("utc_date")
    .save("s3://your-bucket/path-to-new-table")
}

SQL方式批量执行（适合非开发场景）：

SET spark.sql.files.maxRecordsPerFile=1000000;
SET delta.autoOptimize.optimizeWrite=true;
SET delta.autoOptimize.autoCompact=true;

-- 循环执行每个分区的插入语句
INSERT INTO new_table SELECT * FROM old_table WHERE utc_date = '2020-01-01';
INSERT INTO new_table SELECT * FROM old_table WHERE utc_date = '2020-01-02';
-- ... 其余分区依次执行

优势：单分区写入仅需1-2分钟，全表总耗时为分区数×单分区耗时，远低于OPTIMIZE的数周周期；新表自动生成最优大小的数据文件，日志仅保留最新必要记录，彻底解决170TB日志膨胀问题。

步骤2：替换原表（可选，保留原访问路径） #

如果需要保留原表的名称和访问地址：

1. 先备份原表（确保数据安全）：

aws s3 cp --recursive s3://your-bucket/path-to-old-table s3://your-bucket/path-to-old-table-backup

2. 删除原表S3路径：

aws s3 rm --recursive s3://your-bucket/path-to-old-table

3. 将新表路径重命名为原表路径：

aws s3 mv --recursive s3://your-bucket/path-to-new-table s3://your-bucket/path-to-old-table

4. 刷新元数据（若使用Hive元存储）：

REFRESH TABLE old_table;

步骤3：原地清理原表日志（仅当不重建表时选择） #

若必须保留原表，可强制清理日志，但耗时可能较长：

• 先修改表属性，禁用时间旅行并设置最短日志保留：

ALTER TABLE old_table SET TBLPROPERTIES (
  'delta.logRetentionDuration' = '0 hours',
  'delta.deletedFileRetentionDuration' = '0 hours',
  'delta.enableTimeTravel' = 'false'
);

• 强制生成新checkpoint并清理所有历史日志：

import io.delta.tables._
val deltaTable = DeltaTable.forPath(spark, "s3://your-bucket/path-to-old-table")
deltaTable.vacuum(0) // 彻底删除所有历史版本和日志，无法恢复

注意：此操作不可逆，且针对170TB日志的清理可能耗时很久，远不如重建表高效。

后续预防措施 #

• 始终开启delta.autoOptimize.optimizeWrite和delta.autoOptimize.autoCompact，自动优化写入文件大小并合并小文件。
• 设置合理的delta.logRetentionDuration（如1天），避免日志无限膨胀。
• 合并小批量写入任务，减少高频次小文件生成。

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