大维度为什么要专门优化
上亿行的客户或商品维度会同时放大三类成本：存储、关联时的洗牌数据量、以及加载时的排序开销。常用手段是代理键用整数或低碰撞哈希、高基数属性做字典编码、按关联键分桶，让维度与事实能做桶对桶关联，减少洗牌。
基本信息
| 代理键 | bigint 整数键或低碰撞哈希值 |
|---|---|
| 字典编码 | 高基数文本属性映射为整数编码 |
| 分桶 | 按关联键哈希分桶，维表与事实表桶数一致 |
| 压缩 | 列式存储配合字典编码，压缩比通常很高 |
| 分区 | 当前版本集中在最新分区，便于裁剪 |
典型使用场景
- 客户维度：上亿会员的画像属性与关联优化
- 商品维度：SKU 级明细的商品名称与类目关联
- 设备维度：海量设备标识的映射与去重
- 关联优化：桶数一致时避免全量洗牌
- 存储优化：字典编码与列式压缩显著降低存储成本
分桶建表
分桶建表
-- Hive 分桶：按自然键哈希分桶，桶数与事实表保持一致
CREATE TABLE dim_product (
product_sk bigint COMMENT '代理键',
product_id string COMMENT '商品编码',
product_name string COMMENT '商品名称',
cat_id int COMMENT '类目编码'
)
CLUSTERED BY (product_id) INTO 64 BUCKETS
STORED AS ORC;优化手段与代价
| 优化手段 | 作用 | 代价 |
|---|---|---|
| 整数代理键 | 关联与存储成本低 | 需要额外维护映射 |
| 字典编码 | 高基数字段占用下降 | 编码表要同步维护 |
| 分桶 | 桶对桶关联省洗牌 | 桶数不一致时失效 |
| 当前版本单独分区 | 扫描量明显下降 | 需要额外维护逻辑 |
维表与事实表的分桶数必须一致：否则优化器无法做桶对桶关联，仍然走全量洗牌，优化收益为零。
高基数字符串直接做关联键是常见性能陷阱：换成整数编码或哈希键后洗牌数据量明显下降，但编码映射表要纳入日常维护。