在数据仓库（Data Warehouse）的建设中，星型模型（Star Schema）和雪花模型（Snowflake Schema）是两种最主流的维度建模技术。它们的核心区别在于维度表（Dimension Table）的规范化程度。

为了理解这两个概念，首先需要知道两个基础组件：

• 事实表 (Fact Table)：存储业务过程中的度量值（如金额、数量、时长）和指向维度表的外键。数据量通常很大。
• 维度表 (Dimension Table)：存储业务的环境描述信息（如时间、地点、商品名称、用户属性）。

---

1. 星型模型 (Star Schema)

这是最简单、最常用的模型。

结构特点

• 中心化：一张巨大的事实表位于中心。
• 扁平化：周围环绕着一组维度表，每个维度表直接与事实表连接。
• 反范式化 (Denormalized)：维度表没有进一步拆分。例如，“商品维度表”中会直接包含“商品ID、商品名、类别名称、品牌名称”。即使有1000个商品属于同一个类别，“类别名称”也会重复存储1000次。

视觉形象

看起来像一颗星星，中间是事实，四周射出光芒（维度）。

优点

1. 查询性能高：这是最大的优势。因为维度表是扁平的，查询时通常只需要做一次 Join（事实表 Join 维度表），减少了多表关联的开销。
2. 易于理解：结构简单直观，业务人员容易看懂。
3. 分析简单：对于 BI 工具（如 Tableau, PowerBI）非常友好。

缺点

1. 数据冗余：因为反范式化，维度表中存在大量重复数据（如上述的类别名称）。
2. 维护成本稍高：如果“类别名称”变了，需要更新所有包含该类别的商品记录（虽然在数仓中维度更新频率通常较低）。

---

2. 雪花模型 (Snowflake Schema)

这是星型模型的变体，是对星型模型的进一步规范化。

结构特点

• 层次化：维度表被进一步拆分（规范化）。
• 范式化 (Normalized)：遵循数据库第三范式（3NF）。例如，“商品维度表”只存“商品ID、商品名、类别ID”；然后通过“类别ID”关联到一张独立的“类别维度表”，里面存“类别ID、类别名称”。
• 由内向外延伸：事实表连接主维度表，主维度表再连接子维度表。

视觉形象

看起来像一片雪花，从中心向外辐射并分叉。

优点

1. 数据冗余极低：数据高度结构化，节省存储空间（在早期存储昂贵时很重要）。
2. 数据一致性好：如果“类别名称”变了，只需要修改“类别表”中的一条记录，不需要更新成千上万条商品记录。

缺点

1. 查询性能较差：获取完整的业务信息需要大量的 Join 操作（事实表 -> 商品表 -> 类别表 -> 品牌表）。在海量数据下，Join 是性能杀手。
2. 逻辑复杂：模型结构复杂，编写 SQL 语句困难，业务人员难以直接使用。

---

3. 核心对比 (VS)

---

4. 总结与选型建议

现在的趋势是：绝大多数大数据数仓（如 Hive, Spark, ClickHouse, Doris）首选星型模型。

为什么现在更倾向于星型模型？

1. 存储便宜：现在的存储成本极低，数据冗余带来的空间浪费可以忽略不计。
2. 计算昂贵：在分布式计算中，Shuffle 和 Join 是最消耗资源和时间的操作。星型模型通过“空间换时间”，极大提升了分析效率。
3. 大宽表趋势：现代数仓甚至会将星型模型进一步退化，将维度直接整合进事实表中，形成一张极大的“宽表”（Wide Table），完全避免 Join，以达到极致的查询速度（如 ClickHouse 的用法）。

什么时候用雪花模型？

• 维度表本身数据量极其巨大，且存在明显的层级关系，全部打平会导致维度表过大难以加载。
• 业务系统的源数据本身就是高度范式化的，且数仓层级较低（如 ODS 层或 DWD 层），为了保持数据原貌，可能会暂时保留雪花结构。
• 维度属性变更非常频繁，且对数据一致性要求极高。

补充：星座模型 (Galaxy Schema)

除了上述两种，还有一个星座模型。它其实就是多个星型模型的集合。

• 当数仓中包含多个事实表（例如：销售事实表、库存事实表），而它们共享某些维度表（例如：时间维度、商品维度）时，就形成了星座模型。这是企业级数仓最真实的形态。