1. Delta Lake 前世今生：从数据湖到湖仓一体，Delta Lake 的诞生背景与核心优势

大家好，我是你们这门课的老朋友。今天咱们正式开篇，聊聊 Delta Lake 的来龙去脉。

说实话，我最早接触大数据那会儿，Hadoop 还是的王者。那时候大家建数据平台，基本就是 HDFS 存文件，Hive 跑 SQL。后来 Spark 火了，大家发现 Hive 太慢，开始用 Spark 直接读写 HDFS 上的 Parquet 文件。嗯，问题就出在这儿了。

1.1 数据湖的诞生：为什么我们需要它？

2010 年左右，大数据圈子里冒出一个概念叫「数据湖」。说白了，就是把所有原始数据一股脑扔进一个廉价存储里，想怎么用就怎么用。跟传统数据仓库比，数据湖有几个明显的好处：

• 存储便宜：HDFS 或 S3 比 Oracle、Teradata 便宜太多
• 格式开放：Parquet、ORC、Avro 随便选，不绑定厂商
• Schema 灵活：先存数据，后定义结构，适合探索式分析

听起来很美好对吧？但我当年在项目里踩过坑。有一次，一个同事直接往 HDFS 上覆盖写了一个 Parquet 文件，结果下游跑了一天的报表全错了。为什么？因为数据湖没有事务支持，写了一半的文件被读到了，数据就乱了。

1.2 湖仓一体：数据湖的进化方向

到了 2018 年左右，业界开始反思：能不能把数据仓库的可靠性、事务能力，跟数据湖的灵活性、低成本结合起来？这就是「湖仓一体」的雏形。

我个人习惯把湖仓一体理解成「给数据湖装上数据库引擎」。它要解决三个核心问题：

1. 事务性：多任务并发读写时，数据不能乱
2. 一致性：读到的数据必须是完整的、已提交的
3. 可回滚：出错了能回到上一个版本

你想想看，如果没有这些能力，实时特征工程根本没法做。特征数据每天更新几百次，每次更新都可能失败，没有事务保障，特征值就全对不上了。

1.3 Delta Lake 的诞生背景

Delta Lake 是 Databricks 在 2019 年开源的。它的核心思路其实不复杂：在 Parquet 文件之上加一层事务日志（Transaction Log）。

我记得第一次看到 Delta Lake 的时，心里想：这不就是数据库的 WAL（Write-Ahead Log）吗？但仔细一想，能在分布式文件系统上实现这个，确实不容易。

Delta Lake 的诞生背景主要有三个：

背景因素	具体问题	Delta Lake 的解法
数据湖缺乏事务	并发写入导致数据损坏	ACID 事务 + 乐观并发控制
Schema 管理混乱	字段类型变更导致下游报错	Schema 强制 + 自动演进
数据版本不可控	无法回溯历史数据	时间旅行（Time Travel）

1.4 Delta Lake 的核心优势

咱们来细数一下 Delta Lake 到底强在哪儿。我挑几个最常用的说：

1.4.1 ACID 事务

这是 Delta Lake 的立身之本。它通过事务日志记录每一次数据变更，保证读操作要么看到全部新数据，要么全部旧数据，不会看到一半。

-- 示例：两个任务同时写入同一个 Delta 表
-- 任务 A：写入 100 条记录
-- 任务 B：写入 200 条记录
-- 最终结果：要么看到 300 条，要么看到 0 条，不会出现 150 条

1.4.2 Schema 强制与演进

默认情况下，Delta Lake 会强制检查写入数据的 Schema 是否匹配。如果多了一个字段，它会报错。但你可以显式开启 Schema 自动演进：

spark.sql("ALTER TABLE feature_store SET TBLPROPERTIES ('delta.schema.autoMigrate' = 'true')")

我曾经在项目中遇到过一个问题：上游特征表突然加了一个字段，下游的模型训练脚本没更新，直接崩溃了。后来我强制开启了 Schema 演进，并加了一层校验，才彻底解决。

1.4.3 时间旅行

这个功能我特别喜欢。你可以用版本号或时间戳查询历史数据：

-- 按版本号查询
SELECT * FROM feature_store VERSION AS OF 123

-- 按时间戳查询
SELECT * FROM feature_store TIMESTAMP AS OF '2024-01-15 10:00:00'

1.4.4 数据版本管理

Delta Lake 的每个操作都会生成一个新版本。你可以用 DESCRIBE HISTORY 查看所有变更记录：

DESCRIBE HISTORY feature_store

这个命令会返回一个表格，包含操作类型、用户、时间戳、操作指标等信息。做审计和排查问题时特别有用。

1.5 Delta Lake 架构总览

下面这张图是我自己画的 Delta Lake 核心架构。你看一眼就能明白它的工作原理：

从这张图你能看到，Delta Lake 在计算引擎和存储层之间加了一层「核心层」。这一层负责事务日志、Schema 管理和版本控制。说白了，就是把数据库的 ACID 能力搬到了数据湖上。

1.6 为什么 Delta Lake 适合实时特征工程？

咱们这门课叫《Delta Lake 实时特征工程实战》，那 Delta Lake 到底好在哪儿？我总结了几点：

• 支持 Upsert：特征数据经常需要更新，Delta Lake 的 MERGE 操作可以高效地插入或更新记录
• 增量读取：通过 delta.columnMapping 和 streaming，可以只读取新增数据，适合实时流处理
• 数据质量保障：Schema 强制 + 约束检查，保证特征数据不会出现脏数据
• 历史回溯：模型训练需要历史特征，时间旅行可以直接查询任意时间点的特征快照

1.7 本章小结

好了，咱们把 Delta Lake 的前世今生捋了一遍。从数据湖的「野蛮生长」，到湖仓一体的「秩序重建」，Delta Lake 的出现解决了数据湖最核心的几个痛点：事务、Schema、版本管理。