3、Delta Lake 核心概念：事务日志、版本控制与时间旅行、Schema 演化与强制

好，咱们进入正题。Delta Lake 之所以能成为流批一体架构的基石，靠的就是这三个核心概念。说白了，它们就是 Delta Lake 的「灵魂三件套」。我刚开始接触时也觉得概念多，但用熟了就会发现，每个设计都直击痛点。

3.1 事务日志（Delta Log）

事务日志，也叫 Delta Log。它不是什么神秘的东西，就是 _delta_log 目录下的一堆 JSON 文件。每个文件代表一次原子提交。

我打个比方。你想想看，银行柜台是不是每笔交易都要记流水？Delta Log 就是 Delta Lake 的流水账。每次写入、更新、删除，都会生成一个新的 JSON 文件，记录这次操作干了什么。

3.1.1 事务日志的结构

打开一个 Delta 表目录，你会看到这样的结构：

my_delta_table/
├── _delta_log/
│   ├── 00000000000000000000.json
│   ├── 00000000000000000001.json
│   ├── 00000000000000000002.json
│   └── ...
├── part-00000-xxx.snappy.parquet
├── part-00001-xxx.snappy.parquet
└── ...

每个 JSON 文件名是 20 位的零填充数字，这就是版本号。从 0 开始，每次提交加 1。

打开一个 JSON 文件看看：

{
  "commitInfo": {
    "timestamp": 1700000000000,
    "operation": "WRITE",
    "operationParameters": {"mode": "Append"},
    "readVersion": 1,
    "isolationLevel": "Serializable"
  },
  "add": {
    "path": "part-00000-xxx.snappy.parquet",
    "size": 12345,
    "partitionValues": {},
    "modificationTime": 1700000000000,
    "dataChange": true
  }
}

这里面记录了：谁提交的、什么操作、改了哪些文件。嗯，这里要注意，readVersion 字段很关键，它表示这次提交是基于哪个版本做的修改。这就是实现 ACID 事务的核心。

3.1.2 事务日志的工作原理

Delta Lake 的事务日志遵循一个简单的规则：乐观并发控制。

流程是这样的：

1. 读取当前版本：先读最新的 JSON 文件，知道当前状态
2. 准备变更：在内存中计算要改哪些文件
3. 尝试提交：写一个新的 JSON 文件，版本号 +1
4. 冲突检测：如果别人同时提交了，你的版本号就落后了，需要重试

3.2 版本控制与时间旅行

有了事务日志，版本控制就是水到渠成的事。每个 JSON 文件就是一个版本快照。你可以随时回到任意历史版本。

时间旅行，说白了就是「查历史账」。我经常用它来做数据回滚和审计。

3.2.1 时间旅行的三种方式

方式	语法	适用场景
按版本号	VERSION AS OF 5	精确回滚到某个已知版本
按时间戳	TIMESTAMP AS OF '2024-01-01'	回溯到某个时间点的数据状态
按字符串	@v5 或 @20240101	Spark SQL 中的快捷方式

代码示例：

-- 按版本号查询
SELECT * FROM my_table VERSION AS OF 5;

-- 按时间戳查询
SELECT * FROM my_table TIMESTAMP AS OF '2024-01-01 12:00:00';

-- Spark DataFrame API
spark.read.format("delta")
  .option("versionAsOf", "5")
  .load("/path/to/table")

spark.read.format("delta")
  .option("timestampAsOf", "2024-01-01")
  .load("/path/to/table")

3.2.2 版本管理的注意事项

版本不是无限保留的。Delta Lake 默认保留 30 天的提交历史。你可以通过 delta.logRetentionDuration 配置调整。

另外，VACUUM 命令会清理旧版本的数据文件。跑完 VACUUM 后，时间旅行就回不到被清理的版本了。

3.3 Schema 演化与强制

Schema 演化，就是允许表结构动态变化。你想想看，业务需求天天变，今天加个字段，明天改个类型，要是每次都要重建表，那不得累死？

Delta Lake 的 Schema 演化分两种模式：

• Schema 强制（默认）：写入数据必须和现有 Schema 完全匹配，多一个字段都不行
• Schema 演化（需开启）：允许自动添加新字段，或修改字段类型

3.3.1 如何开启 Schema 演化

两种方式：

-- 方式一：Spark SQL 设置
SET spark.databricks.delta.schema.autoMerge.enabled = true;

-- 方式二：写入时指定
df.write
  .mode("append")
  .option("mergeSchema", "true")
  .format("delta")
  .save("/path/to/table")

3.3.2 Schema 演化的规则

操作	是否支持	说明
添加新字段	✅ 支持	自动追加到末尾，已有数据该字段为 null
删除字段	❌ 不支持	只能通过重写表实现
修改字段类型	⚠️ 有限支持	只能从窄类型向宽类型转换（如 int → long）
重命名字段	❌ 不支持	只能通过删除+添加模拟

3.3.3 Schema 强制的好处

你想想看，如果没有 Schema 强制，上游一个不小心多传了个字段，下游消费程序直接崩了。强制模式就像个守门员，把不符合规则的数据挡在门外。

代码示例：

-- 开启 Schema 强制（默认行为）
df.write
  .mode("append")
  .option("mergeSchema", "false")
  .format("delta")
  .save("/path/to/table")

-- 如果 df 的 Schema 和表不匹配，会直接报错
-- org.apache.spark.sql.AnalysisException: 
-- A schema mismatch detected when writing to the Delta table.

3.4 三个概念的协同工作

这三个概念不是孤立的。事务日志是基础，版本控制是上层应用，Schema 演化则是动态扩展能力。

举个例子：

1. 你往表里写了一批新数据，事务日志记录版本 10
2. 发现数据有问题，用时间旅行回到版本 9
3. 业务需要加个字段，开启 Schema 演化写入版本 11
4. 版本 10 和 11 都保留在日志里，随时可以回溯

你看，一环扣一环。没有事务日志，版本控制就是空中楼阁。没有版本控制，Schema 演化后的数据回滚就是噩梦。