📚 课程目录第3章分区演进原理

3. 分区演进原理：分区演进的意义、支持机制、与Hive分区对比

3.1 分区演进的意义：为什么静态分区模型不够用

在 Iceberg 出现之前，Hive 等传统数据仓库的分区结构是建表时一次性确定、后续难以变更的。业务运行一段时间后，分区模型几乎必然面临三类挑战：

分区粒度不匹配：最初按“月”分区，业务量增长后希望细化为“天”分区，但 Hive 表需要重建或新增一张表再迁移数据。
分区列选择失误：上线时按 etl_date 分区，实际查询却大量按 event_time 过滤，导致频繁全表扫描。
分区列值格式演进：日期字段从 yyyy-MM-dd 变为 yyyyMMdd，或需要新增地域维度作为二级分区，传统表只能停机维护。

分区演进（Partition Evolution）的核心意义在于：让分区模型成为表的一种“可调整元数据”，而不是“物理目录的固化约定”。Iceberg 将分区规则与数据文件存储解耦——数据文件本身不依赖目录路径表达分区，而是通过清单（Manifest）中的分区元数据记录归属。因此，修改分区规则时，无需重写历史数据文件，只需更新表的元数据，新旧数据可以按各自所属的分区规则共存于同一张表。

  关键收益：分区演进让数据湖表结构具备“可编程性”，业务模型变化时，表可以原地演进，避免耗时的数据重写和迁移任务。

3.2 支持机制：Iceberg 分区演进的核心原理

Iceberg 分区演进之所以能“轻量”完成，底层依赖三个关键设计：

分区规则版本化（Partition Spec Versioning）
表的每个分区规则（Partition Spec）都有唯一的 spec-id。每次演进操作会生成新的 spec，但旧 spec 仍然保留在表元数据的历史版本中。数据文件写入时，会记录自己所属的 spec-id，因此新旧文件可以明确区分。
分区值与文件路径解耦
数据文件的实际存储路径可以是任意位置（如 /data/warehouse/events/00000-0.parquet），不再要求路径中必须包含 month=2024-01 这样的目录层级。文件属于哪个分区，由 Manifest 中的 partition_data 字段精确记录。
查询时按 spec 分别裁剪
执行查询时，Iceberg 的规划器会同时考虑多个 spec：对于旧 spec 写入的文件，按旧规则裁剪；对于新 spec 写入的文件，按新规则裁剪。最终合并结果时，通过 Manifest 中的列统计信息进一步过滤，保证查询结果正确且高效。

以下 SQL 展示了典型的分区演进操作：

-- 1. 初始建表：按月分区
CREATE TABLE events (
  id BIGINT,
  ts TIMESTAMP,
  region STRING,
  data STRING
) USING iceberg
PARTITIONED BY (month(ts));

-- 2. 业务变化：改为按天分区（历史数据仍按旧规则读取）
ALTER TABLE events ADD PARTITION FIELD day(ts);

-- 3. 新写入的数据自动按天分区
INSERT INTO events VALUES (1, TIMESTAMP '2024-05-15 10:00:00', 'cn', '...');

-- 4. 查询时自动合并新旧分区规则的数据
SELECT * FROM events WHERE ts >= TIMESTAMP '2024-05-01';

提示：执行 ADD PARTITION FIELD 后，Iceberg 会立即将新规则应用于后续写入。对于存量数据，你可以通过 REWRITE DATA 异步重写文件，使其按新规则重新组织，但这并非查询正确性的必要条件。

3.3 与 Hive 分区对比：一张表看清本质差异

对比维度	Hive 分区	Iceberg 分区演进
分区表达	物理目录路径（`month=2024-01/`）	元数据规则（Manifest 记录分区值）
变更分区	需重建表或新增表 + 数据迁移	`ALTER TABLE` 直接演进，秒级完成
历史数据	必须重写才能适配新分区	无需重写，新旧规则共存
查询裁剪	依赖目录路径推断分区	基于 Manifest 统计信息精确裁剪
多级分区变更	增加/删除层级非常困难	支持 ADD / DROP / REPLACE 灵活调整
隐藏分区	不支持，必须显式指定分区列	支持（如 `day(ts)` 自动生成分区值）
数据文件位置	必须位于分区目录下	任意位置，由清单管理

3.4 典型场景与误区复盘

场景一：从粗粒度到细粒度的演进

某用户行为分析平台，最初按 month(ts) 分区存储日志。半年后，业务方需要按天查询最近 7 天的数据，如果继续按月分区，每次查询都要扫描整个月的数据文件。通过 Iceberg 执行：

ALTER TABLE user_logs ADD PARTITION FIELD day(ts);

执行后，新写入的数据自动按天组织，历史数据仍然按月组织。查询时，Iceberg 对最近 7 天的数据走天级裁剪，对更早的数据按月裁剪，整体扫描量大幅下降。整个过程无需停服，也无需重写历史数据。

场景二：分区列选择失误的补救

某订单表最初按 order_status 分区，但实际查询几乎都按 order_time 过滤，导致分区裁剪失效。在 Hive 中，这种问题通常只能“忍痛重建”；在 Iceberg 中，可以平滑过渡：

-- 1. 先保留旧分区字段，新增正确的时间分区
ALTER TABLE orders ADD PARTITION FIELD day(order_time);

-- 2. 等待新数据按时间分区积累
-- 3. 可选：后台重写历史数据，使其也按时间分区
CALL iceberg.system.rewrite_data_files(table => 'orders');

-- 4. 确认无误后，移除旧分区字段
ALTER TABLE orders DROP PARTITION FIELD order_status;

常见误区与复盘

误区一：认为分区演进会立即重写所有历史数据。
实际上，ADD PARTITION FIELD 只是元数据变更，不触发数据移动。如果你希望历史数据也按新规则物理重排，必须显式执行 REWRITE DATA。

误区二：忽略隐藏分区的类型匹配。
例如对 ts 字段使用 day(ts) 后，查询条件必须能推导出分区值。如果查询写成 WHERE ts = '2024-05-15'（字符串），可能无法触发分区裁剪，应使用 WHERE ts = TIMESTAMP '2024-05-15' 或直接对分区字段过滤。

误区三：频繁演进分区导致元数据膨胀。
每次演进都会新增一个 spec 版本，如果每天反复 ADD/DROP，元数据历史会快速增长。建议在测试环境验证分区方案，再一次性演进到目标规则，避免无意义的版本堆积。

复盘要点

分区演进的核心价值是元数据与数据文件解耦，让表结构可以随业务灵活调整。
Iceberg 通过 spec-id 和 Manifest 实现多版本分区规则共存，查询时自动合并裁剪。
与 Hive 相比，Iceberg 的分区演进不需要重建表、不需要迁移数据、不需要停服，是数据湖表结构管理的重要能力。
实际使用中，要区分“元数据演进”和“物理数据重排”，按需执行 REWRITE DATA 优化存储布局。