1. Iceberg 前世今生：从 Hive 痛点看 Iceberg 诞生背景、核心设计哲学、与 Delta Lake / Hudi 的定位差异

1.1 那个被 Hive 支配的年代

聊 Iceberg 之前，我想先带你回到 2016 年左右的数据湖现场。

那时候，Hive 是的主角。几乎所有大数据团队都在用 Hive 管理表数据。我那时候刚接手一个电商平台的数据平台，每天处理几百张 Hive 表。嗯，说实话，Hive 在当时已经算很能打了——能存 PB 级数据，能跑 SQL，生态也成熟。

但问题也藏得很深。你想想看，一个数据工程师最怕什么？不是数据量大，而是数据出问题的时候，你根本不知道它怎么变成这样的。

我印象特别深的一次：某天凌晨，业务方反馈说「昨天的大促 GMV 报表对不上」。我查了半天，发现是某张中间表被一个临时任务覆盖了分区数据。Hive 没有事务，没有快照，没有回滚。数据丢了就是丢了。最后我只能从备份恢复，折腾了整整一个通宵。

这不是个例。Hive 的架构决定了它有几个绕不开的硬伤：

• 没有事务支持——写操作不隔离，读的时候可能看到脏数据
• 没有快照隔离——你没法回到某个时间点看数据长什么样
• 文件管理太粗糙——分区就是目录，数据文件散落一地，没有统一的元数据视图
• 列级变更成本极高——想加一列？重建整张表吧

1.2 Iceberg 的诞生：Netflix 的「自救」

2017 年，Netflix 的数据团队也遇到了同样的困境。他们的数据湖规模比我们大多了——几万张表，每天几十 PB 的数据增量。Hive 的痛点被放大了无数倍。

Netflix 当时尝试过各种方案：自己改 Hive、用 HDFS 快照、甚至想过用数据库来管理元数据。但都不够理想。最后，他们决定从零设计一个「表格式」（Table Format），这就是 Apache Iceberg 的雏形。

Iceberg 的核心思路其实很朴素：把表看作一个不可变的、版本化的元数据日志。每次对表的变更，都生成一个新的元数据版本，而不是直接修改原来的元数据。这样，读操作永远看到的是一个一致的快照，写操作可以安全地并发执行。

我个人觉得，Iceberg 最聪明的地方在于它没有去「改造」Hive，而是重新定义了「表」这个概念。它不依赖 Hive Metastore 来管理元数据，而是自己维护了一套完整的元数据树：

• Catalog —— 表的注册中心，告诉系统「这张表在哪里」
• Metadata File —— 表的元数据文件，记录表的 schema、分区信息、快照列表
• Manifest List —— 快照对应的清单列表，指向一组 Manifest 文件
• Manifest —— 数据文件的索引，记录每个数据文件的路径、统计信息、分区信息
• Data Files —— 实际的数据文件，Parquet / Avro / ORC 格式

这套分层结构，说白了就是让元数据变得可追溯、可版本化、可并发操作。你想想看，每次写操作只追加新的元数据文件，读操作直接指向某个快照——这不就是数据库 MVCC 的思路吗？

1.3 核心设计哲学：不可变、快照、开放

Iceberg 的设计哲学，我总结为三个关键词：

1.3.1 不可变性（Immutability）

Iceberg 的元数据文件一旦生成，就不会被修改。每次提交都生成新的元数据版本。这意味着什么？

• 读操作永远不会被写操作阻塞
• 你可以安全地回滚到任意历史版本
• 并发写入不会产生冲突（乐观锁机制）

我在项目中遇到过一个问题：两个数据管道同时往一张 Iceberg 表写数据，其中一个失败了。如果是 Hive，这张表可能已经处于「半写半不写」的状态，数据对不上。但 Iceberg 呢？失败的提交根本不会生成新的元数据版本，读操作完全不受影响。

1.3.2 快照隔离（Snapshot Isolation）

每个 Iceberg 表的操作都会生成一个快照。快照就是表在某个时间点的完整视图。你可以通过快照 ID 或时间戳来查询历史数据。

这个能力太实用了。我经常用它来做数据回滚：

-- 查看表的历史快照
SELECT * FROM my_table.history;

-- 回滚到某个快照
CALL my_catalog.system.rollback_to_snapshot('my_table', 1234567890);

-- 基于时间戳查询历史数据
SELECT * FROM my_table FOR SYSTEM_TIME AS OF '2024-01-01 00:00:00';

你想想看，以前用 Hive 的时候，想回滚数据？要么从备份恢复，要么手动删文件。现在一行 SQL 就搞定了。

1.3.3 开放格式（Open Format）

Iceberg 不绑定任何计算引擎。Spark、Flink、Trino、Presto、Hive、StarRocks……都能读。它的元数据文件是 JSON 格式，数据文件是 Parquet / Avro / ORC 标准格式。这意味着你不需要为了用 Iceberg 而换掉整个技术栈。

1.4 三大表格式的定位差异：Iceberg vs Delta Lake vs Hudi

说到这，你可能会问：那 Delta Lake 和 Hudi 呢？它们不也是解决类似问题的吗？

没错。这三者都是「表格式」领域的玩家，但设计理念和侧重点不太一样。我画了一张对比图，帮你快速理解：

我再用表格帮你梳理一下关键差异：

维度	Iceberg	Delta Lake	Hudi
发起方	Netflix	Databricks	Uber
元数据存储	自研元数据树（JSON）	事务日志（Delta Log）	时间线（Timeline）
事务模型	乐观锁 + 快照隔离	乐观锁 + 可序列化	基于时间线的 MVCC
引擎绑定	无绑定，原生支持多引擎	强绑定 Spark	Spark 为主，Flink 扩展
UPSERT 能力	支持（Merge Into）	支持（Merge Into）	原生支持（写时复制/读时合并）
增量查询	通过快照差异实现	通过 Change Data Feed	原生增量拉取
Schema 演进	原生支持，无副作用	支持，但有部分限制	支持，但需注意兼容性
社区活跃度	高，Apache 顶级项目	高，Linux Foundation	高，Apache 顶级项目

1.5 为什么我最终选择了 Iceberg

说实话，这三个项目我都深度用过。2019 年我在一个金融科技公司做数据架构升级，当时需要在 Hive 和 HDFS 之上构建一个可靠的数据湖。我评估了三个方案：

• Delta Lake —— 当时还叫 Delta Lake 0.x，Spark 绑定太紧，我们团队用 Flink 和 Presto 也很多
• Hudi —— UPSERT 确实强，但元数据管理偏重，小表场景下性能开销大
• Iceberg —— 元数据设计最优雅，引擎无关，社区增长最快

最后我们选了 Iceberg。原因很简单：它把「表」这个抽象做得最干净。你不需要关心底层文件怎么组织，不需要操心并发写入怎么协调，甚至不需要知道数据存在哪个目录。Iceberg 的元数据层帮你把这一切都管好了。

而且，Iceberg 的社区生态在过去两年爆发式增长。现在几乎所有主流数据引擎都原生支持 Iceberg。这意味着你选 Iceberg，基本上不会被某个引擎绑定死。