数据仓库建模三大方法：维度建模、范式建模、Data Vault一次讲清
做数据仓库，绕不开三个词：
维度建模、范式建模、Data Vault。
很多人第一次接触，会把它们理解成三种“建表方式”。
事实表怎么建、维度表怎么拆、Hub和Satellite怎么设计……
但真正做到企业项目里会发现：
建模最重要的不是表长什么样，而是这套模型准备解决什么问题。
- 业务部门希望数据更容易分析；
- 数据团队希望业务关系表达准确；
- 集团型企业还希望上游系统不断变化以后，历史数据依然能够完整保留下来。
目标不同，模型自然不同。
如果最近正在系统梳理数仓建设，我整理了一套《数据仓库建设解决方案》，里面涉及数据同步、ETL、实时链路、数仓建设等内容。建模并不是孤立存在的，模型设计完以后，数据怎么从业务系统进入数仓、怎样完成加工和分层，同样决定了这套架构最后能不能真正跑起来。
下面就从真实的数据仓库建设过程，看看维度建模、范式建模和Data Vault到底分别解决什么问题。
一、维度建模：先想业务以后要怎么分析
假设老板问：
为什么华东区这个月利润下降了？
真正开始分析时，我们通常会先看几个结果：
销售额、销量、成本、利润、毛利率。
然后继续往下拆：
时间、地区、渠道、客户、产品、门店。
这实际上就是维度建模最核心的逻辑：
把“发生了什么”和“从什么角度观察”分开。
前者叫事实，后者叫维度。
一张销售事实表里，可能保存：
订单ID、客户ID、商品ID、日期ID、门店ID、销售数量、销售金额、成本、利润。
客户、商品、日期、区域、门店，则分别形成维度表。
最终形成经典的：
事实表 + 维度表。
如果所有维度直接围绕事实表展开，就是星型模型；
如果产品继续拆成品类、品牌，地区继续拆成省、市、区，则可能进一步形成雪花模型。
为什么经营分析普遍喜欢这种方式？
因为它天然按照“业务问题”组织数据。
业务人员不会问：
“订单表和客户表应该怎么Join？”
他们真正关心的是：
哪个产品增长最快？哪些客户利润最低？哪个区域库存周转变慢？
维度模型实际上提前把这些分析路径整理好了。
但真正落地时，最容易被低估的反而是建模之前的数据准备。
订单在ERP，客户在CRM，商品在电商系统，组织信息又在OA。即使事实表和维度表已经设计得很完整，只要客户编码对不上、字段类型不一致、订单状态定义不同，最终模型依然建不稳。
因此落表之前，通常还要先完成：
数据接入 → 字段统一 → 清洗 → 关联 → 转换。
数据库、接口、文件等不同来源可以先汇入 FineDataLink 5.0，再沿着数据开发任务继续完成字段映射、多表关联和规则加工。等到数据真正写入事实表和维度表时，每个字段从哪里来、中间经过什么处理，会比后期依赖大量临时SQL重新拼接更容易管理。
这也是维度建模经常被忽略的一点：
模型只是最后看到的结构，前面的数据准备决定了这个结构能不能长期使用。
不过，维度建模也有边界。
它很适合分析，却不一定适合作为企业最底层的数据模型。
因为当业务关系越来越复杂、源系统越来越多时，事实表和维度表本身也可能不断变化。
所以维度建模主要解决的是：
怎样把数据组织成业务更容易理解和分析的样子。
二、范式建模：先把业务关系表达准确
如果目标从经营分析变成企业级数据底座，问题就不一样了。
假设一个订单业务涉及：
客户、订单、订单明细、商品、供应商、合同、组织、地址。
如果为了查询方便，把所有信息全部塞进一张宽表，很快就会出现大量重复。
一个客户产生1000笔订单，客户名称、地址、联系方式就可能重复1000次。
更麻烦的是：
客户地址发生修改以后，究竟应该修改哪一条记录？
这就是范式建模希望解决的问题。
它的核心原则是：
把不同业务实体拆开，减少数据冗余，再通过关系把它们连接起来。
最常见的是第三范式，也就是3NF。
简单理解：
- 客户信息进入客户表；
- 订单进入订单表；
- 商品进入商品表；
- 订单与商品的对应关系进入订单明细。
每张表尽量只描述一个明确的业务实体。
这样做的好处是：
结构严谨、重复更少、业务关系更加清晰。
所以范式建模经常出现在企业数据仓库核心层、主数据以及复杂业务关系沉淀场景。
但问题也随之而来。
结构越规范，分析可能越复杂。
一张销售经营报表，可能需要同时关联：
订单表、订单明细表、客户表、产品表、产品分类表、组织表、区域表……
底层关系很清楚，上层分析却可能面对大量Join。
所以范式建模和维度建模从来不是“谁取代谁”。
更常见的思路反而是：
底层把关系理清，上层再按照分析需要重新组织。
这也是很多企业会出现：
规范数据层 + 主题分析层
这种组合的原因。
三、Data Vault：为不断变化的系统留出空间
前两种模型还有一个很现实的问题：
如果源系统一直变化怎么办？
大型企业的数据环境很少长期保持不动。
- 今年ERP升级；
- 明年并购一家公司，多了一套CRM；
- 后年客户编码规则调整；
- 再过一年，商品、供应商甚至组织结构又发生变化。
如果核心数仓模型与某套源系统绑定得太紧，上游结构一变，下面几十张表可能都要重新调整。
Data Vault就是为了降低这种耦合。
它主要由三类结构组成：
Hub、Link、Satellite。
可以简单理解为：
Hub：记录“是谁”
保存稳定的业务对象及业务主键。
例如：
客户、订单、商品、员工。
Link：记录“谁和谁发生关系”
例如：
客户—订单；
订单—商品；
商品—供应商。
Satellite：记录“它在某个时间是什么状态”
客户名称、等级、地址、状态发生变化以后，不直接覆盖旧值，而是继续保存新的版本。
所以Data Vault特别强调：
历史可追踪。
普通模型可能只回答：
“这个客户现在是什么等级？”
Data Vault还希望继续回答：
什么时候发生变化？之前是什么状态？这条信息来自哪套系统？
这也是它常见于多系统整合、集团型企业、审计要求高以及长期历史留存场景的原因。
但模型设计了历史，并不意味着历史一定真的能够留下来。
假设客户上午还是普通客户，下午升级VIP，晚上又被调整成重点客户。如果同步任务每天只覆盖一次，最后可能只留下晚上的状态，中间发生的变化已经消失。
因此，低频基础数据可以周期更新，高频变化的订单、库存、客户状态则需要持续捕获增删改。FineDataLink 5.0 提供的全量、增量以及实时同步能力，在这里对应的是不同的数据变化方式：变化慢的按周期进入，变化快的持续捕获，再把这些记录送进后面的Hub、Link和Satellite。
否则就会出现一个很尴尬的问题：
Data Vault结构上保存历史，数据链路却根本没有把历史送进来。
所以Data Vault真正难的，从来不只是多建几张表。
而是数据团队必须从关注：
“现在是什么？”
进一步转向：
“它是怎样一步一步变成现在这样的？”
当然，Data Vault也有明显代价：
表数量多、结构复杂、直接查询困难。
所以它通常不会直接面向最终业务分析。
上层依然会继续加工成维度模型、宽表或者指标数据集。
Data Vault追求的不是让今天查数最简单，而是：
几年以后业务系统发生巨大变化，核心数据层仍然能够继续扩展。
四、三种模型到底差在哪里？
把三种方法放在一起看，会清楚很多。
|
对比项 |
维度建模 |
范式建模 |
Data Vault |
|
核心目标 |
分析效率 |
业务关系严谨 |
历史与扩展性 |
|
典型结构 |
事实表+维度表 |
实体表+关系表 |
Hub+Link+Satellite |
|
查询难度 |
较低 |
较高 |
高 |
|
数据冗余 |
相对较高 |
较低 |
中等 |
|
历史追踪 |
需要额外设计 |
需要额外设计 |
强 |
|
应对源系统变化 |
一般 |
一般 |
较强 |
|
常见位置 |
数据集市、分析层 |
核心数据层 |
企业历史数据层 |
换一种更简单的理解：
- 维度建模关注：以后怎么查？
- 范式建模关注：业务对象之间是什么关系？
- Data Vault关注：这些关系和来源以后发生变化怎么办？
而真实项目里，数据也不会永远停留在某一种模型中。
底层可能按照范式或者Data Vault沉淀，到了销售主题，又需要把客户、订单、商品重新组织成事实表和维度表。
这里实际上发生了一次：
模型转换。
例如订单表、订单明细表、商品表，要重新加工成销售事实表；
散落在多个来源里的客户属性，也要整理成统一客户维度。
这一步如果只存在于架构图里，数仓依然跑不起来。多张表怎么关联、字段如何派生、哪些口径通过SQL计算、最终写到哪里，都需要转成真正的数据加工任务。
用 FineDataLink 5.0 把这些关联、转换、SQL处理和结果输出串起来之后，从核心模型到主题模型的加工过程就不再只是几根箭头，而是能够实际执行的数据链路。
所以数仓建模真正进入工程阶段以后，需要同时回答两个问题：
表应该怎么设计？
以及：
上一层的数据怎样稳定地变成下一层模型？
这两件事缺一不可。
五、企业到底应该怎么选？
真正成熟的数据仓库，很少从头到尾只使用一种建模方法。
更多时候是组合。
ODS：先尽量保留源系统数据
ERP是什么结构、CRM是什么结构，先把原始数据完整接进来。
这一层主要解决：
数据有没有进入平台。
核心数据层：统一业务关系
如果业务相对稳定，可以通过规范化方式整理客户、订单、商品等核心实体。
如果数据来源很多、变化频繁，又要求长期保留历史，可以进一步考虑Data Vault。
这一层解决的是：
企业数据到底是什么，彼此之间是什么关系。
主题数据层：转向业务分析
到了销售、财务、供应链、库存等主题，就可以重新构建事实表和维度表。
这一层开始回答：
业务以后准备怎么使用这些数据。
应用层：服务具体需求
继续加工：
宽表、指标表、标签表、算法特征、报表数据集。
数据到了这里，才真正直接面向应用。
所以很多企业常见的：
ODS → DWD → DWS → ADS
和维度建模、范式建模、Data Vault并不是一个概念。
分层解决“数据加工过程怎么组织”；
建模解决“某一层的数据关系怎么表达”。
但数仓真正运行半年、一年以后，还会出现第三个问题：
这些层之间还能不能看得懂。
一张订单源表增加字段，可能先影响ODS，继续影响DWD加工逻辑，再影响DWS主题表，最后甚至让ADS里的指标发生变化。
如果几十层加工全部散落在独立SQL、存储过程和临时脚本里，一旦数字异常，排查过程往往就是从最后一张表开始，一层一层人工往前翻。
因此数据从业务系统进入以后，经由 FineDataLink 5.0 完成同步、加工、转换再落入不同数仓层时，任务本身也在串联这些上下游关系。
到了模型调整或者指标异常时，排查的不再只是某张结果表，而是可以继续往前看数据经过了哪些处理、从哪张表流转而来。
这也是数据仓库从“第一版建设完成”进入长期运营以后，非常重要的一项能力。
因为真正困难的从来不是第一次把模型画出来。
而是半年、一年以后：
源系统变了、业务口径变了、模型也变了，这套数仓还能不能继续看懂、继续维护。
结语
最后，如果只记住一个判断逻辑，可以记住下面三句话。
业务更关心：
数据以后怎么分析？
重点理解维度建模。
数据团队更关心：
企业真实的业务关系是什么？
重点理解范式建模。
企业系统很多，而且还会持续变化：
历史怎么保留？新的数据源怎么继续接进来？
再考虑Data Vault。
真正成熟的数据仓库，也不是找一种“最先进”的建模方法套到底。
而是根据不同层次解决不同问题：
底层接住数据和变化，中间表达清楚业务关系，上层服务具体分析。
模型只是形式。
最终决定数仓质量的，是能不能把：
来源、关系、历史、加工和应用
真正串成一套长期可维护的数据体系。
浙公网安备 33010602011771号