3、Iceberg基础入门：表格式、核心特性与Hive对比

好，我们进入第三章。这一章咱们聊聊Iceberg本身。很多同学一开始接触Iceberg，容易把它跟Hive搞混——都是表格式嘛，有什么不一样？

我刚开始接触Iceberg的时候也有这个困惑。后来在项目中真正用起来，才发现差别太大了。说白了，Iceberg不是Hive的简单升级，而是一次重新设计。

3.1 Iceberg表格式简介

Iceberg是什么？它是一种开放的表格式（Table Format）。注意这个词——"表格式"。

传统上我们说的Hive表，其实只是把数据存成文件，然后用Metastore记录一下"这个目录下有哪些文件"。Iceberg不一样，它在文件之上加了一层元数据层，专门管理文件的版本、分区、列信息。

我画了一张图，帮你理解Iceberg的层级结构：

你看，Iceberg有三层：Catalog负责找表，元数据层管理快照链，数据层才是真正的文件。这种分层设计，让Iceberg能做很多Hive做不到的事情。

3.2 Iceberg核心特性

3.2.1 ACID事务

ACID是Iceberg最让我心动的地方。做过实时数仓的同学都知道，Hive表在并发写入时有多痛苦——写一半挂了，数据就坏了；两个任务同时写，可能互相覆盖。

Iceberg通过乐观锁和快照隔离解决了这个问题。每次写入都会生成一个新的快照，提交时检查冲突。如果有冲突，任务会重试。

具体来说，Iceberg的ACID是这样实现的：

• 原子性：写入要么全部成功，要么全部回滚。不会出现"写了一半"的情况。
• 一致性：每个快照都是表的一个完整视图。读的时候不会看到"写到一半"的数据。
• 隔离性：并发写入互不干扰。每个任务操作自己的快照。
• 持久性：数据写入后，只要文件系统不丢，数据就不丢。

3.2.2 时间旅行（Time Travel）

时间旅行是Iceberg的招牌功能。说白了，就是你可以查"表在某个时间点的样子"。

为什么会需要这个？我举几个场景：

• 你跑了一个批处理任务，发现结果不对——想看看"跑之前的数据是什么样的"
• 有人误删了数据——你可以回到删除前的快照，把数据捞回来
• 做数据对比——比较今天和昨天的数据差异

用法很简单：

-- 查某个时间点的数据
SELECT * FROM orders FOR SYSTEM_TIME AS OF '2024-01-15 10:00:00';

-- 查某个快照版本的数据
SELECT * FROM orders FOR SYSTEM_VERSION AS OF 1234567890;

-- 查看所有快照
SELECT * FROM iceberg.history('db.orders');

3.2.3 Schema演化（Schema Evolution）

Schema演化，就是表结构改了之后，旧数据还能正常读。

Hive也支持加列，但有个坑——如果你加了列，旧分区的数据读出来是NULL。Iceberg不一样，它通过列级元数据记录了"每个文件有哪些列"，所以加列、删列、重命名列，旧数据都能正确解析。

支持的演化操作：

操作	是否支持	说明
添加列	✅ 支持	新列默认值为NULL，旧文件不受影响
删除列	✅ 支持	旧文件仍然存在，只是查询时忽略该列
重命名列	✅ 支持	元数据中记录新旧列名的映射关系
修改列类型	⚠️ 有限支持	只能从窄类型向宽类型转换（int→long）
重新排序列	✅ 支持	不影响底层存储，只改变读取时的投影

我曾经在项目中遇到一个场景：业务方要求给订单表加一个"优惠券ID"字段。如果是Hive，我得把历史数据全部重写一遍。用Iceberg，直接ALTER TABLE加列，历史数据自动补NULL，新数据正常写入——前后花了不到5分钟。

3.3 Iceberg与Hive对比

很多同学会问：既然Hive用了这么多年，为什么还要学Iceberg？

我整理了一个对比表，看完你就明白了：

对比维度	Iceberg	Hive
事务支持	完整ACID，快照隔离	仅ACID表（性能差），默认无事务
时间旅行	原生支持，基于快照	不支持（需要自己实现）
Schema演化	列级元数据，无损演化	分区级演化，旧分区可能出问题
分区管理	隐藏分区，自动剪枝	显式分区，需要手动维护
文件管理	自动小文件合并	需要手动COMPACT
查询性能	元数据过滤，只读需要的文件	全目录扫描，依赖分区裁剪
引擎兼容	Spark/Flink/Trino/Presto等	Hive/Spark/Tez等
存储格式	Parquet/ORC/Avro	Parquet/ORC/Text等

你看，Iceberg在事务、时间旅行、Schema演化这几个维度上，几乎是碾压性的优势。但Hive也不是一无是处——它的生态更成熟，很多老系统都基于Hive构建。如果你在维护一个已经稳定运行多年的Hive数仓，迁移到Iceberg需要评估成本。