为什么 Iceberg 在数据湖领域这么火

最近打开技术社区，满眼都是 Apache Iceberg。无论是在大厂的架构分享中，还是在云厂商的推介里，它都占据了“C位”。
很多刚接触大数据的同学可能会感到困惑：我们不是已经有 HDFS 了吗？不是有 Hive 了吗？甚至文件格式我们也用了 Parquet 和 ORC，为什么还需要一个 Iceberg？它到底是个什么东西？
今天这篇文章，笔者就剥开那些高大上的术语，用最通俗的大白话，带大家看透 Iceberg 火爆背后的逻辑，顺便把 Parquet 这些相关概念也一并理清楚。
01 | 痛点：传统数据湖的“烂泥潭”

在聊 Iceberg 之前，我们得先看看它的“前辈”们——传统数据湖（基于 Hive 也就是文件夹管理模式）有什么问题。
① 数据的“隔离性”差（读写打架）

想象一下，你正在往一个 Hive 表里写数据（比如 INSERT INTO），任务跑了一半。
结果是： 虽然任务没结束，但文件已经产生在文件夹里了。这时候如果有下游任务来读取，就会读到“写了一半”的数据（脏读）。这在金融或对数据准确性要求高的场景下，简直是灾难。
② 修改数据简直是噩梦

在大数据领域，我们通常只做“追加（Append）”，很少做“修改（Update）”或“删除（Delete）”。
如果你想修改 Hive 表里的一行数据，通常的做法是：把整个分区甚至整张表的数据读出来，改好，再全部写回去。 这就好比为了修一个灯泡，把整栋房子拆了重建，效率极低。
③ 文件列表（Listing）慢到怀疑人生

当数据量达到 PB 级别，一个表下面可能有几百万个小文件。当你执行 Select * 或者做查询计划时，系统需要去对象存储（如 S3 或 HDFS）上把这几百万个文件列举出来（List 操作）。
痛点： S3/HDFS 的 List 操作在文件很多时非常慢，且不稳定，经常导致任务卡在“Listing files”阶段很久，甚至 OOM（内存溢出）。
为了解决这些“烂泥潭”问题，Table Format（表格式） 的概念应运而生，而 Iceberg 就是其中的佼佼者。
02 | 核心：厘清“文件格式”与“表格式”

很多小白容易混淆 Parquet 和 Iceberg 的关系。这里笔者做一个最直观的比喻。
① Parquet 是“集装箱”

Parquet（还有 ORC、Avro）是 文件格式（File Format）。
它决定了数据在磁盘上是怎么摆放的。比如 Parquet 采用列式存储，压缩率高，查特定列很快。

• 角色： 它只负责存数据本身（Data），它不知道这批数据属于哪个表，也不知道这一天的数据是不是完整的。
  

② Iceberg 是“物流管理系统”

Iceberg 是 表格式（Table Format）。
它不存储实际的数据内容（数据还是存在 Parquet 里），它存储的是 元数据（Metadata）。

• 角色： 它记录了一张表里有哪些 Parquet 文件（Manifest），这些文件是属于哪个版本的，哪些文件被删除了，哪些是新加的。
  

一句话总结：Iceberg 是管理 Parquet 文件的大脑，而 Parquet 是存储数据的躯干。
03 | 揭秘：Iceberg 为什么能“火”？

Iceberg 之所以火，是因为它通过一套巧妙的 元数据管理机制（Snapshot 快照机制），完美解决了上面提到的痛点。我们来看看它最牛的几个能力。
① ACID 事务能力

还记得刚才说的“读写打架”导致的脏数据吗？
Iceberg 引入了数据库领域的 ACID 能力。当你写入数据时，Iceberg 会生成一个新的“快照（Snapshot）”。

• 原理： 只有当数据全部写完，Iceberg 才会原子性地把“当前版本指针”指向这个新快照。
  
• 效果： 读者要么读到旧版本，要么读到完整的新版本，永远不会读到“写了一半”的数据，实现了读写分离。
  

② 极速的查询规划（不依赖 Listing）

这是 Iceberg 性能起飞的关键。
传统 Hive 查数据，需要去文件系统里 List 所有文件。而 Iceberg 在自己的元数据文件（Manifest Files）里已经记录了每个数据文件的路径、行数、甚至列的最大值最小值。

• 效果： 查询时，引擎直接读元数据就知道要扫哪些文件（Data Skipping），直接跳过不相关的文件，完全不需要去调用缓慢的 HDFS/S3 List 接口。
  

③ 隐藏技能：时间旅行（Time Travel）

这是一个让开发者大呼“真香”的功能。
既然 Iceberg 记录了每一次提交的“快照”，那你就可以随意穿越回过去。
比如，你今天发现数据跑错了，想看看昨天这个时候数据长什么样，只需要简单的 SQL（以 Spark SQL 为例）：

1. -- 笔者示例：查询 snapshot_id 为 123456789 时的状态 (按版本号查询)
2. SELECT * FROM my_table VERSION AS OF 123456789;

复制代码

或者

1. -- 笔者示例：查询指定日期下午4点的数据状态 (按时间戳查询)
2. SELECT * FROM my_table TIMESTAMP AS OF '2025-12-16 16:00:00';

复制代码

这对于排查 Bug 和数据恢复简直是神器。
④ 丝滑的 Schema 演进

在传统数仓里，想给一张大表改个列名或者调整列顺序，往往需要重写数据，或者面临数据错位的风险。
Iceberg 支持完整的 Schema Evolution。你改列名、改类型、加列，Iceberg 只需要修改一下元数据里的定义（Mapping），不需要动底层的 Parquet 文件。

• 体验： 秒级完成表结构变更，对生产环境几乎无影响。
  

04 | 实战：Iceberg 在架构中的位置

为了让大家更清楚怎么上手，笔者梳理了一个现代数据平台的典型架构图。
<ul>计算层（谁来做）： Spark, Flink, Trino, StarRocks —— 它们负责“算”和“写”。
中间层（Iceberg）： <strong>