4、分区策略优化：分区字段选择、分区粒度控制、隐藏分区与分区裁剪
分区，是 Iceberg 成本优化的第一道防线。
很多人觉得分区就是按日期分个文件夹，没什么技术含量。其实不然。分区策略选得好，查询能快 10 倍，存储能省一半。选得不好，那就是给自己挖坑。
我见过一个团队，把分区粒度做到了小时级，结果小文件多到把元数据服务打崩了。也见过有人分区字段选错了，查询时全表扫描，跑一次要半小时。嗯，这些坑我都踩过。
核心观点：分区不是越细越好，也不是越粗越好。关键是在查询模式和数据特征之间找到平衡点。
4.1 分区字段选择：选对字段，事半功倍
分区字段的选择，直接决定了分区裁剪的效果。选错了，分区就是个摆设。
我个人的选择原则：
- 高频过滤字段优先：查询中
WHERE条件最常用的字段，优先作为分区键。比如日志表按event_date分区，订单表按order_date分区。 - 低基数优先：分区字段的取值数量要适中。太少了（比如性别，只有男女）分区没意义；太多了（比如用户ID，几千万个）分区数爆炸，元数据扛不住。
- 时间字段是首选：绝大多数场景下，时间字段是最佳分区键。数据天然有时间属性，查询也常按时间范围过滤。
- 避免高基数字段：像
user_id、transaction_id这种唯一值极多的字段，千万别直接分区。我见过有人用user_id分区，结果生成了上百万个分区目录，查询计划生成都要好几秒。
小技巧：如果必须用高基数字段做过滤，可以考虑先做 bucket 或 truncate 转换，降低基数后再分区。Iceberg 的隐藏分区天然支持这种模式。
4.2 分区粒度控制：粗了浪费，细了崩溃
分区粒度，说白了就是每个分区里装多少数据。
我建议的粒度参考：
| 数据量级 | 推荐分区粒度 | 典型场景 |
|---|---|---|
| 每天 < 100MB | 按月或按季度 | 小规模业务日志 |
| 每天 100MB ~ 10GB | 按天 | 常规业务表 |
| 每天 10GB ~ 100GB | 按小时 | 高流量埋点、IoT 数据 |
| 每天 > 100GB | 按小时或半小时 | 实时流计算、监控指标 |
为什么不能太细？
- 小文件问题：分区粒度太细，每个分区数据量少，文件数量多。Iceberg 虽然比 Hive 好一些，但小文件太多依然会影响元数据操作和查询性能。
- 元数据膨胀：每个分区在 Iceberg 元数据中都有记录。分区数过多，元数据文件变大，查询计划生成变慢。
- 写入放大：频繁的
INSERT操作如果分散到大量分区，每次都要更新元数据，写入性能下降。
为什么不能太粗？
- 分区裁剪失效：粒度太粗，查询时不得不扫描大量无关数据。比如按月分区，你只想查某一天的数据，却要扫整个月。
- 并发写入冲突：多个写入任务同时操作同一个分区，容易产生冲突，影响写入效率。
避坑指南：我曾经接手过一个项目，分区粒度按小时，但每天数据量只有 200MB。结果每个小时分区里只有几十 MB 数据，文件数却有好几十个。查询时元数据解析占了 60% 的时间。后来改成按天分区，查询性能提升了 3 倍。
4.3 隐藏分区：Iceberg 的杀手锏
隐藏分区是 Iceberg 最让我喜欢的功能之一。它解决了传统分区的一个大痛点：分区字段必须显式出现在数据中。
传统 Hive 分区，你得在数据里加一个 dt 字段，然后手动指定 PARTITION (dt='2024-01-01')。Iceberg 的隐藏分区完全不需要。
隐藏分区怎么用？
你只需要在建表时定义分区转换函数，Iceberg 会自动从原始字段推导出分区值。
-- 传统方式：需要显式维护 dt 字段
CREATE TABLE events (
event_ts TIMESTAMP,
event_data STRING
) PARTITIONED BY (dt STRING);
-- Iceberg 隐藏分区：自动从 event_ts 推导
CREATE TABLE events (
event_ts TIMESTAMP,
event_data STRING
) USING iceberg
PARTITIONED BY (days(event_ts));
Iceberg 支持的隐藏分区转换：
| 转换函数 | 说明 | 适用场景 |
|---|---|---|
years(ts) |
按年分区 | 历史归档表 |
months(ts) |
按月分区 | 中等规模时间序列 |
days(ts) |
按天分区 | 常规业务表 |
hours(ts) |
按小时分区 | 高吞吐实时数据 |
bucket(N, col) |
哈希分桶，N 为桶数 | 高基数字段均匀分布 |
truncate(L, col) |
截断字符串，L 为长度 | 字符串前缀分区 |
隐藏分区的优势：
- 无侵入：不需要在数据中额外维护分区字段，减少数据冗余。
- 自动推导：写入时自动计算分区值，不需要手动指定。
- 分区进化：可以随时修改分区策略，不需要重写历史数据。
- 查询透明：用户查询时不需要关心分区结构，Iceberg 自动做分区裁剪。
个人经验：我建议所有时间序列表都优先使用 days() 或 hours() 隐藏分区。它让代码更干净，也让分区策略的调整更灵活。有一次业务方要求把分区粒度从天改成小时，我只需要改一行建表语句，历史数据完全不受影响。
4.4 分区裁剪：Iceberg 的查询加速引擎
分区裁剪，就是查询时只扫描相关分区，跳过无关数据。Iceberg 的分区裁剪比 Hive 强在哪？
Hive 的分区裁剪：
- 只能基于显式分区字段做过滤。
- 如果查询条件不是分区字段，全表扫描。
- 分区信息存储在 Hive Metastore 中，查询计划阶段读取。
Iceberg 的分区裁剪：
- 支持隐藏分区，自动推导分区值。
- 支持复杂过滤条件，比如
BETWEEN、IN、>、<。 - 分区信息存储在 Iceberg 元数据文件中，查询时直接读取，不需要访问 Metastore。
- 支持 分区统计信息，进一步过滤文件级别的数据。
分区裁剪的生效条件：
- 查询的
WHERE条件必须包含分区字段（或隐藏分区字段）。 - 过滤条件必须是可推导的，比如
=、IN、BETWEEN、>、<。 - 分区字段不能有函数包裹，比如
WHERE year(event_ts) = 2024不会触发分区裁剪，但WHERE event_ts BETWEEN '2024-01-01' AND '2024-01-31'可以。
避坑指南：我曾经看到有人写 WHERE DATE_FORMAT(event_ts, 'yyyy-MM-dd') = '2024-01-01'，结果分区裁剪完全没生效，全表扫描跑了 20 分钟。改成 WHERE event_ts >= '2024-01-01' AND event_ts < '2024-01-02' 后，秒级返回。记住：不要在分区字段上套函数。
4.5 分区策略优化实战：一个完整的例子
假设我们有一个用户行为日志表，每天约 50GB 数据，查询模式如下：
- 80% 的查询按天范围过滤。
- 15% 的查询按用户 ID 过滤。
- 5% 的查询按事件类型过滤。
优化前的分区策略：
-- 按天分区，但用户 ID 查询时全表扫描
CREATE TABLE user_events (
event_ts TIMESTAMP,
user_id STRING,
event_type STRING,
event_data STRING
) USING iceberg
PARTITIONED BY (days(event_ts));
优化后的分区策略：
-- 按天分区 + 用户 ID 分桶，兼顾两种查询模式
CREATE TABLE user_events (
event_ts TIMESTAMP,
user_id STRING,
event_type STRING,
event_data STRING
) USING iceberg
PARTITIONED BY (days(event_ts))
CLUSTERED BY (user_id) INTO 100 BUCKETS;
优化效果：
| 查询类型 | 优化前 | 优化后 | 提升 |
|---|---|---|---|
| 按天范围查询 | 扫描 1 天数据 | 扫描 1 天数据 | 不变 |
| 按用户 ID 查询 | 全表扫描（30 天） | 扫描 1 个分桶（1/100） | 约 100 倍 |
| 按事件类型查询 | 全表扫描（30 天） | 全表扫描（30 天） | 不变（需其他优化） |
个人建议：分区策略不是一次定死的。随着业务发展，查询模式会变。Iceberg 支持分区进化，你可以随时调整。我一般每季度 review 一次分区策略，看看有没有优化空间。
4.6 分区策略知识体系
下面这张图总结了分区策略优化的核心逻辑，你可以对照着梳理自己的表。
这张图把分区策略优化的四个维度串起来了。你设计分区时，可以对照着问自己几个问题：
- 我的查询最常用哪些字段做过滤？——对应「分区字段选择」
- 每天数据量多大？查询的时间范围多宽？——对应「分区粒度控制」
- 能不能用隐藏分区简化代码？——对应「隐藏分区」
- 查询条件能不能触发分区裁剪？——对应「分区裁剪」
把这四个问题想清楚，你的分区策略基本不会差到哪里去。