Apache Iceberg：开放表格式深度解析 · 专栏导览
专栏定位
Apache Iceberg 是 Netflix 工程团队于 2018 年开源、2020 年成为 Apache 顶级项目的开放表格式（Open Table Format）。注意这个词的精确含义——Iceberg 的自我定位不是”数据湖框架”，而是”表格式规范”。它解决的核心问题与 Apache Hudi 有本质不同：
Hudi 的核心问题：如何高效地按主键 Upsert 记录？ Iceberg 的核心问题：如何让多个引擎（Spark/Trino/Flink/Hive/Presto）在同一张表上可靠地并发读写，且彼此行为一致？
Netflix 在 2018 年面对的现实是：他们有 10PB 级的 Hive 表，同时被 Spark、Presto 和 Hive 访问。Hive 元存储（HMS）的分区管理是扫描 S3 的”最后一分钟设计”——通过 MSCK REPAIR TABLE 同步分区、通过 HDFS 目录结构存储分区路径——这在大量小分区的情况下极其低效，而且不同引擎之间存在元数据不一致问题。Iceberg 的回答是：把”表”的定义从 HDFS 目录结构抽象为与引擎无关的元数据规范，任何实现了 Iceberg 格式规范的引擎，都能以一致的语义读写同一张表。
本专栏适合：
- 在多引擎数据湖（Spark + Trino + Flink 混用）场景下寻求统一存储标准的平台工程师
- 对 Hidden Partitioning、Partition Evolution 等 Iceberg 高级特性感兴趣的数据工程师
- 已深入了解 Hudi 和 Delta Lake，希望从架构层面理解 Iceberg 差异的架构师
技术版本：Apache Iceberg 1.4.x / 1.5.x
专栏目录
| 篇序 | 文章标题 | 核心主题 |
|---|---|---|
| 01 | 为什么需要 Iceberg——Netflix 的多引擎困境与开放表格式 | Hive 元存储的扩展性瓶颈，Iceberg 的设计哲学 |
| 02 | 元数据三层架构——Snapshot、Manifest List 与 Manifest File | Iceberg 的核心创新：与引擎解耦的多层元数据 |
| 03 | Hidden Partitioning——告别分区列陷阱 | 隐藏分区原理，Partition Evolution（分区演进） |
| 04 | 事务与并发控制——乐观锁与 Optimistic Concurrency | Iceberg 的 ACID 实现，多写冲突处理 |
| 05 | 查询优化——Partition Pruning、Column Metrics 与 Row-level Delete | 文件级过滤，Deletion Vectors，Position Delete |
| 06 | Iceberg vs Delta Lake vs Hudi——格式开放性与生态广度对比 | 三者架构差异的 Iceberg 视角，云原生生态 |
与 Hudi 专栏的差异定位
Hudi 专栏（已完成）：
核心叙事 = 记录级 Upsert + 增量消费（Timeline 驱动）
叙事视角 = 写入效率优先，Index 是核心工程投入
本专栏（Apache Iceberg）：
核心叙事 = 开放表格式规范 + 多引擎一致性
叙事视角 = 引擎解耦优先，元数据架构是核心创新
与 Hudi 的根本差异 = Iceberg 没有记录级索引，不专为 Upsert 优化
但它的元数据架构和分区设计是三者中最先进的
推荐阅读路径
架构入门路径：01 → 02 → 03
多引擎实践路径：01 → 02 → 04 → 06
深度原理路径：01 → 02 → 03 → 04 → 05 → 06