📚 课程目录第4章 Schema演进操作实战

4. Schema演进操作实战：添加、删除、重命名与类型提升

Schema演进，说白了就是表结构改了，数据还在。传统Hive里改个列名得重建表、重刷数据，想想就头疼。Iceberg把这套流程简化了不少，但也不是无脑操作。今天我就带你过一遍最常用的四种操作：加字段、删字段、重命名、改类型。

  核心原则：Iceberg的Schema演进是元数据层面的操作，不会重写数据文件。所以速度快，但有些操作有约束——比如类型只能单向提升，不能随意降级。

4.1 添加字段（Add Column）

加字段是最常见的操作。业务跑着跑着，突然要加个新属性，太正常了。Iceberg支持在任意位置添加字段，包括嵌套结构体里。

-- 在表末尾添加普通字段
ALTER TABLE orders ADD COLUMN discount decimal(5,2);

-- 在指定位置添加字段（AFTER语法）
ALTER TABLE orders ADD COLUMN coupon_code string AFTER status;

-- 在嵌套结构体里添加字段
ALTER TABLE orders ADD COLUMN shipping.address.zip_code string;

我个人习惯在加字段时，尽量指定位置，别全堆在末尾。为什么？因为下游ETL脚本如果按位置取数，新字段突然出现在最后一位，可能不会出问题；但如果你用SELECT *，字段顺序变了，某些解析逻辑就崩了。

小技巧：添加字段时，建议同时设置默认值或注释。Iceberg虽然不强制，但注释对后续维护帮助很大。

4.2 删除字段（Drop Column）

删字段要谨慎。我在项目中遇到过，有人直接删了某个字段，结果下游报表跑出来全是空值，排查了半天才发现是字段被删了。

-- 删除普通字段
ALTER TABLE orders DROP COLUMN temp_field;

-- 删除嵌套字段
ALTER TABLE orders DROP COLUMN shipping.address.zip_code;

注意：删除字段只是从元数据中移除该列的引用，数据文件里的物理数据并不会被删除。Iceberg后续的Compaction操作才会真正清理。所以如果你删错了，理论上还能通过时间旅行恢复——前提是你没做Compaction。

还有一点，删除字段后，如果下游有视图或物化视图引用了这个字段，它们会直接报错。我建议删字段前，先跑一遍依赖分析，看看哪些任务在用这个字段。

4.3 重命名字段（Rename Column）

重命名是个坑。你想想看，字段名一改，所有下游脚本都得跟着改。Iceberg的重命名操作本身很简单，但影响面很大。

-- 重命名字段
ALTER TABLE orders RENAME COLUMN old_name TO new_name;

-- 重命名嵌套字段
ALTER TABLE orders RENAME COLUMN shipping.address.zip_code TO postal_code;

我记得有一次，业务方说“这个字段名太长了，改短一点”。我改完之后，发现数据管道里十几个Spark任务全挂了。从那以后，我定了个规矩：重命名字段必须走变更审批流程，至少提前一周通知所有下游团队。

  避坑指南：Iceberg允许重命名后，新旧字段名同时存在于历史元数据中。如果你用时间旅行查询旧版本，字段名还是旧的。所以下游如果用了旧字段名，在旧快照上还能跑通，但新快照上就挂了。这种“部分兼容”的情况最坑人。

4.4 修改字段类型（类型提升）

类型修改是Schema演进里最讲究的。Iceberg只支持类型提升，不支持类型降级。说白了，只能从窄类型往宽类型改，不能反过来。

源类型	目标类型	是否支持	说明
INT	LONG	✅ 支持	整数范围扩大
FLOAT	DOUBLE	✅ 支持	浮点精度提升
INT	STRING	✅ 支持	整数转字符串
STRING	INT	❌ 不支持	字符串转整数可能丢失数据
LONG	INT	❌ 不支持	大范围转小范围可能溢出

-- 类型提升：INT -> LONG
ALTER TABLE orders ALTER COLUMN quantity TYPE bigint;

-- 类型提升：FLOAT -> DOUBLE
ALTER TABLE orders ALTER COLUMN price TYPE double;

-- 类型提升：INT -> STRING
ALTER TABLE orders ALTER COLUMN status_code TYPE string;

为什么只能提升不能降级？你想想看，数据文件里存的已经是原始类型了。如果允许降级，比如LONG转INT，那超过INT范围的数据怎么办？Iceberg选择保守策略——宁可不让改，也不能丢数据。

特别注意：类型提升操作会生成新的Schema版本，但不会立即重写数据文件。Iceberg在读取时会自动做类型转换。所以性能上会有轻微损耗，尤其是STRING转其他类型时，每次读取都要做解析。

4.5 综合操作与版本管理

实际项目中，这些操作往往是组合使用的。比如加字段的同时，还要改某个字段的类型。Iceberg支持在一个ALTER语句里做多个操作吗？嗯，目前还不支持。每个操作都会生成一个新的Schema版本。

-- 查看Schema历史版本
SELECT * FROM orders.history;

-- 查看某个版本的Schema详情
SELECT * FROM orders.snapshots;

-- 回退到指定Schema版本（通过时间旅行）
SELECT * FROM orders FOR SYSTEM_VERSION AS OF 1234567890;

我个人习惯在每次Schema变更后，都记录变更原因。虽然Iceberg不强制，但你可以用表的属性字段来存这些信息：

ALTER TABLE orders SET TBLPROPERTIES(
  'schema.change.reason' = '新增discount字段，用于促销活动计算',
  'schema.change.ticket' = 'JIRA-12345'
);

最佳实践：建议每次Schema变更都关联一个工单号。这样出了问题，能快速定位是谁改的、为什么改、什么时候改的。

4.6 本章知识体系

下面这张图，我把四种操作的核心要点和注意事项串起来了。你可以保存下来，做Schema演进时对照着看。

嗯，到这里四种操作就讲完了。记住一个核心原则：Iceberg的Schema演进是元数据操作，速度快但有限制。加字段随便加，删字段要谨慎，重命名要通知，改类型只能升不能降。把这些记牢了，线上改表结构就不会翻车。