📚 课程目录第1章数据湖仓概述

1. 数据湖仓概述：从数据仓库到数据湖再到湖仓一体，ACID事务为何成为刚需

1.1 数据架构的演进之路

我入行那会儿，数据架构还很简单。企业级数据仓库（EDW）就是唯一的答案。你想想看，那时候的数据量不大，结构也规整，ETL 跑一遍，报表就能出。但后来事情变了。

数据量开始爆炸。日志、传感器、社交媒体……这些半结构化和非结构化数据，传统数仓根本接不住。于是数据湖（Data Lake）出现了。我记得 2015 年左右，很多团队一窝蜂上了 Hadoop，把数据全扔进去，觉得万事大吉。

结果呢？数据湖变成了数据沼泽。因为没有统一的事务保障，写入一半挂了，数据就坏了。读的时候，你永远不知道拿到的数据是不是最新的。说白了，数据湖解决了存储容量的问题，但把数据治理的难题留给了开发者。

这时候，湖仓一体（Lakehouse）的概念应运而生。它想做的事很简单：把数据湖的廉价存储和数据仓库的 ACID 事务结合起来。嗯，这才是正解。

  核心观点： 湖仓一体不是简单的技术叠加，而是从架构层面重新定义了数据平台的事务边界。

1.2 为什么 ACID 事务成了刚需？

你可能觉得，批处理场景下要什么事务？我以前也这么想。直到有一次，我在项目中遇到一个生产事故：一个 Spark 作业在写入分区表时中途失败，结果下游的报表跑了三天，数据对不上。排查下来，就是因为缺少事务隔离，部分数据写入了，部分没写入，读的时候还读到了脏数据。

从那以后，我意识到 ACID 在数据湖仓中不是锦上添花，而是生存底线。具体来说，有四个场景离不开它：

并发写入冲突： 多个作业同时写同一个表，没有事务控制，数据直接乱掉。
部分失败回滚： 写入过程中作业崩溃，需要原子性保证——要么全写，要么全不写。
读一致性： 你在跑一个长查询，另一边在更新数据。没有隔离性，你读到的是半成品。
数据版本管理： 时间旅行查询、回滚到某个快照，这些能力都依赖事务日志。

我的建议： 选型湖仓一体方案时，先看它的事务实现是否支持 Serializable 隔离级别。Snapshot Isolation 在很多场景下够用，但遇到金融级对账，Serializable 才是安全的。

1.3 从数仓到湖仓：一张图看懂架构变迁

下面这张图是我自己画的，帮你快速理解三种架构的核心差异。别小看这张图，它背后是我踩过的坑。

1.4 三种架构的对比

光看图还不够，我习惯用表格把关键差异列出来。这样选型的时候，一眼就能看出哪个适合你。

特性	传统数据仓库	数据湖	湖仓一体
数据格式	结构化	结构化 + 半结构化 + 非结构化	结构化 + 半结构化 + 非结构化
Schema 策略	Schema on Write	Schema on Read	Schema on Write + 演进
ACID 事务	原生支持	不支持	通过事务日志实现
存储成本	高	低	低
查询性能	高	低	高（通过优化）
并发控制	强	无	乐观并发控制
典型代表	Teradata, Oracle	Hadoop, S3 + Hive	Delta Lake, Iceberg, Hudi

注意： 湖仓一体的 ACID 实现和传统数据库不同。它不依赖锁，而是基于乐观并发控制（OCC）和事务日志。这意味着在高冲突场景下，写入可能会失败重试。我曾经在一个高并发写入的实时数仓项目中，因为没调优重试策略，导致写入延迟飙升。后来把重试间隔从指数退避改成固定间隔，问题才解决。

1.5 事务日志：湖仓一体 ACID 的基石

湖仓一体怎么实现 ACID？核心秘密就是事务日志（Transaction Log）。你可以把它理解成一个不可变的、只追加的日志文件。每次数据变更，都会先写日志，再更新数据文件。

这样做的好处很明显：

原子性： 要么日志写完，要么不写。写一半崩溃？回滚日志就行。
隔离性： 读操作只读已提交的日志版本，不会读到未完成的事务。
持久性： 日志写成功，数据就安全了。数据文件可以异步刷盘。
一致性： 通过日志重放，可以恢复到任意时间点的状态。

我举个例子。假设你有一个订单表，两个作业同时写入：

-- 作业 A：插入订单 1001
BEGIN TRANSACTION;
INSERT INTO orders VALUES (1001, 'user_1', 299.00);
-- 写入事务日志：[Txn_A, INSERT, orders, 1001]
COMMIT;

-- 作业 B：插入订单 1002
BEGIN TRANSACTION;
INSERT INTO orders VALUES (1002, 'user_2', 159.00);
-- 写入事务日志：[Txn_B, INSERT, orders, 1002]
COMMIT;

如果作业 A 在 COMMIT 前崩溃了，事务日志里就没有 Txn_A 的提交记录。系统自动回滚，订单 1001 不会出现。这就是原子性。

一个小技巧： 调试事务问题时，直接查事务日志比查数据文件更高效。我习惯用 DESCRIBE HISTORY orders 这类命令，能看到每个事务的提交时间、影响行数、操作类型。排查数据不一致时，这招屡试不爽。

1.6 本章小结

从数据仓库到数据湖，再到湖仓一体，ACID 事务从「可选」变成了「刚需」。原因很简单：数据规模越大，并发场景越复杂，没有事务保障的数据平台就是定时炸弹。

湖仓一体的核心思路是用事务日志来模拟数据库的 ACID 特性，同时保持数据湖的廉价存储和开放格式。接下来的章节，我会深入 Delta Lake、Iceberg、Hudi 这三个主流方案，看看它们各自是怎么实现事务日志的。嗯，到时候你会发现，细节里藏着魔鬼。