4. Schema 演进与强制：自动 Schema 演进（mergeSchema）、Schema 强制（overwriteSchema）、使用 ALTER TABLE 修改 Schema

数据湖的 Schema 管理，说白了就是一张「数据蓝图」。你往湖里写数据，蓝图得跟得上变化。Delta Lake 在这块做得相当成熟，提供了三种核心手段：自动演进、强制覆盖、以及传统的 ALTER TABLE。我最早接触 Delta Lake 时，就被它的 Schema 自动合并能力惊艳到了——不用再像 Hive 那样手动加字段了。

但别高兴太早。自动演进不是万能的，用不好反而会埋坑。这一节，我把三种方式的适用场景、操作细节、以及我踩过的坑，一次性讲清楚。

4.1 自动 Schema 演进：mergeSchema

自动演进，就是写数据时如果发现 Schema 对不上，Delta Lake 自动帮你合并。你只需要在写操作时设置 .option("mergeSchema", "true")。

4.1.1 什么时候用？

• 数据源字段频繁变动：比如上游 API 时不时加个新字段，你又不想每次手动改表结构。
• 多源数据合并：不同来源的数据集字段不完全一致，自动合并能省去大量 ETL 对齐工作。
• 快速原型开发：初期 Schema 不稳定，频繁迭代时自动演进能提升效率。

4.1.2 怎么用？

# 使用 DataFrame 写入时开启自动演进
df.write \
  .mode("append") \
  .option("mergeSchema", "true") \
  .format("delta") \
  .save("/path/to/delta-table")

# 或者使用 SQL 方式
INSERT INTO my_delta_table
OPTIONS (mergeSchema = true)
SELECT * FROM source_table

4.1.3 自动演进的规则

操作类型	是否支持	说明
添加新字段	✅ 支持	新字段追加到末尾，已有数据该字段为 null
删除字段	❌ 不支持	自动演进不会删除字段，需用 ALTER TABLE
重命名字段	❌ 不支持	会被视为删除旧字段 + 添加新字段
类型升级	✅ 部分支持	Integer → Long, Float → Double 等向上兼容
类型降级	❌ 不支持	Long → Integer 会报错
嵌套字段变更	✅ 支持	Struct 内的字段变更同样适用演进规则

4.2 Schema 强制：overwriteSchema

如果说自动演进是「温柔协商」，那 Schema 强制就是「霸道总裁」。当你使用 overwriteSchema 时，Delta Lake 会用新数据的 Schema 完全替换掉表的现有 Schema。

4.2.1 什么时候用？

• Schema 重构：需要彻底改变表结构，比如合并字段、拆分字段、或者调整字段顺序。
• 数据全量刷新：每天全量覆盖一张表，同时 Schema 也可能变化。
• 修复 Schema 错误：之前 Schema 设计不合理，需要一次性纠正。

4.2.2 怎么用？

# 使用 overwriteSchema 强制替换 Schema
df.write \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .format("delta") \
  .save("/path/to/delta-table")

# SQL 方式
INSERT OVERWRITE my_delta_table
OPTIONS (overwriteSchema = true)
SELECT * FROM source_table

4.2.3 mergeSchema vs overwriteSchema 对比

特性	mergeSchema	overwriteSchema
写模式	append / overwrite	仅 overwrite
数据影响	保留已有数据	清空所有数据
Schema 变更	增量合并	完全替换
字段删除	不支持	支持（新 Schema 没有该字段即删除）
类型降级	不支持	支持
风险等级	低	高
典型场景	增量字段追加	Schema 重构

4.3 使用 ALTER TABLE 修改 Schema

除了写数据时自动处理，Delta Lake 也支持传统的 DDL 操作。ALTER TABLE 让你可以精确控制 Schema 的每一个细节，适合需要「外科手术式」变更的场景。

4.3.1 常用 ALTER TABLE 操作

-- 添加新字段
ALTER TABLE my_delta_table ADD COLUMNS (new_col STRING);

-- 添加嵌套字段
ALTER TABLE my_delta_table ADD COLUMNS (address STRUCT<city: STRING, zip: INT>);

-- 修改字段注释
ALTER TABLE my_delta_table ALTER COLUMN old_col COMMENT '更新后的注释';

-- 重命名字段（Delta 0.7+ 支持）
ALTER TABLE my_delta_table RENAME COLUMN old_col TO new_col;

-- 删除字段（Delta 2.0+ 支持）
ALTER TABLE my_delta_table DROP COLUMN useless_col;

-- 修改字段类型（有限支持）
ALTER TABLE my_delta_table ALTER COLUMN int_col TYPE BIGINT;

4.3.2 ALTER TABLE 的注意事项

• 类型变更限制：和 mergeSchema 一样，ALTER TABLE 也只支持向上兼容的类型转换。想从 String 转 Integer？抱歉，不行。
• 删除字段是逻辑删除：DROP COLUMN 只是把字段标记为删除，元数据里还留着。想彻底清理？需要执行 REORG TABLE 或重写表。
• 重命名字段有版本要求：Delta Lake 0.7 之前不支持 RENAME COLUMN，升级后再用。
• 嵌套字段操作：修改 Struct 内的字段，需要用点号语法，比如 ALTER TABLE t ALTER COLUMN a.b.c TYPE STRING。

4.4 Schema 演进决策流程

你想想看，面对一个 Schema 变更需求，到底该选哪种方式？我画了一张决策图，帮你快速定位。

4.5 实战建议与避坑总结

讲了这么多，最后给你几条我实战中沉淀下来的建议：

1. 生产环境默认关闭 mergeSchema。需要时显式开启，并在代码里加日志，记录每次 Schema 变更的细节。这样出了问题能快速定位。
2. overwriteSchema 前先备份。我习惯在覆盖前用 DESCRIBE DETAIL 把当前 Schema 信息存一份，万一需要回滚，至少知道原来的结构是什么。
3. ALTER TABLE 是安全牌。对于关键表，我倾向于用 DDL 手动管理 Schema 变更，而不是依赖自动演进。DDL 可以纳入 CI/CD 流程，有审批、有记录。
4. 定期做 Schema 审计。用 DESCRIBE TABLE 或 SHOW COLUMNS 检查表的 Schema 是否和预期一致。我见过太多因为 Schema 漂移导致的数据质量问题。
5. 嵌套字段要小心。Struct 内的字段变更容易被忽略，尤其是自动演进时。建议在代码里显式定义嵌套 Schema，而不是依赖自动推断。