超大数据量Impala/Hive表Schema修改及全表字段更新高效方案咨询

1. ALTER TABLE是否支持前3项结构变更？ #

完全支持，且不需要全表重写，仅为元数据级操作，秒级即可完成，前提是你的表使用Parquet/ORC等主流列存格式（650亿行级表默认都会采用这类存储），Hive版本在2.0及以上即可。

2. 是否有无需全表复制的替代方案？ #

有，可将4项需求拆分处理，结构变更完全不需要碰底层数据，数据修改需求可通过增量处理或视图封装避免一次性全表迁移。

前3项结构变更操作（元数据级，无数据读写） #

对应需求的操作命令如下：

• 删除指定array字段：

  ALTER TABLE 你的表名 DROP COLUMN 待删除array字段名;
  

  若你使用的Hive版本低于2.1，查询前需执行set parquet.column.index.access=false; 兼容旧数据格式，Impala侧操作后刷新元数据即可正常查询。
• 新增复杂类型/简单类型字段：

  ALTER TABLE 你的表名 ADD COLUMNS (
    新增array字段名 array<元素类型> COMMENT '字段说明',
    新增string字段 string COMMENT '字段说明',
    新增int字段 int COMMENT '字段说明'
  );
  

  新增字段默认值为NULL，若需指定默认值可在字段定义后加DEFAULT 默认值，同样为元数据操作，不会修改历史数据。

第4项全表3个字段修改方案 #

该操作需要触达全量数据，但可避免一次性全表迁移的风险：

方案A：分区级增量重写（推荐，适配大表生产场景） #

若你的表为分区表（超大表默认都会做分区设计），可按分区逐个重写，错峰执行：

-- 单个分区重写示例，处理完一个分区再处理下一个，可断点续跑
INSERT OVERWRITE TABLE 你的表名 PARTITION (分区字段 = '分区值')
SELECT
  * EXCEPT(待修改字段1, 待修改字段2, 待修改字段3),
  字段1处理逻辑 AS 待修改字段1,
  字段2处理逻辑 AS 待修改字段2,
  字段3处理逻辑 AS 待修改字段3
FROM 你的表名
WHERE 分区字段 = '分区值';

处理过程中业务可以正常查询未修改的分区，不会出现全表不可用的情况。

方案B：视图封装（零数据修改，适配非固化修改场景） #

若你不需要将修改后的字段值固化到存储，仅需查询时返回修改后结果，可直接创建视图封装所有逻辑，完全不需要碰底层数据：

CREATE VIEW 业务查询视图名 AS
SELECT
  * EXCEPT(待删除array字段, 待修改字段1, 待修改字段2, 待修改字段3),
  新增array字段逻辑 AS 新增array字段名,
  字段1处理逻辑 AS 待修改字段1,
  字段2处理逻辑 AS 待修改字段2,
  字段3处理逻辑 AS 待修改字段3
FROM 你的原表名;

Zeppelin中通过Impala直接查询该视图即可，和查询物理表的语法完全一致。

• 纯ALTER TABLE元数据变更方案
  • 优点：秒级完成，无存储开销，不影响业务读写，后续同类结构调整可直接复用
  • 缺点：仅能处理结构变更，无法实现字段内容修改，需要同步刷新Impala元数据才能生效
• 分区级增量重写方案
  • 优点：无全表锁，可错峰、断点续跑，修改后的数据落地存储，查询无额外计算开销，适配Impala高性能查询
  • 缺点：要求表为分区表，整体数据处理总时长和全量重写接近，但可拆分执行不影响业务
• 视图封装方案
  • 优点：秒级完成，无存储开销，后续调整逻辑仅需修改视图，成本极低
  • 缺点：查询时会增加逻辑计算开销，字段处理逻辑复杂时会降低查询性能

• 每次执行完Hive侧的ALTER TABLE操作后，需在Impala中执行INVALIDATE METADATA 你的表名; 刷新元数据，避免Impala读取旧Schema报错
• 分区重写完成后只需执行REFRESH 你的表名 PARTITION (分区字段='分区值'); 即可，不需要全量刷新元数据，速度更快
• 视图在Impala、Zeppelin中完全兼容，和普通物理表查询语法一致，不需要调整业务侧查询代码

内容的提问来源于stack exchange，提问作者Alex Kerr