2、Iceberg基础：表格式、元数据、快照隔离
2.1 从“目录+文件”到“表格式”
在传统 Hive 数仓中，一张表通常只是一个逻辑概念，由 Hive Metastore（HMS）中的元数据指向 HDFS 上的一个目录，目录下散落着若干数据文件。这种“目录即表”的方式虽然简单，却存在几个致命问题：
- 元数据与数据分离：HMS 只记录目录路径和分区列表，不感知文件内部的列结构、统计信息或文件之间的数据关系。
- ACID 能力缺失：多个任务同时写入同一张表时，可能产生脏读或文件互相覆盖，无法保证一致性。
- 演进成本高：修改列类型、拆分分区等操作需要重写整个表或手工迁移数据。
Iceberg 将“表”重新定义为一套自描述、可校验、支持快照隔离的元数据层。它不再依赖 Hive Metastore 来维护文件列表，而是把表的状态完整记录在 Iceberg 自己的元数据文件中。HMS 只承担一个轻量级的“指针”角色，指向当前最新的元数据文件位置。
核心概念：Iceberg 表 = 元数据层（Metadata Layer）+ 数据层（Data Layer）。元数据层描述“表有哪些数据文件、它们如何组织、当前处于哪个快照”，数据层则真正存储 Parquet/ORC/Avro 文件。
2.2 三层元数据架构
Iceberg 的元数据采用分层树状结构，每一层都承担不同的职责。理解这个层级关系，是后续掌握分区裁剪、隐藏分区和优化查询的基础。
| 层级 | 文件类型 | 核心内容 | 更新频率 |
|---|---|---|---|
| Catalog 层 | HMS 表 / Nessie 引用 | 指向当前 metadata_location |
每次提交更新指针 |
| 元数据层 | *.metadata.json |
Schema、分区规格、快照列表、当前快照 ID | 每次提交生成新版本 |
| 清单列表层 | snap-*.avro |
该快照包含的所有 Manifest 文件列表 | 每次快照生成时创建 |
| 清单层 | *.avro（Manifest） |
数据文件路径、分区值、列统计（min/max/null 计数） | 数据文件增删时更新 |
| 数据层 | Parquet / ORC / Avro | 实际的行列数据 | 写入时生成，不可原地修改 |
当执行一次查询时，Iceberg 的读取路径如下：
- 从 Catalog 获取当前表的
metadata_location，加载最新的.metadata.json。 - 从元数据文件中获取当前快照 ID，并找到对应的
snap-*.avro清单列表。 - 读取清单列表，获得该快照下所有 Manifest 文件。
- 逐个读取 Manifest，利用其中的分区值范围和列统计信息，跳过与查询条件无关的数据文件。
- 仅对剩余的数据文件启动 Parquet/ORC 读取任务。
关键理解：Manifest 文件中的列统计信息（如 event_time 的 min/max 值）是 Iceberg 实现分区裁剪和文件裁剪的“弹药”。没有这些统计信息，查询引擎就只能扫描全表文件。
2.3 快照隔离与时间旅行
Iceberg 的每次写入（INSERT、UPDATE、DELETE、MERGE）都会生成一个新的快照（Snapshot）。快照本质上是一个不可变的视图，记录了该时刻表的所有数据文件集合。旧快照不会被立即删除，而是保留在元数据历史中，直到执行过期快照清理（expire_snapshots）为止。
这种设计带来了两个重要能力：
- 读隔离：查询任务在开始时会获取一个快照 ID，整个查询过程中只读取该快照下的文件。即使其他任务并发提交了新数据，当前查询也不会看到，从而避免了脏读和半提交状态。
- 时间旅行：可以指定读取某个历史快照或某个时间点之前的表状态，用于数据回溯、审计或修复误操作。
-- 查看表的历史快照
SELECT snapshot_id, committed_at, operation
FROM events.snapshots
ORDER BY committed_at DESC;
-- 基于时间点读取历史数据（时间旅行）
SELECT count(*) FROM events
FOR SYSTEM_TIME AS OF '2024-06-01 10:00:00';
-- 基于快照 ID 读取
SELECT count(*) FROM events
FOR SYSTEM_VERSION AS OF 38274912734912734;注意：快照隔离并不等于自动清理旧文件。如果长期不执行 expire_snapshots 和 remove_orphan_files，历史快照引用的数据文件会持续占用存储空间，导致表体积膨胀。
2.4 案例：并发写入与读隔离
假设有一个订单表 orders，当前快照为 snap-100，包含 10 个数据文件。此时发生以下并发操作：
场景：任务 A 在 10:00:00 开始执行 SELECT sum(amount) FROM orders WHERE order_date = '2024-06-01'；任务 B 在 10:00:05 向同一张表插入 100 条新订单，生成 snap-101。
由于 Iceberg 的读隔离机制，任务 A 在启动时已经绑定了 snap-100，因此它只会扫描 snap-100 对应的 10 个文件，不会看到任务 B 新插入的数据。即使任务 B 在任务 A 执行过程中完成了提交，也不会影响任务 A 的结果一致性。反之，如果任务 A 在 10:00:06 之后才启动，则会读取 snap-101，看到最新的 100 条记录。
这种机制在数据湖场景中尤为重要——它让多个流式写入任务、批处理任务和即席查询可以同时运行，而无需担心互相干扰或加锁阻塞。
2.5 误区与复盘
在实际使用 Iceberg 时，以下几个误区比较常见，值得特别注意：
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 认为 Iceberg 完全替代 Hive Metastore | HMS 仍作为 Catalog 指针存储，删除 HMS 表会导致无法定位元数据 | 保留 Catalog 注册，但可迁移到 Nessie、JDBC 等更灵活的 Catalog |
| 忽略 Manifest 列统计的维护 | 统计信息缺失或过期，分区裁剪失效，查询退化为全表扫描 | 定期执行 REWRITE MANIFESTS 或 OPTIMIZE 更新统计 |
| 从不清理过期快照 | 存储成本持续增长，NameNode 或对象存储请求压力增大 | 设置保留策略，如保留最近 7 天快照，定期执行清理 |
| 把 Iceberg 当作“自动调优工具” | 文件大小不均、小文件过多，仍然影响查询性能 | 结合 WRITE_TARGET_FILE_SIZE_BYTES 和压缩策略控制文件布局 |
复盘一个真实案例：某团队将 Hive 表迁移到 Iceberg 后，发现部分查询反而变慢。排查后发现，这些查询的过滤条件列（如 user_id）并未定义在分区规格中，且 Manifest 中的列统计因为写入时未开启 write.metadata.metrics.default 而缺失。Iceberg 无法利用统计信息跳过文件，只能逐个读取 Manifest 并扫描全部数据文件。解决方案是：为高频过滤列开启列统计收集，并重新写入 Manifest 文件，使裁剪生效。
这个案例说明，Iceberg 的元数据能力需要主动配置和维护，并非“建表即优化”。理解表格式、元数据层级和快照机制，是正确使用 Iceberg 的前提，也是后续掌握隐藏分区与分区裁剪优化技巧的基石。