Apache Iceberg 核心概念：表格式定义、快照、清单、数据文件
聊到 Iceberg，很多人第一反应是「又一个 Hive 的替代品」。其实不然。Iceberg 本质上是一套表格式规范，它不绑定任何计算引擎，也不依赖特定存储后端。说白了，它就是一套告诉系统「表长什么样、数据怎么组织、版本怎么管理」的契约。
我最早接触 Iceberg 时，被它的分层结构绕晕过。后来亲手搭了一套测试环境，把元数据一层层拆开看，才真正理解它的设计哲学。今天咱们就把这四个核心概念掰开揉碎，讲清楚。
1. 表格式定义：Iceberg 的「宪法」
表格式定义（Table Format）是 Iceberg 的根基。它规定了：
- 表的元数据如何存储
- 数据文件如何组织
- 快照如何管理
- 并发写入如何保证
你可以把它理解成一套文件系统上的目录结构 + 元数据文件。Iceberg 表在 HDFS 或 S3 上看起来就是一堆目录和 JSON/AVRO 文件。任何引擎只要读懂这套结构，就能操作这张表。
核心要点：Iceberg 的表格式定义是开放且标准化的。它不像 Hive 那样依赖 Metastore 里的元数据，而是把元数据直接写到了文件系统上。这意味着你甚至可以用 Python 脚本直接读取 Iceberg 表的元数据，不需要启动任何计算引擎。
我个人习惯把 Iceberg 的元数据层想象成「三明治」：最上层是 Catalog（注册表位置），中间是 Metadata Layer（元数据层），最下层是 Data Layer（数据层）。今天咱们重点讲中间和下层。
2. 快照（Snapshot）：表的「时间机器」
快照是 Iceberg 最让我惊艳的特性之一。它本质上是一个不可变的、完整的表状态标记。每次对 Iceberg 表的写操作（INSERT、UPDATE、DELETE、MERGE），都会生成一个新的快照。
为什么说它是时间机器？因为你可以：
- 查询某个历史快照的数据（Time Travel）
- 回滚到任意一个快照
- 对比两个快照之间的差异
实战技巧：我在做数据回溯时，经常用 SELECT * FROM table FOR SYSTEM_VERSION AS OF 1234567890 这种语法。有一次业务方说昨天的报表数据算错了，我直接查了昨天的快照，5 分钟就定位到了问题。要是用 Hive，得重新跑一遍分区回溯，至少半小时。
快照之间通过父快照 ID 形成一条链。每个快照都记录了：
| 快照属性 | 说明 |
|---|---|
| snapshot-id | 全局唯一的快照 ID，长整型 |
| parent-snapshot-id | 上一个快照的 ID，用于形成版本链 |
| timestamp-ms | 快照创建时间戳（毫秒） |
| manifest-list | 指向该快照的清单列表文件 |
| summary | 操作摘要，比如新增了多少行、删除了多少行 |
嗯，这里要注意：Iceberg 的快照是写时复制（Copy-on-Write）的变体。它不会复制全部数据文件，只记录新增和变更的文件。所以快照本身很轻量，创建成本极低。
3. 清单（Manifest）：元数据的「索引」
清单是连接快照和数据文件的桥梁。每个快照会引用一个清单列表（Manifest List），而清单列表里包含多个清单文件（Manifest File）。
我画了一张图，帮你理清它们的关系：
每个清单文件里存的是什么呢？是一组数据文件的元数据条目。每个条目包含：
- 数据文件的路径
- 文件格式（Parquet、ORC、Avro）
- 文件大小、行数
- 列统计信息（最小值、最大值、空值数）
- 分区信息
避坑指南：我曾经在生产环境遇到过一个问题——清单文件数量爆炸。原因是频繁的小批量写入，每次写入都生成新的清单文件。虽然 Iceberg 有合并机制，但如果写入频率太高（比如每分钟一次），清单文件会堆积。后来我调整了写入策略，把批量大小提高到每 10 分钟一次，问题就解决了。
清单文件还有一个关键作用：分区裁剪。查询时，Iceberg 会先读清单文件里的统计信息，跳过那些不包含目标数据的分区。你想想看，如果一张表有 1000 个分区，查询只命中 1 个，那就能跳过 999 个分区的数据文件扫描。性能提升是数量级的。
4. 数据文件（Data File）：真正存数据的地方
数据文件就是实际存储行数据的文件。Iceberg 支持三种格式：
| 格式 | 特点 | 适用场景 |
|---|---|---|
| Parquet | 列式存储，压缩率高，支持复杂嵌套 | OLAP 分析、数据仓库 |
| ORC | 列式存储，Hive 生态友好 | Hive 迁移场景 |
| Avro | 行式存储，写性能好 | 流式写入、Kafka 落盘 |
数据文件本身是不可变的。Iceberg 不会原地修改一个数据文件，而是通过新增文件 + 废弃旧文件的方式实现更新。这听起来有点浪费，但实际上带来了巨大的好处：
- 并发安全：多个写入者不会互相干扰
- 快照隔离：读操作不受写操作影响
- 文件级统计：每个文件都有独立的统计信息
数据文件在 Iceberg 里被组织成分区。但 Iceberg 的分区和 Hive 的分区有个本质区别：Hive 的分区是目录结构，而 Iceberg 的分区是逻辑概念。数据文件可以放在任意目录，Iceberg 通过清单文件里的分区信息来定位它们。
个人经验：我建议你在设计 Iceberg 表时，分区字段不要太多。分区字段越多，清单文件里的条目就越碎片化。一般来说，2-3 个分区字段就够了。比如按日期 + 地区分区，或者按日期 + 事件类型分区。
5. 四者如何协作？
咱们用一个实际写入流程来串一遍：
- 写入请求：Spark/Flink 向 Iceberg 表写入一批数据
- 生成数据文件：Iceberg 将数据写入新的 Parquet 文件，放到数据目录下
- 生成清单文件：Iceberg 为这批新数据文件创建一个清单文件，记录它们的路径、统计信息等
- 更新清单列表：Iceberg 创建一个新的清单列表文件，包含旧的清单 + 新的清单
- 创建快照：Iceberg 创建一个新的快照，指向最新的清单列表
- 更新元数据：Iceberg 更新 metadata.json，将最新快照的指针指向新快照
整个过程是原子性的。如果第 6 步失败，整个写入不会生效。Iceberg 通过这种分层设计，实现了 ACID 事务。
总结一下：
- 表格式定义：Iceberg 的「宪法」，规定了元数据和数据的组织方式
- 快照：表的「时间机器」，每次写入生成一个不可变的版本
- 清单：元数据的「索引」，连接快照和数据文件
- 数据文件：真正存数据的地方，不可变、列式存储
这四个概念层层递进，构成了 Iceberg 的核心架构。理解了它们，你就掌握了 Iceberg 的「内功心法」。