4、Iceberg表格式核心概念：Snapshot、Manifest、Data File、分区与排序
好，咱们今天来啃一块硬骨头——Iceberg的表格式核心概念。说实话，我第一次接触Iceberg时，也被Snapshot、Manifest这些词搞得有点晕。但后来我发现，只要理解了这几个概念之间的关系，整个Iceberg的设计哲学就通了。
你想想看，Iceberg之所以能成为实时数仓的优选，核心就在于它的表格式设计。它不是简单的文件堆叠，而是一套精心设计的元数据层。我习惯把这套体系比作一本书的目录系统——你不需要翻遍整本书，只看目录就能找到想要的内容。
核心一句话：Iceberg的表格式，本质上是一个多层元数据树。从Snapshot到Manifest再到Data File，每一层都在解决不同的问题。
4.1 Snapshot：表的“时间快照”
Snapshot，说白了就是表在某个时刻的完整快照。每次对Iceberg表的写入、删除、更新操作，都会生成一个新的Snapshot。
我记得有个同学问我：“那岂不是每次操作都复制一份全量数据？那存储不得爆炸？”
当然不是。Iceberg的Snapshot是增量式的——它只记录这次操作改变了哪些文件，没变的文件直接复用。这就是Iceberg能做到“快照隔离”和“时间旅行”的秘密。
| 特性 | 说明 |
|---|---|
| 不可变性 | Snapshot一旦生成，内容不再改变 |
| 增量存储 | 只记录变更，不复制全量 |
| 时间旅行 | 可查询任意历史Snapshot的数据 |
| 原子切换 | 表的“当前快照”指针原子更新 |
我的经验：在生产环境中，我建议保留最近7天的Snapshot用于回溯。太老的Snapshot可以清理掉，否则元数据层会越来越臃肿。Iceberg提供了expireSnapshots操作，我一般每天凌晨跑一次。
4.2 Manifest：文件的“索引清单”
Manifest文件，你可以把它理解成一张“索引清单”。每个Manifest记录了哪些Data File属于这个Snapshot，以及这些文件的统计信息——比如列的最大最小值、行数、文件大小等。
为什么要搞这么一层？直接记录文件列表不行吗？
嗯，这里要注意。Iceberg的查询优化，很大程度上依赖Manifest提供的统计信息。比如你查WHERE date = '2024-01-15'，Iceberg会先看Manifest里记录的date列范围，如果某个Manifest里所有文件的最小日期都大于'2024-01-15'，那这个Manifest对应的文件直接跳过，根本不用读。
这就是分区裁剪和谓词下推的底层实现。我在做实时写入优化时，经常通过调整Manifest的粒度来控制查询性能。
我曾经踩过的坑：有一次我把Manifest的target文件大小设得太小，结果生成了上千个小Manifest。查询时Iceberg需要合并读取这些Manifest，反而拖慢了性能。后来我调整到128MB左右，效果好了很多。
4.3 Data File：真正的数据载体
Data File就是实际存储数据的文件。Iceberg支持Parquet、Avro、ORC等格式，我个人最常用Parquet，列式存储+压缩，查询性能好。
每个Data File在Manifest里都有详细的元数据记录：
- 文件路径和格式
- 分区信息
- 列统计信息（min/max/null count）
- 行数和文件大小
- 文件内容的校验和
这些信息有什么用？举个例子，我在做实时写入时，Flink会不断生成新的Data File。Iceberg通过Manifest里的统计信息，能快速判断哪些文件需要合并（compaction），哪些文件可以跳过。
4.4 分区：物理组织与查询加速
Iceberg的分区和Hive分区不太一样。Hive的分区是目录结构，而Iceberg的分区是虚拟的——它通过转换函数来定义。
比如你按天分区：
-- Iceberg分区定义
PARTITION BY (days(ts))
-- 实际写入时，ts='2024-01-15 10:30:00'的数据
-- 会被自动映射到 day=2024-01-15 这个分区这样做的好处是：分区逻辑和存储结构解耦了。你随时可以修改分区策略，不需要重写数据。我记得有个项目，一开始按天分区，后来业务需要按小时查询，我直接改了分区定义，数据原地不动就生效了。
| 对比项 | Hive分区 | Iceberg分区 |
|---|---|---|
| 存储结构 | 目录层级 | 虚拟分区，元数据管理 |
| 分区变更 | 需要重写数据 | 原地生效，无需重写 |
| 隐藏分区 | 不支持 | 支持（如按小时、按日期提取） |
| 查询优化 | 依赖目录结构 | 依赖Manifest统计信息 |
4.5 排序：数据布局的艺术
排序是Iceberg里容易被忽视但极其重要的特性。它决定了数据在文件内的物理顺序。
为什么排序重要？因为Parquet等列式存储格式，在读取时会利用数据的局部性。如果你经常按某个字段做范围查询，把这个字段排好序，查询效率能提升数倍。
我在实践中常用的策略：
- 时间字段排序：适合时间范围查询，比如查最近一小时的数据
- 高基数字段排序：比如用户ID，适合点查
- 复合排序：先按分区字段，再按业务字段
我的建议：排序不是免费的。写入时排序会消耗CPU和内存。我一般只在写入量大的表上做排序，小表直接写就行，没必要折腾。
4.6 整体架构：一张图看懂
下面这张图展示了Snapshot、Manifest、Data File之间的层级关系。我画这张图时特意把分区和排序也标出来了，方便你理解它们在整个体系中的位置。
从这张图你能看到：Catalog指向Snapshot List，每个Snapshot关联一组Manifest，每个Manifest又指向一批Data File。分区和排序的信息，就藏在Manifest对Data File的元数据描述里。
4.7 实战中的几个关键点
最后，我分享几个在实际项目中积累的经验：
- Snapshot管理：定期清理过期Snapshot，我一般保留3-7天。清理太频繁会影响时间旅行查询。
- Manifest合并：写入频繁时，Manifest会变多。我习惯在低峰期做一次Manifest合并，减少元数据层数。
- 分区策略：不要过度分区。我见过有人按小时分区，结果每个分区只有几百KB数据，查询反而变慢。一般按天或按周就够了。
- 排序字段选择：优先选查询中最常用的过滤字段。如果拿不准，就选时间字段，大部分场景都适用。
我曾经踩过的坑：有次我把排序字段设成了一个低基数的枚举字段（只有3个值），结果排序几乎没效果，反而增加了写入开销。后来改成时间+用户ID的复合排序，查询性能提升了40%。
好了，这一章的内容就到这里。这几个概念是Iceberg的基石，理解了它们，后面讲Flink集成时你就能明白为什么Iceberg能做到“实时写入、读时合并”了。