星型模型 vs 雪花模型
总结
| 记忆点 | 内容 |
|---|---|
| 事实表 | 存度量（金额、次数），粒度要明确 |
| 维度表 | 存描述（属性），用于筛选和分组 |
| 星型模型 | 一层维度，JOIN少，查询快，优先选 |
| 雪花模型 | 维度规范化，JOIN多，存储省 |
| 选型原则 | 大多数OLAP场景选星型，别过度设计 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
基础 | 大数据面试 · 数仓建模系列
| 面试真题 星型模型和雪花模型有什么区别？你们公司用的是哪种？为什么？ |
|---|
先搞懂维度建模的两块砖
Kimball维度建模，核心就两类表：
事实表（Fact Table）存业务度量：订单金额、点击次数、播放时长。粒度必须明确——一行代表什么？一笔订单？一次点击？通常数据量很大，是数仓里最「胖」的表。
维度表（Dimension Table）存描述信息：用户属性、商品分类、地区信息。用于筛选、分组、过滤。数据量相对小，但字段多。
打个比方：事实表是「考试成绩单」（谁考了多少分），维度表是「学生花名册」（叫什么、哪个班、男生女生）。分析时把两张表JOIN起来，就能回答「三年级男生的平均成绩是多少」。
星型 vs 雪花，核心区别
对比项 | ⭐ 星型模型 | ❄ 雪花模型 |
|---|---|---|
结构 | 事实表 + 一层维度表 | 维度表进一步拆分（规范化） |
JOIN数 | 少，查询快 | 多，查询慢 |
冗余 | 有冗余（维度表宽） | 低冗余（维度拆到第三范式） |
易理解 | 直观，业务友好 | 复杂，要理解层级关系 |
ETL | 简单 | 复杂 |
适用场景 | 大多数OLAP分析（首选） | 维度层级很深、存储敏感场景 |
举个例子理解区别
订单分析场景：
星型模型：事实表fact_order直接关联一张dim_user，dim_user里把city、province、country都塞在一张表里。有冗余但查询只需要一次JOIN。
雪花模型：dim_user只存city_id，再关联dim_city → dim_province → dim_country，拆成4层。没冗余但查询要JOIN 4张表，性能差且维护复杂。
直观来说，星型模型的结构就像一颗星星——事实表在中间，维度表像射线一样围绕在周围，每张维度表只有一层。雪花模型则是维度表本身又展开了分支，像雪花的结晶一样。
实际工作中怎么选？
结论：90%的场景选星型模型。
我做了9年数据开发，经历过4家公司，全部用的星型模型为主。原因有四个：
第一，OLAP引擎更擅长扫描宽表，多次JOIN反而是瓶颈。不管是Doris、Hologres还是ClickHouse，都是宽表扫描性能更好。
第二，业务变化快，维度表拆太细的话，加个字段要改好几张表。小公司的业务变化尤其快，昨天还在做短剧，今天可能就加了小说业务线。
第三，磁盘便宜，冗余那点存储成本完全可以接受。现在云存储的价格，一年多花几百块存储费，换来查询性能的大幅提升，绝对划算。
第四，团队理解成本低，新人来了看星型模型一目了然。小公司团队通常只有3-5个人，维护简单比极致规范化更重要。
| Wood的实战经验 什么时候考虑雪花？维度层级特别深的时候，比如组织架构树有7-8层，并且有严格的数据规范化要求。但说实话，我至今没在生产环境中用过纯雪花模型。 如果你也没用过，面试时诚实说就行，不要硬编。面试官更看重你是否理解两者的区别和选型逻辑，而不是你用过多少种模型。 |
|---|
| 面试加分提示 面试官问「为什么选星型」时，不要只说「查询快」，要从业务场景出发： 「我们选星型模型，主要考虑三点：第一，业务分析以多维聚合查询为主，星型模型JOIN少查询效率更高；第二，我们用Doris/Hologres做查询引擎，天然擅长宽表扫描；第三，团队只有3个人，维护简单比极致规范化更重要。」 把技术选型和团队规模、业务场景、技术栈结合起来说，这才是高级别的回答。 |
|---|