📚 课程目录第2章维度建模核心概念

维度建模核心概念：事实表、维度表、星型模型、雪花模型、星座模型详解

好，咱们正式开始啃维度建模的硬核内容。这一章是整门课的基石，你把它吃透了，后面实时数仓的融合设计才能游刃有余。

我记得刚入行那会儿，带我的老大哥扔给我一本 Kimball 的《数据仓库工具箱》，说「看完前四章再来找我」。结果我翻了三天，脑子里全是「事实」「维度」「粒度」这些词，就是串不起来。后来真正上手做项目，踩了几个坑，才明白这些概念到底在说什么。

今天我就用最直白的方式，把这些核心概念给你拆开揉碎。

1. 事实表：业务事件的「快照」

事实表，说白了就是记录「发生了什么」的表。每一行代表一次业务事件，比如一笔订单、一次点击、一次登录。

事实表的核心特征：

可加性度量：金额、数量、时长，这些数值可以随意聚合
外键指向维度：每个事实行都关联着多个维度表的主键
粒度决定一切：一行代表什么，粒度就是什么

粒度陷阱：我见过最坑的项目，是把订单头信息和订单明细混在同一张事实表里。结果想算「每个用户的平均订单金额」，怎么算都不对。后来发现，一行代表的是订单明细行，不是订单本身。粒度没对齐，分析全白费。

事实表有三种类型，我习惯用这个表格来区分：

类型	特点	典型场景	我踩过的坑
事务事实表	每事件一行，最细粒度	订单支付、点击流	数据量爆炸，忘了做分区
周期快照事实表	固定周期汇总，如每天	账户余额、库存快照	快照时间没对齐，导致数据对不上
累积快照事实表	记录全生命周期	订单流转、工单处理	状态字段太多，维护成本高

我的建议：刚开始做设计，优先选事务事实表。它最灵活，也最容易理解。等业务稳定了，再考虑用快照表做性能优化。

2. 维度表：业务描述的「字典」

维度表就是用来「描述事实」的。它回答的是谁、什么、哪里、何时这些问题。

维度表的设计要点：

单一主键：通常是自增 ID 或业务主键
冗余设计：允许反范式化，把相关属性都塞进来
缓慢变化维度：属性变了怎么办？这是个大坑

举个例子，用户维度表：

-- 用户维度表（典型设计）
CREATE TABLE dim_user (
    user_sk INT PRIMARY KEY,        -- 代理键
    user_id VARCHAR(20),            -- 业务主键
    user_name VARCHAR(50),
    register_date DATE,
    city VARCHAR(30),
    province VARCHAR(30),
    level VARCHAR(10),
    effective_date DATE,            -- SCD2 生效时间
    expire_date DATE,               -- SCD2 失效时间
    is_current CHAR(1)              -- 是否当前版本
);

为什么维度表要冗余？你想想看，如果用户的城市和省份分开存两张表，每次查询都要 JOIN，性能能好吗？维度建模的核心思想就是「用空间换时间」。

3. 星型模型：最经典的数仓架构

星型模型，就是一张事实表在中间，周围围着多张维度表。形状像星星，所以叫星型。

它的优点很明显：

查询性能好，JOIN 路径短
业务理解容易，业务人员一看就懂
扩展方便，加个维度表就行

我曾经在一个电商项目中，坚持用星型模型重构了原来的雪花模型。查询时间从 30 秒降到了 2 秒。业务方直接说「你们终于把数仓做快了」。

4. 雪花模型：规范化但别过度

雪花模型是星型模型的「规范化版本」。维度表不再是一张大宽表，而是拆成多个层级。

比如，用户维度表里有个城市字段，雪花模型会把城市单独拆成一张表，再关联省份表。

这样做的好处是节省存储，但代价是查询变慢。我个人不太推荐在数仓里用雪花模型。为什么？

数仓的存储成本已经很低了
查询性能才是第一位的
业务人员看不懂多层 JOIN

注意：雪花模型不是不能用，但要有节制。我见过一个项目，维度表拆了 7 层，最后连开发人员自己都搞不清怎么 JOIN 了。这种过度设计，还不如用回星型。

5. 星座模型：多事实表共享维度

星座模型，也叫事实星座。就是多个事实表共享同一套维度表。

举个例子，订单事实表和退款事实表，都共用用户维度、时间维度、商品维度。这就是星座模型。

它的核心价值在于：

一致性维度：同一个维度，在不同事实表里定义完全一样
交叉分析：可以同时分析订单和退款，维度口径一致
维护成本低：改一个维度表，所有事实表都受益

我在做金融数仓时，就用了星座模型。交易事实表、风控事实表、对账事实表，全部共享客户维度和产品维度。这样出报表的时候，数据口径完全一致，再也不用扯皮了。

6. 三种模型对比

维度	星型模型	雪花模型	星座模型
查询性能	高	低	高
存储成本	高（冗余）	低（规范化）	中
易用性	高	低	高
扩展性	中	高	高
适用场景	大多数 OLAP 场景	存储敏感、查询简单	多业务线、共享维度

7. 核心知识体系图

下面这张图，把本章的核心概念串起来了。你可以把它当作思维导图来用。

8. 避坑指南

最后，分享几个我这些年踩过的坑，你遇到了可以少走弯路。

我曾经犯过的错：

事实表粒度不统一：同一个事实表里，有的行代表订单，有的行代表订单明细。后来查数据对不上，查了三天才发现问题。
维度表没有代理键：直接用业务主键当维度主键。结果业务系统改了主键规则，历史数据全乱了。
过度使用雪花模型：为了省存储，把维度表拆了又拆。最后查询要 JOIN 七八张表，性能惨不忍睹。

我的建议：

先画星型模型，再考虑要不要转雪花
事实表粒度一定要在文档里写清楚
维度表一定要用代理键，别偷懒
多事实表共享维度时，确保维度定义完全一致

嗯，这一章的内容就到这儿。概念虽然多，但核心就一句话：事实表记录发生了什么，维度表描述谁在什么时间什么地方做的。把这个逻辑刻在脑子里，后面的实时数仓设计就不会跑偏。