4. 嵌套类型变更：Struct、Array、Map 的字段增删改

嵌套类型，说白了就是「类型里面套类型」。Struct 像一条记录，Array 像列表，Map 像字典。在数据湖仓里，这三兄弟几乎无处不在——日志解析、事件溯源、特征工程，哪哪都有它们。

但麻烦也来了。业务一迭代，嵌套结构就得跟着变。我见过不少团队，因为嵌套 Schema 变更没处理好，导致下游任务大面积报错。嗯，今天咱们就把这块硬骨头啃下来。

核心原则：嵌套类型的变更，本质上和扁平字段一样遵循「加字段安全、删字段危险、改类型更危险」的规则。但因为嵌套层数多、路径深，操作起来更容易踩坑。

4.1 Struct 类型：给记录加字段

Struct 相当于一个内嵌的「小表」。比如用户信息里有个 address 字段，里面包含 city、street、zip。现在要加一个 country，怎么办？

在 Apache Hudi 或 Delta Lake 里，加 Struct 的子字段是安全的。举个例子：

-- 原始 Schema
CREATE TABLE users (
  id INT,
  name STRING,
  address STRUCT<city: STRING, street: STRING, zip: STRING>
) USING HUDI;

-- 加一个 country 字段
ALTER TABLE users ALTER COLUMN address TYPE STRUCT<city: STRING, street: STRING, zip: STRING, country: STRING>;

这里有个细节：新加的字段必须放在最后。为什么？因为 Parquet 和 ORC 的列式存储是按位置索引的。你插在中间，老数据就读不对了。

我的习惯：加 Struct 子字段时，永远追加到末尾。如果业务非要插在中间，那就重建表，别想着原地改。

删字段就麻烦多了。比如要删掉 zip：

-- 删字段（危险操作）
ALTER TABLE users ALTER COLUMN address TYPE STRUCT<city: STRING, street: STRING>;

这行代码一跑，老数据里 zip 字段就变成 null 了。但问题在于——下游如果还有任务在读 address.zip，直接崩。我曾经在一个生产环境里，就因为删了一个嵌套字段，导致十几个 Spark 任务同时挂掉。嗯，从那以后我定了个规矩：删嵌套字段前，先查血缘。

4.2 Array 类型：列表元素的增删

Array 的变更，核心在于「元素类型」和「元素结构」。比如一个 tags 字段，原来是 ARRAY<STRING>，现在要改成 ARRAY<STRUCT<key: STRING, value: STRING>>。

这种变更，说白了就是改元素类型。在大多数数据湖仓引擎里，不允许直接改。你想想看，老数据里存的是字符串，新数据里存的是结构体，读的时候怎么兼容？

避坑指南：Array 的元素类型变更，不要想着原地改。正确的做法是——加一个新字段，双写一段时间，等老数据过期后再删旧字段。

那 Array 里加元素呢？比如 ARRAY<STRUCT<name: STRING, age: INT>> 要加一个 email 字段。这其实和 Struct 的变更一样：

-- 给 Array 里的 Struct 加字段
ALTER TABLE employees ALTER COLUMN contacts TYPE ARRAY<STRUCT<name: STRING, age: INT, email: STRING>>;

注意：新字段在老数据里是 null。下游如果期望这个字段非空，就得做默认值处理。

4.3 Map 类型：键值对的灵活与陷阱

Map 类型看起来最灵活——键值对嘛，想加就加。但实际用起来，坑也不少。

比如一个 properties 字段，类型是 MAP<STRING, STRING>。业务说，现在要支持数值类型的值，改成 MAP<STRING, STRUCT<value: STRING, type: STRING>>。

这又是元素类型变更。和 Array 一样，不能原地改。我建议的做法是：

  1. 新建一个 properties_v2 字段，用新类型。
  2. 写一个迁移任务，把老数据转成新格式。
  3. 等所有下游都切到新字段后，再删掉 properties。

Map 还有一个特殊问题：键的约束。比如你定义了一个 Map，键必须是 country、city、zip 之一。但引擎层面一般不校验这个，全靠应用层保证。一旦脏数据进来，下游解析就炸了。

我的建议：能用 Struct 就别用 Map。Struct 有明确的 Schema 约束，Map 太自由了。只有在键不确定、或者键数量极大的场景下，才考虑 Map。

4.4 嵌套变更的核心流程

说了这么多，咱们总结一下。嵌套类型的变更，我一般按这个流程走：

  1. 识别变更类型：是加字段、删字段，还是改类型？
  2. 评估影响范围：查血缘，看哪些下游任务会受影响。
  3. 选择变更策略：安全变更直接改，危险变更走双写。
  4. 执行并验证：先跑小批量数据，确认无误后再全量。

下面这张图，把嵌套类型变更的决策路径画清楚了：

嵌套类型变更决策流程 识别变更需求 变更类型？ 删字段 加字段 改类型 查血缘 + 双写 追加到末尾 新建字段 + 迁移 小批量验证 → 全量

4.5 实战中的避坑清单

最后，分享几个我踩过的坑，希望能帮你省点时间：

场景 错误做法 正确做法
Struct 加字段 插在中间位置 追加到末尾
Struct 删字段 直接 ALTER 先查下游依赖，再双写
Array 改元素类型 原地 ALTER 新建字段 + 数据迁移
Map 改值类型 直接改类型 新建字段 + 双写
嵌套层数过深 超过 5 层嵌套 考虑展平或拆表

我曾经接手过一个项目，嵌套层数达到了 7 层。每次改 Schema 都要等半小时，而且经常超时。后来我强制要求团队：嵌套不超过 3 层，超过就拆成单独的表。虽然重构工作量大了点，但后续的维护成本直线下降。

嵌套类型的变更，说白了就是「加字段容易、删字段难、改类型要命」。记住这个口诀，大部分场景你都能应付。至于那些极端情况——嗯，到时候再查文档也不迟。

← 上一章 📖 返回目录 下一章 →