Delta Lake 基础：表格式、事务日志、版本管理与时间旅行

在深入 OPTIMIZE 与小文件治理之前，必须先理解 Delta Lake 的底层架构。Delta Lake 并非一个独立的存储系统，而是构建在 Apache Spark 之上、以 Parquet 文件为数据载体的一种表格式（Table Format）。它通过一组核心机制——事务日志、版本管理和时间旅行——将“数据文件”与“元数据”紧密耦合，从而在数据湖上实现了 ACID 事务能力。理解这些概念，是后续治理小文件问题的前提。

2.1 表格式：从“文件目录”到“事务表”

传统数据湖（如 Hive 表）本质上是一个目录，其中散落着大量 Parquet/ORC 文件。当 Spark 写入数据时，它只是简单地在目录下生成新文件，没有原子性保证——如果作业中途失败，可能留下部分写入的文件，造成数据不完整。而 Delta Lake 将表定义为一个目录 + 事务日志（_delta_log）的组合体。每次写入（INSERT、UPDATE、DELETE、MERGE）都会生成一个新的事务提交，记录在 _delta_log 目录下的 JSON 文件中。

下图展示了 Delta 表的基本结构，以及事务日志如何将数据文件组织成可查询的表快照：

从图中可以看到，事务日志是 Delta 表的“大脑”。每次提交都会生成一个新的 JSON 文件，文件名是单调递增的版本号。查询时，Spark 读取最新的日志文件，解析出当前表应该包含哪些数据文件，然后只扫描这些文件。这种设计使得 Delta 表具备了原子性（要么全部提交，要么全部不提交）和隔离性（并发写入通过乐观锁解决冲突）。

2.2 事务日志：Delta Lake 的“账本”

事务日志（Delta Log）是理解 Delta Lake 一切行为的钥匙。它记录了表从创建开始的每一次变更操作。每个 JSON 文件包含一个或多个 action，常见的 action 类型包括：

• add：声明添加一个数据文件，包含文件路径、大小、分区信息、统计信息（如 min/max 值）。
• remove：声明删除一个数据文件，通常带有 deletionTimestamp 和 dataChange 标记。
• metaData：定义表的 schema、分区列、格式等元数据信息。
• commitInfo：记录提交的操作类型、用户、时间戳等审计信息。
• protocol：定义 Delta 协议的版本号，用于兼容性检查。

下面是一个简化的 00000000000000000002.json 文件内容示例，它表示一次 DELETE 操作：

{
  "commitInfo": {
    "timestamp": 1710000000000,
    "operation": "DELETE",
    "operationParameters": {"predicate": "id = 100"}
  },
  "remove": {
    "path": "part-0001-yyy.parquet",
    "deletionTimestamp": 1710000000000,
    "dataChange": true
  },
  "add": {
    "path": "part-0004-new.parquet",
    "size": 2048,
    "partitionValues": {},
    "stats": "{\"numRecords\": 500, \"minValues\": {\"id\": 1}, \"maxValues\": {\"id\": 999}}"
  }
}

注意，DELETE 操作在 Delta 中并不是物理删除文件，而是通过 remove 将旧文件标记为“不可见”，同时通过 add 写入一个不包含被删除行的新文件。这种机制称为 MVCC（多版本并发控制），它使得读取操作无需加锁，同时为时间旅行提供了基础。

2.3 版本管理与时间旅行

由于每次提交都会生成一个新的日志版本，Delta 表天然维护了完整的版本历史。你可以通过以下方式查询历史版本：

-- 查看表的历史操作记录
DESCRIBE HISTORY events;

-- 结果示例（简化）：
-- version | timestamp          | operation | operationParameters
-- 3       | 2024-03-10 10:30  | UPDATE    | {"predicate": "id=5"}
-- 2       | 2024-03-10 10:15  | DELETE    | {"predicate": "id=100"}
-- 1       | 2024-03-10 10:00  | WRITE     | {"mode": "Append"}
-- 0       | 2024-03-10 09:45  | CREATE    | {}

时间旅行（Time Travel）允许你基于历史版本或时间戳查询数据，这在数据审计、错误修复和场景回放中非常有用。语法如下：

-- 按版本号查询（读取 v1 时的数据快照）
SELECT * FROM events VERSION AS OF 1;

-- 按时间戳查询（读取某个时间点之前的最新快照）
SELECT * FROM events TIMESTAMP AS OF '2024-03-10 10:00:00';

-- 在 Spark DataFrame API 中：
spark.read.format("delta")
  .option("versionAsOf", "1")
  .table("events")

时间旅行的实现原理并不复杂：当指定版本号时，Spark 会读取该版本对应的日志文件，并只重放该版本及之前的 add 和 remove 操作，从而构建出那个时间点的文件列表。这意味着，即使某个文件在后续版本中被标记为删除，只要它仍然物理存在于存储中，就可以被时间旅行查询访问。

2.4 案例：理解 OPTIMIZE 与版本管理的关系

现在，我们可以将 OPTIMIZE 与上述概念联系起来。假设一张 Delta 表经过多次小批量写入后，产生了 1000 个小文件（每个约 1MB）。此时执行 OPTIMIZE：

1. OPTIMIZE 会读取所有小文件的数据，进行重新分区和排序（默认按文件大小目标，如 1GB）。
2. 它将数据压缩写入少量大文件（例如 10 个 100MB 的文件）。
3. 在事务日志中，OPTIMIZE 会生成一个新的版本（例如 v100），其中包含：
   • 对所有 1000 个小文件的 remove 操作（标记为 dataChange=false，表示这不是数据变更，而是布局优化）。
   • 对 10 个大文件的 add 操作。

关键点在于：OPTIMIZE 之后，查询性能大幅提升，因为需要扫描的文件数从 1000 个降为 10 个。但如果你执行 SELECT * FROM table VERSION AS OF 99，仍然可以访问到优化前的 1000 个小文件——只要它们没有被 VACUUM 清理。这就是为什么 OPTIMIZE 不会破坏数据完整性，而是通过“标记删除 + 新增”的方式实现无缝切换。

2.5 误区与复盘：常见理解偏差