平时做数据处理，肯定遇过这种糟心事儿：一开始做用户信息表，只存姓名和手机号，后来业务要加个邮箱字段，用普通的Parquet或者ORC表改的话，要么得重跑全量数据，要么老数据读不了，整个人都麻了。这时候Apache Iceberg的Schema演进机制，就是专门来解决这个麻烦的。
一、为什么Apache Iceberg需要Schema演进
1.1 传统数据存储的痛点
之前用普通文件存数据，比如把CSV转成Parquet，要是加个字段，就得重新生成所有文件，不仅慢还占存储，更要命的是，老数据没法对应新字段，甚至直接读错。比如你存了1000条用户旧数据，没有邮箱，突然加这个字段，老数据读出来的邮箱全是空，改结构还得停服务，业务都受影响。Iceberg是数据湖的表格式，它的Schema演进只改元数据，不动底层数据，就能搞定字段的新增、修改，老数据还能正常用，不用折腾全量重跑。
二、Apache Iceberg Schema演进的核心逻辑
2.1 字段变更的几种方式
Iceberg的Schema演进不是乱改，只支持兼容的变更：比如新增字段、修改同类型的兼容类型（比如int转long，不会丢数据），还有软删除字段（先标记，后续垃圾回收真删数据）。而且每个Schema版本都有唯一ID，历史版本全保留，相当于给数据的Schema建了“版本档案”，以后要回溯也方便。
2.2 核心：不碰数据，只改元数据
这是和传统存储最大的区别，比如你加个字段，Iceberg只在自己的元数据表里记一下“这个表多了个X字段”，老数据还是原来的样子，读的时候自动把新字段的老值填成null，完全不影响现有业务。
三、实操示例：用Python操作Iceberg实现Schema演进
3.1 技术栈说明
本次示例用单一技术栈：Python + PyIceberg + 本地文件系统（用SQLite存元数据，不用分布式存储，降低入门门槛），所有代码都有注释，方便理解。
3.2 初始表创建（Schema初始化）
# 导入PyIceberg需要的模块
from pyiceberg.catalog.sql import SqlCatalog
from pyiceberg.schema import Schema
from pyiceberg.types import NestedField, StringType, IntegerType, LongType
# 搭建本地Iceberg环境，元数据存SQLite，数据存在当前目录
catalog = SqlCatalog(
"local",
**{
"uri": "sqlite:///iceberg_demo.db", # 元数据库文件
"warehouse": "./iceberg_demo" # 数据存储目录
}
)
# 初始Schema：姓名（必填）、手机号（可选）、年龄（可选，int类型），每个字段有唯一ID
initial_schema = Schema(
NestedField(1, "name", StringType(), required=True),
NestedField(2, "phone", StringType(), required=False),
NestedField(3, "age", IntegerType(), required=False)
)
# 创建用户信息表，表名是default.user_info
catalog.create_table("default.user_info", schema=initial_schema)
# 打印初始Schema，确认创建成功
print("初始Schema内容：")
print(catalog.load_table("default.user_info").schema())
运行这段代码后，你会看到初始表只有三个字段，没有邮箱，Schema版本是1。
3.3 新增字段的Schema演进
# 加载已经创建的用户表
table = catalog.load_table("default.user_info")
# 新增邮箱字段，ID设为4，类型字符串（可选）
new_fields = [NestedField(4, "email", StringType(), required=False)]
# 应用Schema变更，只改元数据，不碰已有数据
table.update_schema().add_fields(new_fields).commit()
# 打印更新后的Schema，确认字段新增成功
print("新增字段后的Schema内容：")
print(table.schema())
执行后你会发现，表多了email字段，之前的老数据读的时候，email会自动填成null，完全兼容旧程序的查询。
3.4 修改字段类型的Schema演进
这里演示把年龄的类型从int改成long（因为后续可能存超过int范围的年龄值，比如超大龄用户），注意：只能做兼容的类型修改，不能反过来（比如把long改成int会丢数据）。
# 加载用户表
table = catalog.load_table("default.user_info")
# 修改age字段的类型，ID保持3（不能改ID，ID是字段的唯一标识），从Integer转成Long
table.update_schema().update_column("age", LongType()).commit()
# 打印更新后的Schema，确认类型修改成功
print("修改字段类型后的Schema内容：")
print(table.schema())
执行后，age字段的类型变成long，老数据的age值会自动转成long，不需要重写任何数据。
四、Schema演进的实际应用场景
4.1 用户埋点数据迭代
电商的用户点击数据，一开始只存点击时间和页面URL，后来要加设备ID、IP地址这些字段，用Iceberg演进的话，不用重跑之前的所有点击数据，直接加字段就行，新老数据都能正常查询，不会影响埋点分析的结果。
4.2 电商订单表字段扩展
订单表一开始只有订单ID和金额，后续要加支付方式、收货人、物流单号这些字段，Schema演进直接搞定，老订单的新增字段都是null，新订单有完整数据，业务完全不用停。
4.3 数据修复场景
比如之前存的日期格式不统一，都是字符串类型的“2024/01/01”，后来统一改成DateType，Iceberg可以修改字段类型，只要字符串格式符合日期要求，老数据会自动转成日期类型，不用手动修复每一条数据。
五、Schema演进的优缺点
5.1 优点
- 效率极高：不用重写全量数据，Schema变更几秒就能完成，节省大量时间和存储；
- 兼容稳定：历史Schema全保留，旧程序用旧Schema，新程序用新Schema，互不影响；
- 排查方便：能回溯之前的所有Schema版本，改坏了可以快速切回旧版本。
5.2 缺点
- 破坏性修改风险：比如改字段名、把可选字段改成必填，这些操作会导致老数据缺失，必须谨慎操作；
- 兼容范围有限：只能做兼容的类型修改，不兼容的（比如字符串转int）会丢数据；
- 元数据膨胀：旧Schema版本太多会占元数据空间，需要定期清理。
六、Schema演进的实操注意事项
6.1 避免破坏性修改
绝对不要改字段的名字、把可选字段改成必填（老数据会有null值），这些操作相当于“删除旧字段加新字段”，会丢数据，尽量只做新增、兼容类型修改、软删除。
6.2 定期清理旧Schema
Iceberg会保留所有历史Schema，旧版本太多会拖慢查询，建议每周用GC命令清理不需要的Schema版本，减少元数据负担。
6.3 下游系统适配
如果用Spark、Flink这些工具查询Iceberg表，要确保工具和Iceberg的版本兼容，不然演进后的Schema可能读不了，比如Spark3.3对应Iceberg1.2版本。
七、总结
Apache Iceberg的Schema演进是数据湖的核心能力，完美解决了传统存储在字段变更时的痛点，用Python就能简单实现。它的逻辑简单，只改元数据不动数据，适配各种业务场景，只要注意别做破坏性修改，就能大幅降低数据迭代的成本，非常适合做数据处理的开发者用。
评论
围绕“Apache Iceberg的Schema演进机制及应用场景”参与讨论