3. Schema演进原理：Iceberg如何做到“改表不伤数据”

Schema演进，说白了就是表结构变了之后，历史数据还能不能正常读。这个问题在传统Hive里是个老大难，但在Iceberg这里，我可以说一句：它把这个事做得相当优雅。

我记得刚接触Iceberg时，第一反应是“这玩意儿怎么敢随便加列、删列、改类型？”后来翻了它的元数据设计，才明白——Iceberg的Schema演进，本质上是元数据层的版本管理，而不是物理数据的重写。这个思路，跟Git管理代码版本有点像。

3.1 Iceberg的Schema演进机制

Iceberg支持哪些演进操作？我列个表，你一看就明白：

操作类型	是否支持	说明
添加列	✅ 支持	可指定位置（末尾或嵌套字段内）
删除列	✅ 支持	仅标记删除，历史数据仍可读
重命名列	✅ 支持	通过列ID映射，不破坏历史数据
修改列类型	⚠️ 有限支持	仅允许类型拓宽（如int→long）
调整列顺序	✅ 支持	仅影响元数据，不移动物理数据
嵌套结构变更	✅ 支持	Struct/Map/List内的字段同样适用

为什么会这样？因为Iceberg给每个列分配了一个全局唯一的列ID。这个ID在表创建时就固定了，后续不管你怎么改名、挪位置，ID都不变。数据文件里存的是列ID，不是列名。所以，你改列名，对历史数据毫无影响。

3.2 元数据层如何支持演进

Iceberg的元数据层，我习惯把它拆成三层来看：

1. Metadata文件（.metadata.json）：记录表的当前Schema、分区信息、快照列表等。每次演进操作，都会生成一个新的Metadata文件。
2. Manifest列表（avro文件）：指向当前快照包含的所有Manifest文件。演进后，新的Manifest列表会引用新的Manifest文件。
3. Manifest文件（avro文件）：记录数据文件的元信息，包括文件路径、分区范围、列统计信息等。每个Manifest都关联一个Schema版本。

我画了一张图，帮你理解这三层的关系：

每次Schema演进，Iceberg会做三件事：

• 生成一个新的Schema版本，分配新的Schema ID
• 更新Metadata文件中的当前Schema指针
• 后续写入的数据文件，会关联新的Schema ID

历史数据文件呢？它们仍然关联旧的Schema ID。读取时，Iceberg会根据每个数据文件的Schema ID，自动做列映射。新加的列，历史数据里没有，就填NULL；被删除的列，历史数据里还有，但读取时会被忽略。

3.3 与Hive的对比：为什么Hive改Schema那么痛苦

说到Hive的Schema演进，我真是有一肚子苦水。早年间做数仓迁移，每次Hive表加列，都得跑一遍ALTER TABLE，然后祈祷历史分区别出问题。

Hive的Schema演进，说白了就是“改元数据，但不管历史数据”。它的问题在于：

对比维度	Iceberg	Hive
列标识方式	全局唯一列ID（不变）	列名+位置（可变）
添加列	安全，历史数据自动补NULL	⚠️ 历史分区可能读不到新列
删除列	安全，历史数据仍可读	❌ 历史分区可能报错
重命名列	安全，通过列ID映射	❌ 历史分区列名不匹配
修改列类型	仅允许拓宽（int→long）	⚠️ 可能导致数据损坏
元数据版本管理	✅ 完整版本链，可回滚	❌ 无版本管理
历史数据重写	不需要	通常需要重写历史分区

我曾经在一个Hive数仓项目里，遇到一个经典问题：业务方要求给一张已有3年历史数据的表加一列。Hive的ALTER TABLE ADD COLUMNS只改元数据，历史分区的Parquet文件里根本没有新列。查询时，如果SELECT *，历史分区会报NullPointerException。最后没办法，只能写个Spark任务把历史分区全部重写一遍——跑了整整两天。

换成Iceberg后，同样的情况，一行ALTER TABLE ADD COLUMN就搞定。历史数据自动补NULL，查询完全正常。你想想看，这省了多少事。

3.4 实战：一次完整的Schema演进过程

我拿一个实际场景来演示。假设我们有一张用户行为表，初始Schema是这样的：

CREATE TABLE user_events (
    user_id BIGINT,
    event_type STRING,
    event_time TIMESTAMP
) USING iceberg;

运行一段时间后，业务方说：我们需要记录用户的IP地址。在Iceberg里，加列很简单：

ALTER TABLE user_events ADD COLUMN ip_address STRING;

这条语句执行后，Iceberg在元数据层做了什么？

1. 生成一个新的Schema版本（假设从v1变成v2）
2. 新Schema里多了一个列ip_address，列ID为3（假设前两个列ID是1和2）
3. 更新Metadata文件，当前Schema指向v2
4. 后续写入的数据文件，会包含列ID 1、2、3

历史数据文件呢？它们只有列ID 1和2。查询时，Iceberg自动给历史数据补上ip_address = NULL。整个过程，数据文件一个都没动。

又过了一段时间，业务方说：event_type这个列名不好，改成event_name吧。在Hive里，这是个噩梦。但在Iceberg里：

ALTER TABLE user_events RENAME COLUMN event_type TO event_name;

Iceberg只是把元数据里的列名改了，列ID（假设是2）保持不变。历史数据文件里存的还是列ID 2，读取时自动映射成event_name。完美兼容。