📚 课程目录第3章湖仓一体架构

3. 湖仓一体架构：数据湖与数据仓库融合

3.1 从“两套系统”到“一套架构”的演进逻辑

传统大数据平台往往同时维护两套割裂的系统：数据仓库负责承载经过清洗加工的结构化业务数据，提供高并发、低延迟的BI查询；数据湖则负责存储原始日志、非结构化文件与中间结果，供数据科学团队进行探索式分析。这种“双轨制”带来的直接后果是：同一份业务数据在数仓中是一张张表，在湖中是一批批Parquet/ORC文件，两边的元数据、权限体系、生命周期管理互不相通。ETL链路冗长，数据从湖入仓往往需要T+1甚至更久，且一旦湖中文件被直接修改，数仓侧完全感知不到，极易引发“湖里一个数、仓里一个数”的指标口径冲突。

湖仓一体（Lakehouse）的核心思路，是在廉价的对象存储（如MinIO、Ceph RGW或云OSS/S3）之上，直接构建一层具备事务性、索引和表语义的“元数据与存储管理层”。它不再把数据物理搬迁到另一个集群，而是通过表格式（Table Format）让同一份文件同时具备数据湖的开放存储优势和数仓的ACID事务能力。下图展示了湖仓一体与传统两套架构在数据流路径上的本质差异：

从图中可以清晰看到，湖仓一体将“存储”与“表语义”解耦：对象存储只负责持久化文件，而表格式层负责记录“哪些文件属于哪个表版本”。这种设计使得数据从产生到可查询的延迟从小时级缩短到分钟级，同时避免了双份存储带来的资源浪费和口径漂移。

3.2 三大表格式组件的核心机制

目前主流的湖仓表格式组件包括 Apache Iceberg、Apache Hudi 和 Delta Lake。它们虽然实现细节不同，但都围绕一个共同目标：让对象存储上的文件集合具备数据库表一样的事务能力。理解它们的关键，不在于背诵API，而在于掌握各自的“元数据组织模型”和“并发控制策略”。

维度	Apache Iceberg	Apache Hudi	Delta Lake
元数据组织	三层：Catalog → Metadata → Manifest	Timeline + FileGroup + FileSlice	Delta Log（JSON事务日志）
核心抽象	Snapshot（不可变快照）	Copy-on-Write / Merge-on-Read	Transaction Log + Checkpoint
并发控制	乐观锁 + 条件提交（基于版本号）	基于时间线的并发控制	乐观并发控制（OCC）
适合场景	多引擎（Spark/Flink/Trino）	大规模UPSERT、近实时写入	Databricks生态、SQL分析
对象存储适配	原生支持S3/OSS/MinIO	需配置Hoodie存储配置	依赖文件系统事务锁

3.2.1 Iceberg：不可变快照与Manifest分层

Iceberg 的设计哲学是“表即目录”。每次写入都会生成一个新的 Metadata 文件，指向一组 Manifest 列表，Manifest 再指向具体的数据文件。旧 Metadata 文件不会被删除，因此天然支持时间旅行（Time Travel）。其提交过程采用“先写数据文件，再写Manifest，最后原子替换Metadata指针”的方式，保证任何时刻读者看到的都是一致快照。

-- Iceberg 表当前快照结构（简化）
my_table/
├── metadata/
│   ├── v1.metadata.json   ← 初始元数据
│   ├── v2.metadata.json   ← 第二次提交（指针指向此文件）
│   └── snap-123.avro      ← Manifest 列表
└── data/
    ├── 00000-0.parquet
    └── 00001-1.parquet

在对象存储上，Iceberg 的提交操作是“最后写Metadata文件”，这个文件写入是原子的（对象存储的PUT操作天然具备原子性）。因此即使并发提交，也只有一个能成功更新Catalog中的指针，另一个会收到版本冲突异常。

3.2.2 Hudi：文件组与MOR模式

Hudi 的核心创新在于 FileGroup 概念：每个主键范围对应一个文件组，组内包含多个 FileSlice（文件切片）。写入时，新数据要么直接生成新文件（Copy-on-Write，COW），要么写入增量日志文件（Merge-on-Read，MOR）。MOR 模式特别适合“频繁小批量更新”的场景，因为更新操作只追加日志，不需要重写整个列存文件。

-- Hudi MOR 表文件布局（示意）
partition_path=2024/
├── .hoodie/
│   ├── .commit-20241101.dat
│   └── .inflight-20241102.dat
├── 12345-abc/
│   ├── 12345-abc_0-0-0_000.parquet   ← Base文件（列存）
│   └── .12345-abc_0-0-0.log.1_0-0-0  ← 增量日志（行存）
└── 67890-def/
    └── 67890-def_0-0-0_000.parquet

查询MOR表时，引擎需要合并Base文件和Log文件，因此读放大较高；但写入路径极轻。Hudi 的 Timeline 机制记录了每次 commit 的元数据，用于控制并发和恢复失败操作。

3.2.3 Delta Lake：事务日志与Checkpoint

Delta Lake 将事务信息记录在 _delta_log/ 目录下的 JSON 文件中，每个文件对应一次原子提交。日志内容包含新增文件、删除文件、Schema变更等操作。为了避免日志无限增长，Delta 会定期生成 Checkpoint（Parquet格式的聚合快照），恢复时只需读取最新Checkpoint及其后的增量JSON。

-- Delta 表目录结构
my_delta_table/
├── _delta_log/
│   ├── 00000000000000000000.json
│   ├── 00000000000000000001.json
│   ├── 00000000000000000010.checkpoint.parquet
│   └── _last_checkpoint
└── part-00000-xxx.snappy.parquet

Delta Lake 的并发控制依赖 _delta_log 目录下的互斥锁（基于文件系统原子创建），在对象存储上通常需要启用 DynamoDB 或 ZooKeeper 等外部锁服务来保证正确性，这是它与 Iceberg/Hudi 在公有云对象存储上部署时的一个重要差异点。

3.3 湖仓组件与对象存储的交互流程

无论使用哪种表格式，写入对象存储的流程都遵循“两阶段提交”思想。以 Iceberg 写入为例，完整流程如下：

写入数据文件：Spark/Flink 任务将数据以 Parquet/ORC 格式写入对象存储的临时目录或直接写入数据目录，此时文件对表不可见。
生成Manifest：Driver 节点收集所有写入文件的信息（路径、行数、列统计等），生成 Manifest 文件并上传。
提交Metadata：Driver 生成新的 Metadata 文件，其中包含新 Manifest 列表和父快照指针，然后通过原子操作将 Catalog 中的当前元数据指针指向新 Metadata 文件。
清理过期文件：提交成功后，可异步执行过期快照清理，删除不再被引用的数据文件和旧 Metadata 文件。

关键点：在步骤3中，如果两个任务同时提交，后提交者会因版本号冲突而失败。此时需要业务层决定是重试还是合并写入。这也是“提交故障”最常发生的环节——并非数据写入失败，而是元数据提交冲突导致整个事务回滚。

3.4 案例：基于MinIO的Iceberg湖仓写入故障复盘

某互联网公司使用 MinIO 作为对象存储，Iceberg 作为表格式，Spark 批处理每日写入用户行为数据。某日数据延迟，排查发现 Spark 作业在提交阶段持续报错：

org.apache.iceberg.exceptions.CommitFailedException: 
Cannot commit: stale metadata (expected: 123, found: 124)
at org.apache.iceberg.io.ClosingIterator$1.close(ClosingIterator.java:88)

进一步检查 MinIO 访问日志，发现同一表分区存在两个并发 Spark 作业（一个凌晨重跑任务，一个正常日任务）同时提交。由于 Iceberg 的乐观锁机制，后提交的作业检测到元数据版本从 123 变为 124，直接抛出 CommitFailedException。

根因分析：

重跑任务未使用 INSERT OVERWRITE 的原子替换语义，而是先删除分区数据再写入，导致与正常任务产生写写冲突。
两个作业共享同一个 Catalog 和表名，没有做任务级隔离。
MinIO 的 PUT 操作虽然原子，但 Iceberg 的提交检查依赖 Catalog 中的版本号，MinIO 本身不提供条件更新接口，因此冲突只能靠应用层捕获。

解决方案：

将重跑任务改为使用 Iceberg 的 REPLACE PARTITIONS 或独立临时表 + 原子切换，避免与实时任务直接竞争。
在 Spark 作业提交阶段增加重试机制，捕获 CommitFailedException 后重新读取最新元数据并合并写入。
为不同业务线配置独立的 Catalog 命名空间（如 ods_catalog 与 ads_catalog），从物理上隔离提交路径。

3.5 常见误区与设计建议

误区一：认为湖仓组件可以完全替代数仓。 湖仓擅长存储与事务管理，但复杂的权限管控、资源隔离、数据质量规则引擎仍然需要上层数仓工具配合。

误区二：忽视对象存储的“列表一致性”。 某些对象存储（如早期S3）在文件覆盖后存在短暂不一致，Iceberg/Hudi 依赖“先写新文件、再切换指针”规避此问题，但如果直接修改数据文件路径则可能读到半成品。

误区三：所有表都采用同一套表格式。 应根据写入频率、查询模式选择：频繁小文件UPSERT选 Hudi MOR；多引擎共享分析选 Iceberg；深度绑定 Spark/Databricks 选 Delta。

在设计湖仓架构时，建议先明确“数据新鲜度要求”和“并发写入模式”。如果业务以批量导入为主、并发度低，Iceberg 是最稳妥的选择；如果存在大量流式更新且需要秒级可见性，Hudi 的 MOR 模式更合适；如果团队已深度使用 Spark SQL 且希望获得最简运维体验，Delta Lake 的日志机制更直观。无论选择哪种组件，都必须将对象存储的原子性、版本控制和目录结构纳入整体故障排查预案中——因为湖仓的“一致性”最终都建立在存储层的行为之上。