Apache Iceberg 核心概念：表格式、快照、清单与分区
好，咱们正式开始啃 Iceberg 的核心概念。这四个东西——表格式、快照、清单、分区——是 Iceberg 的骨架。你把这四个搞明白了，后面讲读写、讲合并、讲优化，你一听就通。我当年刚接触 Iceberg 时，就是先啃透这四个概念，后面几乎没走弯路。
1. 表格式（Table Format）——不只是“存数据”
很多人一听到“表格式”，第一反应是 Parquet、ORC 这些。不对。Parquet 是文件内部的存储格式，而 Iceberg 的“表格式”是描述整个表元数据和数据文件之间关系的规范。说白了，它是一套“目录结构 + 元数据文件”的约定。
我个人习惯把 Iceberg 的表格式想象成一本书的目录：
- 元数据层：记录表的 schema、分区信息、快照列表——相当于书的版权页和目录索引。
- 清单层：记录每个数据文件的位置、行数、列统计信息——相当于每章的详细内容列表。
- 数据层：真正的 Parquet/ORC 文件——相当于书的正文。
你想想看，传统 Hive 表只有数据层，没有元数据层和清单层。所以 Hive 做分区剪枝、做 ACID 事务非常吃力。Iceberg 把这三层拆开，每一层都能独立演进。
核心要点：Iceberg 表格式的本质是“元数据驱动”。所有操作（读、写、更新、删除）都先读元数据，再操作数据文件。这跟 Hive 那种“直接扫目录”的思路完全不同。
2. 快照（Snapshot）——表的“时间胶囊”
快照是 Iceberg 最让我惊艳的设计。它本质上是一个不可变的、完整的表状态视图。每次对表做写入、删除、更新操作，Iceberg 不会修改已有数据文件，而是生成一个新的快照，指向一组新的数据文件。
为什么会这样？因为 Iceberg 采用了乐观并发控制 + 多版本并发控制（MVCC）。每次提交都生成一个新快照，旧快照仍然可读。这就实现了：
- 时间旅行：你可以查询任意历史快照的数据。
- 增量读取：从快照 A 到快照 B，只读取变化的数据文件。
- 无锁并发：读操作从不阻塞写操作，写操作之间通过原子性提交解决冲突。
我记得有一次线上环境需要回滚误操作的数据。传统 Hive 表只能靠备份恢复，耗时几小时。Iceberg 直接一条 SQL 把表指向误操作前的快照，几分钟搞定。嗯，这就是快照的价值。
小技巧：Iceberg 默认保留最近 10 个快照。你可以通过 write.metadata.previous-versions-max 调整保留数量。保留太多快照会占用元数据存储空间，建议根据业务需求设置合理的保留策略。
3. 清单（Manifest）——数据文件的“索引卡片”
清单是连接快照和数据文件的桥梁。每个快照包含一个或多个清单文件，每个清单文件记录了一组数据文件的元信息。
清单里存了什么？我列一下关键字段：
| 字段 | 说明 | 我的经验 |
|---|---|---|
file_path |
数据文件的完整路径 | 建议用路径，避免相对路径带来的歧义 |
file_format |
Parquet、ORC、Avro | Parquet 最常用，列存 + 压缩效果好 |
record_count |
该文件包含的行数 | 用于查询优化器估算成本 |
lower_bound / upper_bound |
各列的最小值/最大值 | 这是 Iceberg 做分区剪枝和谓词下推的关键 |
partition_spec_id |
所属的分区规范 ID | 支持分区演进而设计 |
你想想看，有了这些统计信息，查询引擎在读数据前就能通过清单判断：这个文件里有没有我需要的数据？如果没有，直接跳过。这就是 Iceberg 比 Hive 快的原因之一——清单级别的数据跳过。
避坑指南：我曾经遇到过一个坑——清单文件过多导致元数据操作变慢。原因是频繁的小文件写入产生了大量清单。解决方案是开启 Iceberg 的 write.target-file-size-bytes 参数，控制数据文件大小，减少清单数量。
4. 分区（Partition）——Iceberg 的分区跟 Hive 不一样
说到分区，很多人会想到 Hive 的分区目录：/dt=2024-01-01/hour=12/。Iceberg 的分区理念完全不同。
Iceberg 的分区是“隐藏的”。什么意思？
- Hive 分区：分区列是物理目录结构，查询时必须显式指定分区列。
- Iceberg 分区：分区列是逻辑概念，Iceberg 自动根据分区规范将数据路由到对应分区。用户不需要关心数据存在哪个目录。
更厉害的是，Iceberg 支持分区演进。你可以随时修改表的分区规范，旧数据仍然按旧分区布局存储，新数据按新分区布局存储。Iceberg 在查询时会自动合并两种分区布局的结果。
我记得有个业务场景：一开始按天分区，后来数据量暴增，需要改成按小时分区。Hive 表得重建表、重刷数据。Iceberg 直接一条 ALTER TABLE ... ADD PARTITION FIELD 搞定，零停机。
分区演进示例：
-- 初始分区：按天
ALTER TABLE events ADD PARTITION FIELD event_date;
-- 后来改为：按天 + 按小时
ALTER TABLE events ADD PARTITION FIELD event_hour;
-- Iceberg 自动处理：旧数据按天，新数据按天+小时5. 四者关系全景图
下面这张图展示了表格式、快照、清单、分区之间的关系。我建议你多看几遍，理解这个数据流。
从上图你可以看到：
- 表格式在最顶层，管理所有元数据。
- 快照是表格式下的版本节点，每个快照指向一组清单。
- 清单记录数据文件的元信息，包括分区统计。
- 分区贯穿整个流程，影响数据文件的组织方式。
6. 实战中的选择建议
最后，我根据实际项目经验，给你几个选择建议：
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 数据量 < 100GB | 不分区，或按天分区 | 分区过多反而增加元数据开销 |
| 数据量 100GB ~ 10TB | 按天分区 + 按小时分区演进 | 平衡查询性能和元数据规模 |
| 数据量 > 10TB | 按小时分区 + 按业务键分桶 | 进一步减少扫描数据量 |
| 需要时间旅行 | 保留 30~90 天快照 | 满足审计和回滚需求 |
| 频繁小文件写入 | 开启压缩合并，控制文件大小 | 减少清单数量，提升查询性能 |
嗯，这四个概念就讲到这里。你先把它们消化掉，后面讲读写流程时，你会发现一切都顺理成章。