4. 分区转换：identity、hour、day、month、year 等转换
Iceberg 的分区裁剪之所以高效，核心在于它把“分区值”与“数据文件路径”之间的映射关系固化在元数据中。但实际查询时，用户给出的过滤条件往往不是直接命中分区字段的原始值，而是需要经过一层函数或表达式转换才能落到分区字段上。例如，日志表按 event_ts（时间戳）做 day 分区，用户查询“今天下午的数据”，SQL 中写的是 WHERE event_ts >= '2025-01-15 13:00'，这个过滤条件并不会直接等于某个分区值，而是需要将时间戳转换为对应的日期分区。此时，Iceberg 的分区转换（Partition Transform）机制就决定了：能否从过滤条件中反推出需要扫描的分区集合，从而完成裁剪。
4.1 分区转换的本质：从“值”到“分区标识”的映射
分区转换定义了一条规则：输入一行数据的某一列值，输出该行数据所属的分区标识。Iceberg 内置了多种转换函数，最常用的包括：
- identity：原样输出，适用于按枚举值、ID、地区等低基数列直接分区。
- hour / day / month / year：从时间戳列中截取对应的时间粒度作为分区值。
- bucket：对列值做哈希后取模，将数据分散到固定数量的桶中。
- truncate：按指定长度截断字符串或数值，常用于长文本或高基数数值列。
这些转换在表定义时通过 PARTITIONED BY 子句声明，并写入 Iceberg 的 schema 中。每次写入数据时，Iceberg 根据转换函数计算每条记录的分区值，并将数据文件组织到对应的分区目录下。查询时，Iceberg 的 planner 会尝试将过滤条件中的谓词“反向推导”为分区值的范围或集合，从而跳过无关分区。
关键区别：Hive 等传统表分区是“物理目录 + 静态值”，而 Iceberg 的分区转换是“逻辑映射 + 元数据索引”。这意味着 Iceberg 的分区值不必与列值完全一致，而是可以通过函数动态推导，这为时间粒度裁剪提供了极大灵活性。
4.2 各转换的语义与裁剪能力对比
| 转换类型 | 输入示例 | 分区输出 | 典型查询谓词 | 裁剪能力 |
|---|---|---|---|---|
| identity | region='ap-south-1' | region=ap-south-1 | region = 'ap-south-1' | 等值/IN 直接命中 |
| hour | 2025-03-18T14:23:00 | 2025-03-18-14 | ts BETWEEN '14:00' AND '14:59' | 精确到小时范围 |
| day | 2025-03-18T14:23:00 | 2025-03-18 | ts >= '2025-03-18' AND ts < '2025-03-19' | 精确到天 |
| month | 2025-03-18T14:23:00 | 2025-03 | ts BETWEEN '2025-03-01' AND '2025-03-31' | 精确到月 |
| year | 2025-03-18T14:23:00 | 2025 | ts >= '2025-01-01' | 精确到年 |
从上表可以看出，转换粒度越细，裁剪精度越高，但分区数量也越多。例如按 hour 分区，一天会产生 24 个分区目录；按 year 分区则一年只有一个分区。实际设计时需要在“裁剪粒度”和“元数据开销”之间权衡。
4.3 分区转换如何驱动查询裁剪：一个完整案例
假设有一个电商订单表 orders，按 order_ts 做 day 分区，DDL 如下：
CREATE TABLE orders (
order_id BIGINT,
user_id BIGINT,
order_ts TIMESTAMP,
amount DECIMAL(10,2)
) USING iceberg
PARTITIONED BY (day(order_ts));写入几条数据后，Iceberg 元数据中记录的分区信息如下：
分区1: day(order_ts)=2025-03-18 → 文件1.parquet
分区2: day(order_ts)=2025-03-19 → 文件2.parquet
分区3: day(order_ts)=2025-03-20 → 文件3.parquet现在执行查询：
SELECT * FROM orders
WHERE order_ts >= '2025-03-19 10:00'
AND order_ts < '2025-03-20 22:00';Iceberg 的 planner 会执行以下推导步骤：
- 识别出过滤列
order_ts对应的分区转换是day。 - 将时间范围
[2025-03-19 10:00, 2025-03-20 22:00)映射为分区值集合：{2025-03-19, 2025-03-20}。 - 从元数据中查找这两个分区对应的文件列表，仅扫描文件2和文件3。
- 文件1（2025-03-18 的数据）被直接跳过，无需读取。
这个推导过程完全发生在规划阶段，不涉及数据扫描。下图展示了这一转换与裁剪的完整链路：
4.4 转换选择与查询模式的匹配策略
在实际建模时，分区转换的选择不能只看列类型，更要分析业务查询中最常见的过滤粒度。以下是几条经过验证的经验法则：
- 高频按天查询（如“查某天订单”“查最近7天”）→ 选择
day转换，裁剪粒度与查询粒度一致。 - 需要跨天但按小时聚合（如实时监控、小时级报表）→ 选择
hour转换，但要注意分区数量膨胀（一年约 8760 个分区），元数据压力较大。 - 历史归档表，查询多为月度或年度汇总 → 选择
month或year，减少分区数量，虽然单次扫描可能略多，但整体元数据更轻。 - 非时间列，但值域有限（如国家代码、渠道 ID）→ 使用
identity，等值过滤可直接裁剪。 - 高基数且无自然范围（如用户 ID、设备 ID）→ 使用
bucket，将数据均匀打散到固定桶数，避免小文件过多。
最佳实践：如果业务同时存在“按天查询”和“按月汇总”两种模式，优先选择 day 分区。因为 Iceberg 的元数据可以高效处理数千个分区，而 day 分区既能满足细粒度裁剪，又能在月汇总时通过读取多个连续分区实现，不会造成明显性能退化。
4.5 常见误区与排查
误区一：对时间戳列使用 identity 分区。如果直接按 order_ts 做 identity 分区，每个精确到毫秒的时间戳都会生成一个独立分区，导致分区数量爆炸，且查询时几乎无法裁剪——因为用户很少用精确时间戳等值过滤。正确做法是使用 day 或 hour 转换。
误区二：过滤条件与分区转换不匹配导致裁剪失效。例如表按 day(order_ts) 分区，但查询中写的是 WHERE date(order_ts) = '2025-03-18'。虽然语义上等价，但 Iceberg 的规划器无法自动将 date(order_ts) 反向推导为 day(order_ts) 的分区值，导致全表扫描。此时应改写为 WHERE order_ts >= '2025-03-18' AND order_ts < '2025-03-19'，让规划器能够直接利用分区转换。
误区三：忽略时区对时间分区的影响。如果写入端和查询端处于不同时区，同一个 UTC 时间戳可能被划分到不同的本地日期分区中。Iceberg 的时间分区转换默认基于 UTC，如果业务需要按本地时区分区，必须在写入前将时间戳转换为目标时区，否则会出现“数据进了前一天分区”的诡异问题。
排查裁剪是否生效，最直接的方法是查看执行计划中的 Scan Metrics 或使用 EXPLAIN 语句，确认 Partition Filters 中是否列出了预期的分区值集合。如果发现 Partition Filters 为空或包含过多分区，就需要回头检查过滤条件的写法是否与分区转换匹配。
总结来说，分区转换是 Iceberg 实现精准裁剪的基石。理解 identity、hour、day、month、year 等转换的语义，并让查询谓词与转换规则对齐，才能让 Iceberg 的元数据索引真正发挥作用，避免不必要的全表扫描。