全栈攻城狮

Appearance

数据仓库核心概念 ​

概述 ​

数据仓库（Data Warehouse）是面向主题、集成、稳定、随时间变化的数据集合，服务于决策分析。理解数仓，先要分清两大建模流派：Kimball 的维度建模与 Inmon 的企业信息工厂，以及星型/雪花型/星座型三种模型形态。本文把这些概念一次讲透。

一、什么是数据仓库 ​

1.1 四大特征 ​

特征说明
面向主题按业务主题（订单、用户、商品）组织，而非按业务过程
集成来自多源的数据统一编码、口径、单位后进入仓库
稳定进入仓库的数据一般不更新，只随时间追加
随时间变化数据带时间维度，支持历史对比与趋势分析

1.2 与业务库（OLTP）的对比 ​

维度业务库 OLTP数据仓库 OLAP
目的支撑业务交易支撑分析决策
读写高并发小事务大批量复杂查询
建模范式建模（3NF）维度建模（星型）
数据当前状态历史 + 汇总
更新频繁增删改批量追加覆盖
典型引擎MySQL/PostgreSQLHive/ClickHouse/Doris

二、两大建模流派 ​

2.1 Inmon：自顶向下，范式建模 ​

Inmon 认为数仓应自顶向下构建：先建企业级规范化数仓（3NF），再从数仓派生各主题数据集市。

数据源 → ETL → 企业数仓（3NF 范式，单一事实来源）→ 数据集市（按部门）
优点缺点
企业级统一，消除数据冗余建设周期长、见效慢
数据一致性最佳3NF 查询需多表 Join，性能差

2.2 Kimball：自底向上，维度建模 ​

Kimball 主张自底向上：直接按业务过程建维度模型（星型），先建部门数据集市，再整合成企业数仓。

数据源 → 数据暂存区 → 维度建模（星型，事实表 + 维度表）→ 汇总给上层
优点缺点
见效快，先出成果各集市可能口径不一致，后期整合难
查询性能好，易理解维度冗余需靠规范控制

2.3 现实中的选择 ​

实践中很少有纯 Inmon 或纯 Kimball，主流是Kimball 维度建模为主体（各层仍按 ODS/DWD/DWS/ADS 分层），个别企业级主数据（如用户、商品）用 Inmon 的规范模型作为维度主数据（DIM）。

三、维度建模核心元素 ​

3.1 事实表（Fact Table） ​

记录业务过程的度量，行代表一次业务事件：

元素说明示例（订单事实表）
外键引用各维度user_id、product_id、date_id
度量可加性数值amount、quantity、discount
退化维度留在事实表的业务主键order_no

度量三类型：可加（金额，跨维度求和）、半可加（余额，只对部分维度可加）、不可加（比率，需重新计算）。

3.2 维度表（Dimension Table） ​

描述事实的上下文（谁、什么、何时、何地），是分析的口径来源：

元素说明
代理键数仓内部主键，与业务无关，隔离业务键变化
自然键业务系统主键（如用户 ID）
属性分析所需的描述字段（性别、城市、品类）

维度表小而宽（列多行少），事实表大而窄（行多列少）。

四、三种模型形态 ​

4.1 星型模型 ​

事实表居中，维度表直接与事实表关联，维度不做规范化（含冗余）：

                用户维度
                 /
订单事实表 —— 商品维度
                 \
                时间维度
优点缺点
查询快，Join 次数少维度表冗余，更新需维护
结构直观，易理解维度层级信息分散

4.2 雪花型模型 ​

维度表进一步规范化，拆出层级子表：

用户维度 → 城市表 → 省份表
优点缺点
消除维度冗余，节省存储Join 层级多，查询变慢
维度标准化复杂度高，维护难

4.3 星座型模型（事实星座） ​

多个事实表共享维度表（一致性维度）：

用户维度 ─┬─ 订单事实表
          └─ 售后事实表

共享维度保证了跨事实表的口径一致，是现代数仓的标准形态。

4.4 选型建议 ​

场景模型
绝大多数分析场景星型 + 星座
存储极紧张、维度层级稳定雪花型
企业级统一口径星座型 + 一致性维度

五、建模流程 ​

1. 明确业务过程（要分析什么：下单、支付、退款）
2. 声明粒度（一行代表什么：一笔订单、一个订单项）
3. 确定维度（分析角度：时间、用户、商品、渠道）
4. 确定事实（度量指标：金额、数量）
5. 冗余维度属性和退化维度
6. 生成模型（星型/星座），校验口径

粒度声明是最关键的一步：粒度不清，后续所有指标都无法对齐。例如"订单粒度"与"订单明细粒度"，总额相同但件数不同。

六、常用指标口径 ​

指标定义要点常见坑
GMV下单金额口径（含未支付）是否含取消单
净成交额支付且未退款退款时间点归属
活跃用户当日有行为用户数去重口径（按用户 ID）
复购率多次购买用户占比时间窗口定义

指标口径必须落在模型设计的度量定义中，并在元数据里记录，这是数仓规范的根基。

小结 ​

掌握 Kimball/Inmon 之争的本质是"自底向上 vs 自顶向下"，星型/雪花/星座的选择本质是"性能 vs 规范"的权衡。下一节的分层架构，就是把这些模型按 ODS/DWD/DWS/ADS 落到具体层次。