Apache Hudi：增量数据湖架构深度解析 · 专栏导览
专栏定位
Apache Hudi（Hadoop Upsert Delete and Incremental）是 Uber 工程团队于 2016 年开源的数据湖存储框架，于 2019 年进入 Apache 孵化器，2020 年成为 Apache 顶级项目。Hudi 的设计出发点和 Delta Lake 有着本质区别：Delta Lake 的核心叙事是”给数据湖加上事务”，而 Hudi 的核心叙事是”让数据湖支持高效的记录级 Upsert”。
Uber 面对的原始问题是：每天有数十亿条行程记录需要以”按主键更新”的方式同步到 Hive 数据仓库，传统的”每天全量覆盖”方式既慢（重处理几百 GB 数据只为更新几万条记录）又无法满足近实时（小时级而非天级）的数据新鲜度要求。这个**增量摄入（Incremental Ingestion）**问题催生了 Hudi，也决定了它和 Delta Lake、Apache Iceberg 在架构上的核心差异。
本专栏适合：
- 需要将 CDC（Change Data Capture）数据高效同步到数据湖的数据工程师
- 希望在 Hive/Spark 数据湖上实现低延迟 Upsert 而不走全量覆盖的平台工程师
- 已深入了解 Delta Lake，希望对比理解 Hudi 的架构差异和选型依据的架构师
技术版本：Apache Hudi 0.14.x / 1.x
专栏目录
| 篇序 | 文章标题 | 核心主题 |
|---|---|---|
| 01 | 为什么需要 Hudi——Uber 的 CDC 增量数仓困境与 Timeline 解法 | 增量摄入问题，Hudi 的设计哲学与 Delta Lake 的根本差异 |
| 02 | 存储类型深度解析——CoW vs MoR 的设计权衡与适用场景 | Copy-on-Write 与 Merge-on-Read 的文件布局、读写性能权衡 |
| 03 | Timeline 机制——Hudi 事务与增量语义的核心 | .hoodie 元数据目录，Instant、Action、State 的完整状态机 |
| 04 | Upsert 写入路径——Index 机制、HoodieKey 与 Bucket Index | 记录路由、索引类型对比（Bloom/HBase/Bucket/Record-Level），写入流程 |
| 05 | 增量查询与 Incremental Pull——流批一体的数据消费 | INCREMENTAL 查询模式，Checkpoint 机制，下游 CDC 消费 |
| 06 | Hudi vs Delta Lake vs Iceberg——架构设计的本质差异与选型 | 三者的核心差异对比，场景化选型决策矩阵 |
与 Delta Lake 专栏的差异定位
Delta Lake 专栏（已完成）：
核心叙事 = 事务日志（_delta_log）驱动 ACID
强项 = Spark 深度集成、DML 操作、流批一体写入
设计 = 文件级 MVCC，Snapshot Isolation，CoW 为主
本专栏（Apache Hudi）：
核心叙事 = 记录级 Upsert，Timeline 驱动增量消费
强项 = CDC 摄入、近实时数仓、增量 ETL 链路
设计 = 记录级 Index 路由，MoR 延迟合并，Timeline 全局事件日志
推荐阅读路径
CDC 工程师路径（快速上手 Hudi 做 CDC 摄入）：01 → 02 → 04 → 05
架构对比路径（理解 Hudi 与 Delta/Iceberg 的本质差异）：01 → 03 → 06
深度原理路径（完整理解 Hudi 内部机制）：01 → 02 → 03 → 04 → 05 → 06