📚 课程目录第1章 Delta Lake 前世今生

Delta Lake 前世今生：数据湖的痛点、ACID 事务的引入、核心特性概览

聊 Delta Lake 之前，我想先聊聊数据湖。2015 年前后，我还在帮一家电商公司搭数据平台。那时候 Hadoop 生态如日中天，HDFS 存一切，Spark 算一切，听起来很美。但真正用起来，你会发现——嗯，问题不少。

数据湖的「三座大山」

说白了，传统数据湖就是个「大仓库」。你把所有数据往里扔，不管结构化的、半结构化的，还是原始日志。存储便宜，格式灵活，这都没错。但真正跑起业务来，痛点一个接一个。

痛点一：数据质量没人敢保证

我遇到过最头疼的事：凌晨跑批任务写到一半，集群挂了。等恢复后一看，数据只有一半进了表。另一半呢？丢了。下游报表直接对不上。你想想看，这种「写了一半就失败」的场景，在传统数据湖里太常见了。没有事务机制，没有回滚能力，数据一致性全靠运气。

痛点二：文件多到元数据扛不住

Hive 表存了两年日志，分区几千个，文件几十万。每次执行 ALTER TABLE ADD PARTITION 都要等半天。更别提小文件问题了——Spark 写数据默认每个分区一个文件，跑一次批处理，生成几千个小文件。NameNode 内存吃紧，查询性能直线下降。

痛点三：流批分离，维护成本翻倍

很多团队流处理用 Kafka + Flink，批处理用 Hive + Spark SQL。两套引擎，两套表结构，两套数据校验逻辑。我见过最夸张的案例：实时看板的数据和 T+1 报表的数据对不上，业务方天天来问「到底哪个准？」——说实话，我也答不上来。

ACID 事务：Delta Lake 的「定海神针」

2019 年，Databricks 开源了 Delta Lake。它最核心的贡献，就是把 ACID 事务带进了数据湖。

ACID 这四个字母，做数据库的人都不陌生：

特性	含义	在数据湖中的价值
原子性	事务要么全做，要么全不做	写入失败自动回滚，不会出现半截数据
一致性	事务前后数据约束不变	保证读取到的数据是完整、合法的
隔离性	并发事务互不干扰	多个任务同时读写同一张表，不会乱套
持久性	提交的数据不会丢失	写入成功后，即使宕机也能恢复

Delta Lake 怎么做到的？核心秘密是 事务日志（Transaction Log）。它把每一次数据变更都记录成 JSON 文件，存在 _delta_log 目录下。读取时，引擎只认最新版本的数据。写入时，先写日志再写数据，失败就回滚。

我个人的习惯：刚接触 Delta Lake 时，我总爱去翻 _delta_log 目录下的文件。里面记录了每一次 commit 的详细信息——加了哪些文件、删了哪些文件、schema 是什么。这比看任何文档都直观。建议你也试试。

核心特性概览：不止是 ACID

ACID 是基础，但 Delta Lake 能火，靠的是下面这几个「组合拳」。

1. Schema 强制与演进

传统数据湖里，往 Hive 表里加一列，你得先 ALTER TABLE，再重写历史数据。Delta Lake 不一样：

Schema 强制：写入的数据类型不匹配，直接报错。不会出现「字段 A 本来是 INT，某天突然写成了 STRING」这种坑。
Schema 演进：允许自动加列，历史数据自动补 NULL。我做过一个实时数仓项目，业务方每周都要加新指标。用 Delta Lake 的 schema evolution，一行配置就搞定，不用停服务。

-- 允许 schema 自动演进
spark.sql("SET spark.databricks.delta.schema.autoUpdate.enabled = true")

-- 写入时自动加列
df.write.format("delta").mode("append").save("/path/to/table")

2. 时间旅行（Time Travel）

这个功能我太喜欢了。你可以查询任意历史版本的数据，就像 Git 回滚一样。

-- 查询 30 分钟前的数据
SELECT * FROM my_table TIMESTAMP AS OF current_timestamp() - INTERVAL 30 MINUTE

-- 查询第 5 个版本的数据
SELECT * FROM my_table VERSION AS OF 5

我曾经用它排查过一次数据异常：某天凌晨的报表数据突然翻倍，查了半天没找到原因。用时间旅行对比了前一天的数据，发现是上游一个脚本重复跑了两遍。直接回滚到出问题前的版本，5 分钟搞定。

3. 数据版本管理与小文件合并

Delta Lake 每次写入都会生成新版本，但不会自动清理旧文件。时间久了，小文件问题还是会冒出来。好在它提供了 OPTIMIZE 命令：

-- 合并小文件，默认目标文件大小为 1GB
OPTIMIZE my_table

-- 指定合并后的文件大小
OPTIMIZE my_table WHERE date >= '2024-01-01'

我建议把 OPTIMIZE 做成定时任务，每天凌晨跑一次。配合 VACUUM 清理过期文件，能有效控制存储成本。

4. 流批一体：同一张表，两种模式

这是 Delta Lake 最吸引我的地方。你可以用批处理写历史数据，用流处理写实时数据，它们操作的是同一张表、同一套元数据。

-- 批写入
spark.range(1000)
  .write.format("delta")
  .mode("append")
  .save("/data/events")

-- 流写入
val streamDF = spark.readStream
  .format("kafka")
  .option("subscribe", "events")
  .load()

streamDF.writeStream
  .format("delta")
  .option("checkpointLocation", "/checkpoint/events")
  .start("/data/events")

流批共享同一份数据，意味着实时看板和离线报表终于能对上了。我上一个项目就是靠这个特性，把两套引擎砍成一套，维护成本降了 40%。

Delta Lake 架构全景

下面这张图，是我梳理的 Delta Lake 核心架构。你可以看到数据文件、事务日志、以及各种操作之间的关系。

注意：Delta Lake 的事务日志是单点写入的。高并发写入场景下，可能会出现事务冲突。解决办法是合理控制写入频率，或者使用 OPTIMIZE 的 ZORDER 排序来减少数据文件重叠。我踩过这个坑，后面会专门讲。

小结

Delta Lake 不是凭空冒出来的技术。它解决了传统数据湖最痛的三个问题：数据一致性、元数据管理、流批分离。核心武器是事务日志，核心价值是 ACID。有了它，数据湖才真正从一个「仓库」变成了「数据库」。后面几章，我会带你一步步搭建 Delta Lake 环境，并深入每个特性的实战用法。