Delta Lake 基础：ACID 事务、Schema 演进、时间旅行原理

聊到 Lakehouse，绕不开的一个核心组件就是 Delta Lake。我最早接触它是在 2019 年，当时团队正被 Hive 表的“脏读”和“覆盖写一半挂了”折磨得够呛。Delta Lake 的出现，说白了就是把数据库的 ACID 特性带到了数据湖里。今天咱们就把它最核心的三个能力掰开揉碎讲清楚。

4.1 ACID 事务：让数据湖不再“脏”

传统数据湖（比如 Hive + HDFS）最大的痛点是什么？你写一个任务跑半小时，写到一半程序崩了，数据就处于“半残”状态。下游读到的可能是部分数据，甚至文件格式都坏了。这就是缺少事务保证的后果。

Delta Lake 用 事务日志（Transaction Log） 解决了这个问题。每次写操作都会先记录日志，再真正写数据。如果中途失败，回滚日志就行，数据文件不受影响。

我给大家拆解一下具体流程：

1. 读操作：读取最新版本的事务日志，确定要读哪些文件。
2. 写操作：先写数据文件（临时目录），再写事务日志。
3. 提交：原子性地将事务日志条目写入 _delta_log 目录。
4. 失败回滚：如果写日志失败，临时文件会被自动清理，数据湖状态不变。

举个例子，两个任务同时往一张表写数据：

-- 任务 A：插入 100 条记录
INSERT INTO events VALUES (1, 'click'), (2, 'view') ...

-- 任务 B：插入 200 条记录
INSERT INTO events VALUES (101, 'purchase'), (102, 'add_cart') ...

-- 如果 A 先提交，B 后提交，两者互不干扰
-- 如果 A 和 B 修改了同一行数据，后提交的会失败并重试

4.2 Schema 演进：表结构不再“死板”

做数据开发的人都知道，业务一变，表结构就得跟着变。传统 Hive 表加个字段，你得先 ALTER TABLE ADD COLUMNS，然后重写所有历史数据。麻烦不说，还容易出错。

Delta Lake 的 Schema 演进，允许你 自动或手动 地修改表结构，而且不需要重写数据。它支持：

• 添加列：新列默认值为 NULL，历史数据不受影响。
• 删除列：元数据中标记删除，数据文件不变。
• 修改列类型：比如从 INT 改成 STRING，Delta Lake 会自动做类型提升。
• 列重命名：通过 ALTER TABLE RENAME COLUMN 实现。

具体怎么用？看代码：

-- 创建表时定义 Schema
CREATE TABLE events (
  event_id INT,
  event_name STRING,
  event_time TIMESTAMP
) USING DELTA;

-- 插入数据
INSERT INTO events VALUES (1, 'click', '2024-01-01 10:00:00');

-- 添加新列，不需要重写数据
ALTER TABLE events ADD COLUMNS (user_id STRING);

-- 查询历史数据，新列显示为 NULL
SELECT * FROM events;
-- 结果：1, click, 2024-01-01 10:00:00, NULL

-- 插入新数据，新列有值
INSERT INTO events VALUES (2, 'view', '2024-01-02 12:00:00', 'user_123');

Schema 演进的底层原理其实不复杂。Delta Lake 的事务日志里记录了每个版本的 Schema 信息。当你查询时，它会根据当前版本解析数据文件。历史数据文件里的字段顺序和类型可能和当前 Schema 不同，但 Delta Lake 会在读取时做映射和类型转换。

4.3 时间旅行（Time Travel）：回到过去查数据

时间旅行是我个人最喜欢的功能。说白了，就是你可以查询表的 历史版本。这在数据恢复、审计、调试场景下特别有用。

举个例子，你昨天跑了个任务，不小心把某个字段的值全改错了。传统做法是找备份恢复，耗时又费力。有了时间旅行，你只需要一条 SQL 就能查到昨天的数据：

-- 查询表在某个时间点的状态
SELECT * FROM events TIMESTAMP AS OF '2024-01-01 10:00:00';

-- 或者按版本号查询
SELECT * FROM events VERSION AS OF 5;

-- 查看表的历史版本
DESCRIBE HISTORY events;

时间旅行的原理是什么？我画个图帮大家理解：

你看，每个版本都对应一个 JSON 日志文件。日志里记录了：

• 这个版本新增了哪些数据文件
• 删除了哪些数据文件
• 当前的 Schema 是什么
• 提交时间、操作类型等元数据

当你查询历史版本时，Delta Lake 会读取对应版本的日志，然后只读取该版本“可见”的数据文件。比如查版本 2，它就读版本 2 日志里列出的所有文件。版本 3 删掉的文件，版本 2 的查询根本看不到。

4.4 三个特性的协同关系

ACID 事务、Schema 演进、时间旅行，这三个特性不是孤立的。它们都依赖同一个东西——事务日志。

特性	依赖的日志信息	典型场景
ACID 事务	提交记录、冲突检测	并发写入、失败回滚
Schema 演进	Schema 版本记录	加字段、改类型
时间旅行	文件列表、版本号	数据恢复、审计

说白了，事务日志就是 Delta Lake 的“大脑”。每次操作都会写日志，日志里包含了所有元数据。读数据时，先读日志，再读文件。写数据时，先写文件，再写日志。这个设计保证了数据的一致性和可追溯性。