2、数据集市架构设计：星型模型、雪花模型、星座模型的选择与对比，以及维度建模的核心原则。
好，咱们进入第二章。这一章是数据集市设计的核心，说白了就是「怎么把数据摆得又好用又好看」。我见过太多项目，ETL 写得飞起，结果业务方一查数就卡死，或者根本看不懂表结构。嗯，这往往就是模型选型出了问题。
我个人习惯，在动手建表之前，先花半天时间把模型定下来。你想想看，地基歪了，后面装修再漂亮也白搭。咱们今天就把星型、雪花、星座这三个模型掰开揉碎，再聊聊维度建模那几条铁律。
2.1 维度建模的核心原则
先讲原则，再讲招式。维度建模不是拍脑袋想出来的，它有几条硬规矩。我刚开始做数仓时，觉得这些条条框框太死板，后来被坑过几次才明白——规矩都是血泪换来的。
维度建模四大核心原则：
- 原则一：业务驱动 —— 模型必须回答业务问题，而不是为了技术炫技。我曾经见过一个团队，把表拆了十几层，结果业务方要的「本月销售额」跑了三分钟没出来。
- 原则二：原子数据不可逆 —— 最细粒度的数据必须保留。你永远不知道明天业务方会问什么奇葩问题。聚合后的数据丢了细节，那就再也找不回来了。
- 原则三：一致性维度 —— 同一个「客户」在不同数据集市里，定义必须一样。否则就会出现「A 部门说客户 1000 人，B 部门说 1200 人」的扯皮现场。
- 原则四：面向过程 —— 事实表记录「发生了什么」，维度表描述「谁、什么、在哪、何时」。别把状态和事件混在一起。
这四条原则，我建议你打印出来贴在工位上。每次建模前问自己一遍：我违反了吗？
2.2 星型模型
星型模型，最经典、最常用，也是我个人的首选。结构很简单：中间一张事实表，周围一圈维度表，像星星一样辐射出去。
为什么它这么流行？
- 查询性能好 —— 关联次数少，一张事实表直接 JOIN 维度表，SQL 写起来也清爽。BI 工具最喜欢这种结构。
- 易于理解 —— 业务方看一眼就能明白：「哦，这个是订单事实，那个是客户维度，那个是产品维度。」
- 易于扩展 —— 加一个新维度？直接加一张表，事实表加个外键就行。
我的经验： 80% 的数据集市场景，星型模型就够了。别为了「看起来高级」去搞复杂模型。我在一个零售项目中，全部用星型模型，业务方自己写 SQL 都能搞定，运维成本极低。
当然，星型模型也有缺点。维度表会存在一些冗余。比如「产品维度」里，如果产品类别信息很多，每个产品都重复存一遍类别名称，会浪费一点存储。但说实话，现在存储这么便宜，用空间换时间，值。
2.3 雪花模型
雪花模型是星型模型的「规范化」版本。它把维度表进一步拆分成更细的层次。比如「产品维度」拆成「产品表」和「产品类别表」，「客户维度」拆成「客户表」和「城市表」。
结构看起来像雪花一样，一层层散开。
什么时候用雪花模型？
- 维度层次深且稳定 —— 比如地理维度：省→市→区，层级固定，很少变化。
- 存储极度敏感 —— 虽然现在很少见，但如果你在存储成本受限的环境下，雪花模型能省不少空间。
- 数据源本身就是规范化设计 —— 直接从 OLTP 系统拿数据，不做太多转换，保留原样。
避坑指南： 我曾经在一个项目中，为了追求「完美规范化」，把维度表拆了五层。结果呢？一个简单的报表查询，要 JOIN 七八张表，性能惨不忍睹。业务方直接投诉：「你们的数据集市怎么比 ERP 还慢？」
后来我全部改回星型模型，查询时间从 30 秒降到了 0.5 秒。嗯，从那以后我对雪花模型就谨慎多了。
雪花模型不是不能用，但要控制拆分的深度。我个人建议：最多拆两层。超过两层，收益就远小于代价了。
2.4 星座模型
星座模型，也叫事实星座模型。它包含多个事实表，共享一部分维度表。结构看起来像星座，多个星星（事实表）共用同一片天空（维度表）。
典型场景： 一个电商平台，既有「订单事实表」，又有「退货事实表」，还有「库存快照事实表」。它们都共享「客户维度」、「产品维度」、「时间维度」。
星座模型的优势：
- 维度复用 —— 一套维度表，多个事实表共用。维护成本低，一致性高。
- 跨过程分析 —— 可以同时分析「下单」和「退货」的关系，比如「哪些客户退货率高？」
- 企业级架构 —— 适合构建企业级数据仓库，多个数据集市共享核心维度。
注意： 星座模型不是独立于星型和雪花之外的「第三种模型」，而是多个星型/雪花模型的组合。你可以把它理解为「星型模型的集群」。
2.5 三种模型对比
咱们用一张表把区别说清楚。我习惯在项目立项阶段，拿这张表跟业务方和技术团队对齐，避免后期扯皮。
| 对比维度 | 星型模型 | 雪花模型 | 星座模型 |
|---|---|---|---|
| 结构复杂度 | 低，一张事实表 + 多张维度表 | 中，维度表有层次拆分 | 高，多张事实表 + 共享维度 |
| 查询性能 | 高，JOIN 次数少 | 中，JOIN 次数多 | 高，但跨事实表查询需注意 |
| 存储冗余 | 高，维度表有冗余 | 低，规范化后冗余少 | 中，维度表共享减少冗余 |
| 易用性 | 高，业务方容易理解 | 中，需要理解层次关系 | 中，需要理解多个事实表 |
| 维护成本 | 低 | 中 | 中高 |
| 适用场景 | 单业务过程，如订单分析 | 维度层次深且稳定 | 多业务过程，企业级数仓 |
你看，没有的好坏，只有合不合适。我个人的选择优先级是：星型 > 星座 > 雪花。除非有非常明确的理由，否则先用星型。
2.6 如何选择？一个决策框架
光讲理论不行，咱们来点实操。我总结了一个简单的决策流程，你照着走一遍，基本不会出错。
- 先问：这个数据集市覆盖几个业务过程？
- 一个 → 走星型或雪花
- 多个 → 走星座
- 再问：维度表有没有深层次且稳定的层级？
- 有，且层次不超过 2 层 → 可以考虑雪花
- 没有，或层次浅 → 星型
- 最后问：团队和业务方的技术能力如何？
- 业务方自己写 SQL → 星型，别犹豫
- 有专业数仓团队 → 可以适当用雪花或星座
我的建议： 新手先死磕星型模型。等你把星型玩透了，自然就知道什么时候该用雪花，什么时候该上星座。别一上来就搞复杂架构，容易翻车。
2.7 知识体系总览
下面这张图，我把本章的核心逻辑画出来了。你保存下来，建模时对照着看。
这张图把咱们今天讲的内容串起来了。从核心原则出发，分支出三种模型，每种模型有各自的特点，最后落到选择建议上。你建模时，就按这个框架走。
2.8 小结
这一章内容不少，我帮你捋一下重点：
- 维度建模四条原则：业务驱动、原子数据、一致性维度、面向过程。这是根基。
- 星型模型：简单、快、易用。我的首选，也是你的首选。
- 雪花模型：规范化、省存储，但别拆太深。最多两层。
- 星座模型：多事实表共享维度，企业级架构的标配。
- 选择框架：先看业务过程数量，再看维度层次，最后看团队能力。