3. Apache Iceberg核心原理
好，我们进入 Iceberg 的核心。说实话，我第一次看 Iceberg 的时，最打动我的不是它的性能，而是它把「表」这个抽象概念，用一套极其干净的文件系统结构给落地了。你想想看，一个表在 Hive 里就是个目录加一堆文件，但在 Iceberg 里，它是一棵有版本、有快照、可回溯的元数据树。
这一章，我们就拆开这棵树，看看它的根、干、叶分别是什么。
3.1 表格式：Iceberg 到底存了什么？
Iceberg 的表格式，说白了就是三层结构：Catalog → Metadata Layer → Data Layer。但真正有意思的是 Metadata Layer 内部的设计。
一个 Iceberg 表，在文件系统上长这样：
warehouse/db/table/
├── metadata/
│ ├── 00001-abc.metadata.json # 元数据文件
│ ├── 00002-def.metadata.json
│ ├── snap-12345.avro # 清单列表
│ └── snap-67890.avro
├── data/
│ ├── partition_col=value1/
│ │ ├── 00000-0.parquet
│ │ └── 00001-0.parquet
│ └── partition_col=value2/
│ └── 00002-0.parquet
嗯，这里要注意：元数据和数据完全分离。我在项目中遇到过有人把 Iceberg 和 Hive 的目录结构搞混，结果写代码时直接去 data 目录下找 schema——那是找不到的。Iceberg 的 schema、分区信息、快照列表，全在 metadata 目录里。
核心概念：Iceberg 的表格式是一种「自描述」格式。表的所有状态信息都存储在元数据文件中，不需要依赖外部 Hive Metastore 来维护 schema 或分区信息。这意味着你可以把表从一个集群搬到另一个集群，只要把 metadata 和 data 目录拷过去就行。
3.2 快照隔离：读不阻塞写，写不阻塞读
这是 Iceberg 最让我佩服的设计之一。快照隔离的实现思路其实很朴素：每次写操作都生成一个新的快照，读操作只认自己看到的那个快照版本。
具体怎么做的？
- 写操作开始：Iceberg 在元数据中记录当前最新的快照 ID。
- 写操作进行：新数据写入新的数据文件，同时生成新的清单列表和清单文件。
- 写操作提交：原子性地更新元数据文件，把快照指针指向新生成的快照。
- 读操作：读取时拿到的是提交那一刻的快照 ID，后续写操作不会影响它。
举个例子。假设表当前有快照 S1，包含文件 A 和 B。这时候来了一个读请求和一个写请求：
- 读请求拿到 S1，它看到的是 A + B。
- 写请求开始写入文件 C，生成新快照 S2（A + B + C）。
- 写请求提交成功，元数据中的最新快照变成 S2。
- 读请求继续读 S1，完全不受影响。
我曾经在一个实时数仓项目里，用 Iceberg 同时跑批处理和流处理。批处理每 5 分钟写一次全量快照，流处理每秒都在写增量。如果没有快照隔离，这两个作业早就互相踩死了。但 Iceberg 让它们各读各的快照，互不干扰。
个人经验：快照隔离的代价是存储。每次写操作都会生成新的元数据文件，如果写得太频繁，metadata 目录会膨胀得很快。我建议设置合理的快照过期策略，比如保留最近 7 天的快照，或者保留最近 100 个快照。
3.3 元数据层设计：从根到叶的路径
Iceberg 的元数据层，我习惯把它理解成一张「四层路由表」。从最顶层到最底层，每一层都在缩小数据范围：
| 层级 | 文件类型 | 作用 | 包含内容 |
|---|---|---|---|
| 1 | Metadata File | 表的全局状态 | Schema、分区规范、快照列表、当前快照 ID |
| 2 | Manifest List | 快照的文件索引 | 该快照包含的所有 Manifest 文件的路径、分区范围、文件计数 |
| 3 | Manifest File | 数据文件的元数据 | 每个数据文件的路径、分区值、列统计信息（min/max/null count） |
| 4 | Data File | 实际数据 | Parquet / ORC / Avro 格式的行列数据 |
这个设计的好处是什么？分区裁剪和谓词下推可以做到极致。比如你查 WHERE date = '2024-01-15'，Iceberg 不需要扫所有文件。它先看 Manifest List 里每个 Manifest 的分区范围，跳过不相关的 Manifest；再看 Manifest 里每个数据文件的列统计信息，跳过 min/max 不匹配的文件。两层过滤下来，往往只需要扫几个文件。
避坑指南：我曾经遇到过一个性能问题——Manifest 文件太大。原因是表有上千个分区，每个分区下又有几百个小文件，导致一个 Manifest 里塞了几万个数据文件条目。Iceberg 在读取 Manifest 时会把整个文件加载到内存，如果 Manifest 太大，OOM 风险很高。解决方案是：控制文件数量，定期做 compaction，把大量小文件合并成大文件。
3.4 核心流程：一次查询的元数据之旅
为了让你更直观地理解，我画了一张图，展示一次查询请求在 Iceberg 元数据层中的完整路径：
你看，一次查询从发起到最后读到数据，中间经过了 5 次元数据跳转。每次跳转都在做「减法」——缩小需要扫描的数据范围。这就是 Iceberg 能在 PB 级数据上做到秒级查询的原因。
3.5 元数据版本管理：如何做到时间旅行？
时间旅行是 Iceberg 的一个杀手级功能。说白了，就是你可以查询表在过去某个时刻的状态。
实现原理其实不复杂：每个 Metadata File 都记录了它之前的所有快照。当你指定一个时间戳或快照 ID 时，Iceberg 会沿着 Metadata File 的版本链往回找，直到找到那个时间点对应的快照。
举个例子：
-- 查询表在 2024-01-15 10:00:00 时的状态
SELECT * FROM my_table FOR SYSTEM_TIME AS OF '2024-01-15 10:00:00'
-- 或者直接指定快照 ID
SELECT * FROM my_table FOR SYSTEM_VERSION AS OF 1234567890
我在做数据回滚时经常用这个功能。有一次，一个 ETL 作业写错了数据，把某个分区的值全改成了 null。我直接一个时间旅行查询，把数据恢复到作业运行前的状态，然后重新跑了一遍。整个过程不到 5 分钟，比从备份恢复快多了。
小技巧：时间旅行依赖历史快照的元数据文件。如果你设置了 aggressive 的快照过期策略（比如只保留最近 3 个快照），那超过这个范围的时间旅行就会失败。我建议保留至少 7 天的快照，这样既能做时间旅行，又不会让元数据膨胀得太厉害。
3.6 总结：Iceberg 元数据设计的精髓
聊了这么多，我想用三句话总结 Iceberg 的元数据设计：
- 分层解耦：Metadata File → Manifest List → Manifest → Data File，每一层只关注自己该管的事。
- 快照即状态：每次写操作生成一个新快照，读操作绑定到固定快照，天然实现 ACID 的隔离性。
- 自描述 + 可回溯：表的所有状态信息都在元数据文件里，不依赖外部系统；历史快照保留完整，支持时间旅行。
嗯，这套设计让我觉得 Iceberg 不只是一个存储格式，更像是一个「文件系统上的数据库引擎」。下一层我们聊它的写入流程，看看一次 INSERT 操作背后，Iceberg 是怎么保证原子性和一致性的。