星型模型是什么
星型模型是维度建模的默认形态：中心一张事实表，外围若干维度表，维度只与事实直接相连，不做多级范式拆分。代价是维度属性存在冗余，比如类目名称在商品维度里直接存一份；收益是查询 join 层数少、表关系一眼可见，BI 工具与各类分析引擎都对其友好。需要压缩冗余时才会引入雪花，那是针对特定场景的取舍，而不是为了让模型『更规范』。
基本信息
| 结构 | 1 张事实表 + N 张维度表 |
|---|---|
| 关联方式 | 维度只连事实，维度之间不互连 |
| 优点 | join 少、易理解、扫描列少、BI 友好 |
| 代价 | 维度存在冗余存储，调整属性需重刷维表 |
| 适配引擎 | 列存与云数仓均适用，压缩可摊薄冗余成本 |
典型使用场景
- 新建集市：不确定该不该雪花时先落星型，把复杂度留在可优化的一侧
- 自助分析：业务方拖拽维度做透视，两层结构不必解释多级 join 路径
- BI 报表性能调优：减少 join 层级直接降低查询耗时与错连风险
- 指标口径治理：维度属性只在维表维护一处，避免多份副本慢慢漂移
- 教学与交接：看 ER 图即可复述模型结构，沟通成本最低
星型查询示例
星型查询示例
-- 事实表存维度代理键，查询时按需 join 维度
SELECT d.day_name, -- 日期维度属性
p.category_l1, -- 商品维度一级类目
sum(f.qty) AS qty, -- 度量：销售数量
sum(f.amt) AS amt -- 度量：销售金额
FROM fact_sale f
JOIN dim_date d ON f.date_key = d.date_key
JOIN dim_product p ON f.product_sk = p.product_sk
GROUP BY 1, 2; -- 只需两层 join 即可出报表星型与雪花取舍
| 判断维度 | 倾向星型 | 倾向雪花 |
|---|---|---|
| 查询复杂度 | 自助分析、SQL 由业务方编写 | 固定报表，路径由开发维护 |
| 维度变更频率 | 类目层级稳定 | 层级频繁调整且共享面广 |
| 存储压力 | 可接受冗余 | 维度极大且重复率高 |
| 引擎特性 | 列存压缩后冗余成本低 | 宽维表显著影响 join 与 shuffle |
星型的冗余是设计选择而不是失误。真正需要警惕的是维表之间互相引用形成链路，那会让自助分析里的 join 路径变得不可预测，使用者很难判断该连哪张表。
围绕同一个事实表的一圈维度通常控制在十张以内较好落地；维度过多时先确认是否把同一概念的多个角色拆成了不同表，那类情况往往该用角色扮演而不是新增维表。