Iceberg 核心概念：表格式、元数据分层与快照管理

好，咱们正式开始聊 Iceberg 的核心。很多朋友第一次接触 Iceberg 时，会被一堆术语搞懵——表格式、元数据层、Manifest、快照……说实话，我最早看文档时也绕了好一阵。但这些东西一旦理清楚，你会发现 Iceberg 的设计其实非常优雅。

这一节，我就带你把这些概念一个一个拆开，用我自己的理解讲明白。

1. 表格式（Table Format）到底是什么？

先问个问题：Hive 表、Parquet 文件、Iceberg 表，它们之间有什么区别？

你可能会说，Hive 用分区目录组织文件，Parquet 是列式存储格式。没错，但 Iceberg 做的不是存储格式，而是表格式（Table Format）。

表格式，说白了就是描述表结构、数据文件、分区信息、统计信息的一套元数据规范。它不关心数据怎么存（Parquet/ORC/Avro 都行），它关心的是：

• 这张表有哪些文件？
• 这些文件在哪个分区？
• 每个文件包含哪些列？
• 文件里数据的 min/max 值是多少？
• 当前表的最新快照是哪个？

我打个比方。Hive 表就像一本没有目录的书，你要找某页内容，得从头翻到尾。Iceberg 表就像一本带目录、带索引、带版本号的书——你翻到目录页，就知道每一章在哪，每一节有哪些内容，甚至知道哪些章节被修改过。

我在项目中遇到过最典型的场景：业务方要求「回滚到昨天下午 3 点的数据状态」。用 Hive 的话，你得重新跑一遍昨天的分区。用 Iceberg，直接切到那个时间点的快照就行——这就是表格式带来的能力。

2. Iceberg 的元数据分层

Iceberg 的元数据是分层的，一共四层。我习惯从下往上讲，因为这样更符合数据读取的路径。

2.1 四层结构总览

先看这张图，我画了 Iceberg 的元数据分层结构：

嗯，这张图很关键。你仔细看，数据读取是从上往下的：先查 Catalog 找到表，再读 Metadata 文件拿到快照和 Manifest 列表，然后读 Manifest 找到具体数据文件，最后读数据文件。

2.2 各层详解

Catalog（目录层）

Catalog 是入口。它存的是「表名 → 当前元数据文件路径」的映射。常见的 Catalog 实现有 Hive Metastore、Hadoop、JDBC、REST 等。

我个人习惯用 REST Catalog，因为它支持跨集群共享，而且不需要依赖 Hive Metastore。有一次我在 K8s 上搭 Iceberg 环境，Hive Metastore 死活连不上，换成 REST Catalog 十分钟搞定。

Metadata File（元数据文件）

每个 Metadata 文件是一个 JSON，记录了：

• 表的 schema（列名、类型）
• 分区规范（按哪个字段分区）
• 快照列表（每个快照的 ID、时间戳、Manifest 列表）
• 当前快照 ID

每次提交（commit）都会生成一个新的 Metadata 文件。所以 Iceberg 的元数据是不可变的——旧文件不会被覆盖，只是 Catalog 指针指向了新文件。

Manifest File（清单文件）

Manifest 文件是 Avro 格式的，里面每行记录对应一个数据文件。记录内容包括：

• 文件路径
• 文件格式（Parquet/ORC/Avro）
• 分区数据
• 列统计信息（min/max/null count）
• 文件大小、行数

Manifest 文件的设计非常巧妙。因为每个 Manifest 只包含少量数据文件（通常几百到几千个），查询时只需要读取相关的 Manifest，不需要扫描所有文件。这就是 Iceberg 能实现分区裁剪和谓词下推的基础。

Data File（数据文件）

最底层就是实际的数据文件了。Iceberg 不限制存储格式，Parquet 用得最多，ORC 也有。每个数据文件都是不可变的——写入后就不会再修改。

3. 快照（Snapshot）与版本管理

快照是 Iceberg 最核心的概念之一。我把它理解为表在某个时间点的完整视图。

3.1 快照是什么？

每次对 Iceberg 表进行写入操作（INSERT/UPDATE/DELETE/MERGE），都会生成一个新的快照。快照本质上是一个指针，指向一组 Manifest 文件，而这些 Manifest 文件又指向具体的数据文件。

举个例子：

• 快照 1：包含文件 A、B、C
• 快照 2（追加写入）：包含文件 A、B、C、D
• 快照 3（覆盖写入）：包含文件 E、F（A、B、C、D 被标记为删除）

注意，快照 3 虽然「删除了」A、B、C、D，但这些文件物理上仍然存在。只是快照 3 的 Manifest 里不再引用它们。这就是 Iceberg 能实现时间旅行和回滚的原因——旧快照仍然可以访问旧文件。

3.2 快照的版本管理

Iceberg 的快照管理有几个关键操作：

操作	说明	SQL 示例
查看快照	列出表的所有历史快照	SELECT * FROM table.history
时间旅行	查询某个时间点的数据	SELECT * FROM table FOR SYSTEM_TIME AS OF '2024-01-01 10:00:00'
回滚	将表恢复到某个快照	CALL system.rollback_to_snapshot('table', 123456)
过期快照清理	删除旧快照以释放存储	CALL system.expire_snapshots('table', now() - INTERVAL '7' DAY)

3.3 快照的隔离级别

Iceberg 的快照提供了快照隔离（Snapshot Isolation）。什么意思？就是每个读操作看到的是某个快照的完整数据，不会受到并发写入的影响。

举个例子：

• 事务 A 开始读取快照 1
• 事务 B 写入数据，生成快照 2
• 事务 A 仍然读取快照 1，看不到事务 B 的数据

这种机制避免了脏读、不可重复读等问题。而且 Iceberg 的写入是乐观锁机制——多个写入者可以同时提交，但只有第一个提交成功，后面的会重试。

4. 实战中的避坑指南

聊了这么多理论，我分享几个实际踩过的坑：

• Manifest 文件过多：频繁的小文件写入会导致 Manifest 数量爆炸。我建议开启 Iceberg 的 write.target-file-size-bytes 参数，控制目标文件大小，减少 Manifest 数量。
• 快照过期策略：默认保留 7 天的快照。如果你的表写入频繁，快照文件会占用大量存储。建议根据业务需求调整 history.expire.max-snapshot-age-ms。
• Metadata 文件膨胀：每次提交都生成新的 Metadata 文件，时间长了会很多。Iceberg 会自动清理旧 Metadata 文件，但如果你发现元数据目录太大，可以手动执行 remove_orphan_files 清理孤立文件。