Apache Iceberg

Apache Iceberg 是一种为超大规模分析数据集设计的开放表格式（Open Table Format），最初由 Netflix 开发，用于解决其在 PB 级数据上遇到的诸多痛点，现已成为 Apache 顶级项目。

背景

数据存储架构的演进，本质上是在「成本与开放性」和「事务与管理能力」之间寻找平衡。

Hive 表的局限

在 Iceberg 出现之前，业界普遍采用 Hive 表管理数据湖：以目录（directory）作为分区单位，元数据存放于 Hive Metastore。该方案在数据规模增长后暴露出一系列根本性缺陷：

Iceberg 通过重新设计表的元数据组织方式，系统性地解决了上述问题。

核心概念

Iceberg 既不是数据库，也不是存储引擎或查询引擎。

它是一套开放规范，定义了一张「表」由哪些文件构成、这些文件如何组织，以及计算引擎应如何对其进行读写。Iceberg 位于计算引擎与底层存储之间，作为逻辑表与物理文件之间的抽象层：

graph LR
    A[查询引擎<br/>Spark / Flink / Trino] -->|读写| B[Iceberg 表格式<br/>元数据规范]
    B -->|引用| C[数据文件<br/>Parquet / ORC / Avro]
    C -->|存储于| D[对象存储 / HDFS<br/>S3 / OSS / GCS]

这一设计带来两个关键价值：

• 引擎中立：同一份数据可被 Spark、Flink、Trino 等多种引擎一致地读写，避免数据孤岛与重复拷贝。
• 存储计算解耦：数据持久化于廉价对象存储，计算资源按需弹性伸缩。

核心架构

Iceberg 的核心思想是将元数据（描述数据的数据）与实际数据彻底分离，并以分层结构组织元数据，使得引擎在访问数据前即可完成大量裁剪。

Catalog（入口：表名 → 当前版本指针）
   │
   └── Metadata File（.json）       表级元数据：Schema、分区规格、快照列表
          │
          └── Manifest List（.avro）  某一快照所引用的 Manifest 集合
                 │
                 └── Manifest File（.avro）  数据文件清单 + 列级统计信息
                        │
                        └── Data Files（.parquet / .orc / .avro）  实际数据

核心特性

Snapshot & Time Travel

Iceberg 采用多版本机制：每一次写操作（INSERT / UPDATE / DELETE）都会生成一个新的快照（Snapshot），历史快照默认予以保留。

snapshot-1  (2024-01-01 提交)
snapshot-2  (2024-01-02 提交)
snapshot-3  (2024-01-03 提交)  ← current（当前快照）

其语义类似于版本控制系统的提交历史——表的每个状态都被完整记录。由此衍生出两项能力：

ACID 事务

Iceberg 基于乐观并发控制（Optimistic Concurrency Control, OCC）提供 ACID 保证，确保多任务并发读写同一张表的安全性。其提交流程如下：

1. 写任务基于当前快照生成新的数据文件与元数据；
2. 提交时，通过 Catalog 的原子操作（Compare-And-Swap, CAS）将当前快照指针由旧快照替换为新快照；
3. 若期间已有其他提交导致指针变更，本次提交将失败并自动重试。

Schema Evolution

Iceberg 以唯一的列标识符（field-id）而非列名或列序来追踪字段，因此 Schema 变更是安全、即时且无需重写历史数据的操作。

ALTER TABLE orders ADD COLUMN discount double;   -- 新增列
ALTER TABLE orders RENAME COLUMN amt TO amount;  -- 重命名列

Partition Evolution

分区（Partition）指按特定规则（如按日期、地区）对数据进行物理分组，使查询得以仅扫描相关分组以提升性能。

传统 Hive 表的分区规则在建表后即固定，调整分区方案须重建整表。Iceberg 则允许直接变更分区规格，且无需重写任何历史数据——这是其相较于其他表格式的显著优势。

-- 初始：按天分区
ALTER TABLE logs ADD PARTITION FIELD days(event_time);

-- 数据规模增长后改为按小时分区（历史数据保持不变）
ALTER TABLE logs ADD PARTITION FIELD hours(event_time);

演化后，历史数据沿用旧规格、新数据采用新规格，查询引擎自动处理混合分区规格的扫描，对用户透明。

Hidden Partitioning

在 Hive 中，对按 date 分区的表，查询必须显式书写 WHERE date = '2024-01-01' 方可命中分区，否则触发全表扫描；同时需手动维护额外的分区列。

Iceberg 在内部维护分区逻辑与原始列之间的映射关系。用户仅需基于原始列进行查询，引擎即可自动完成分区裁剪：

-- 建表时声明分区规格：按 event_time 的"天"分区
CREATE TABLE logs (id bigint, event_time timestamp, msg string)
PARTITIONED BY (days(event_time));

-- 查询直接使用原始列，引擎自动完成分区裁剪
SELECT * FROM logs
WHERE event_time BETWEEN '2024-01-01' AND '2024-01-02';

常用的分区转换函数（partition transforms）：

读取流程

将前述概念串联，一次查询读取 Iceberg 表的完整流程如下：

graph TD
    A[1. 查询 Catalog<br/>定位当前 Metadata 文件] --> B[2. 读取 Metadata<br/>获取 Schema 与当前 Snapshot]
    B --> C[3. 读取 Manifest List<br/>枚举该快照的 Manifest]
    C --> D[4. 读取 Manifest<br/>结合谓词与列级统计<br/>裁剪无关数据文件]
    D --> E[5. 仅扫描剩余 Data Files<br/>返回结果]

整个流程的核心在于逐层裁剪：在实际读取数据之前，引擎已通过元数据排除了绝大部分无关文件。这正是 Iceberg 在海量数据下仍保持高性能的根本原因。

底层文件格式

Iceberg 不绑定特定数据文件格式，可根据负载特征选择：

Catalog：表的访问入口

Catalog 负责维护 表名 → 当前 Metadata 文件路径 的映射，是引擎定位表的第一站。不同实现适配不同的部署环境：

与其他湖仓表格式的对比

Iceberg 的主要竞品为 Delta Lake 与 Apache Hudi，三者各有侧重：

综合而言，Iceberg 在开放性、引擎中立性与分区演化能力上具有明显优势，已成为当前湖仓领域事实上的主流标准之一。

表维护

随着读写持续进行，Iceberg 表会累积元数据与小文件，需定期执行维护操作（通常通过 Spark 存储过程调用）以保障性能与控制存储开销：

适用场景

• 湖仓一体的核心存储层：在低成本对象存储之上获得数据仓库级的管理与查询能力
• 需要 ACID 事务保证的大规模数据仓库与数据湖
• Schema 或分区频繁演化的业务表
• 需要数据版本管理、审计与回滚的合规场景
• 多引擎（Spark / Trino / Flink）对同一份数据的混合读写