3、事务日志详解：Delta Log 结构、Commit 文件、Checkpoint 文件、日志清理策略

事务日志，也就是 Delta Log，是 Delta Lake 最核心的组件。说白了，它就是整个表的“黑匣子”，记录了每一次数据变更。我刚开始接触 Delta Lake 时，觉得这玩意儿就是个普通的日志文件，后来在生产环境踩过坑才明白——理解透它，才能真正用好 Delta Lake。

3.1 Delta Log 的物理结构

每个 Delta 表都有一个隐藏目录 _delta_log，里面躺着两类文件：Commit 文件和Checkpoint 文件。它们共同构成了事务日志的完整历史。

文件名中的数字是版本号，从 0 开始递增。每个版本对应一次原子提交。嗯，这里要注意：版本号是 20 位零填充的十进制数，排序就是自然顺序。

3.2 Commit 文件：每一次变更的“快照”

Commit 文件是 JSON 格式，记录了某次事务的所有操作。我习惯把它理解成“增量变更记录”——只存这次改了啥，不存全量数据。

一个典型的 Commit 文件内容长这样：

{
  "commitInfo": {
    "timestamp": 1700000000000,
    "operation": "WRITE",
    "operationParameters": {"mode": "Append"},
    "readVersion": 5,
    "isolationLevel": "Serializable"
  },
  "add": {
    "path": "part-00000-xxx.snappy.parquet",
    "size": 123456,
    "partitionValues": {"date": "2024-01-01"},
    "modificationTime": 1700000000000,
    "dataChange": true
  },
  "remove": {
    "path": "part-00000-old.snappy.parquet",
    "deletionTimestamp": 1700000000001,
    "dataChange": true
  }
}

这里面有几个关键字段：

字段	含义	我的经验
commitInfo	事务元信息（时间、操作类型、隔离级别）	排查问题时，readVersion 和 isolationLevel 是重点
add	新增的数据文件	注意 dataChange 字段，它标记是否真的改了数据
remove	删除的数据文件	删除不是物理删除，只是标记，文件还在磁盘上

3.3 Checkpoint 文件：加速历史回溯的“快照”

随着 Commit 文件越来越多，从头回放所有 Commit 来重建表状态会越来越慢。Checkpoint 就是来解决这个问题的——它把截止到某个版本的所有变更“压缩”成一份全量快照。

Checkpoint 文件是 Parquet 格式，结构上比 JSON 紧凑得多。它包含截至该版本的所有数据文件列表（包括已删除的标记）。

默认情况下，Delta Lake 每 10 个 Commit 自动生成一次 Checkpoint。这个频率可以调，但我建议别改太大——太频繁浪费存储，太稀疏又起不到加速作用。

3.4 日志清理策略：别让历史成为负担

Commit 文件和 Checkpoint 文件不会自动删除。时间长了，_delta_log 目录可能膨胀到几百 GB。这时候就需要手动或自动清理。

Delta Lake 提供了 VACUUM 命令来清理：

-- 清理 7 天前的日志文件
VACUUM your_table RETAIN 168 HOURS

-- 清理时保留最近 30 天的日志
VACUUM your_table RETAIN 720 HOURS

清理逻辑是这样的：

1. 扫描 _delta_log 目录下所有文件
2. 找出所有版本号小于“当前版本 - 保留版本数”的文件
3. 删除这些文件（但会保留最近的 Checkpoint 文件）

这里有个关键点：VACUUM 只清理日志文件，不清理数据文件。数据文件的清理需要另外用 VACUUM 的 RETAIN 参数控制。

3.5 事务日志的完整生命周期

为了让你更直观地理解整个过程，我画了一张图：

这张图展示了从 Commit 文件到 Checkpoint 文件，再到日志清理的完整流程。每次写入操作产生一个 Commit 文件，累积到 10 个后触发 Checkpoint 生成，最后通过 VACUUM 清理过期日志。

3.6 实战中的注意事项

最后分享几个我在生产环境中积累的经验：

• 不要手动删除日志文件——Delta Lake 的 ACID 事务依赖完整的日志链，删一个可能导致整个表不可用。我见过有人手贱删了 _delta_log 目录，结果表直接废了。
• 监控日志目录大小——建议设置告警，当 _delta_log 超过 10GB 时触发通知。这通常是日志清理没跑起来的信号。
• Checkpoint 文件不是越小越好——虽然 Parquet 格式压缩率高，但如果表有上万个数据文件，Checkpoint 文件也会很大。这时候考虑做文件合并（OPTIMIZE）来减少文件数。
• 时间旅行依赖日志——如果你需要回溯到 30 天前的状态，确保日志保留期大于 30 天。VACUUM 清理后，旧版本就再也回不去了。