数仓建模（维度建模）

本文主要介绍关于数据仓库,维度建模的知识点，对【数仓建模（维度建模）】和【数仓建模的方法及原则】有兴趣的朋友可以看下由【aijiudu】投稿的技术文章，希望该技术和经验能帮到你解决你所遇的数据仓库相关技术问题。

数仓建模的方法及原则

一、什么是建模？（为什么建模）

数仓建模的本质是通过模型完成对复杂业务的抽象，清晰准确完整的刻画业务场景，以便用户通过业务视角便捷的获取所需数据，完成对业务活动的度量。

从上面这句话，我们可以得出建模的四要素：一个过程(抽象)和三个目标(清晰、准确、完整)。

抽象：是指从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。通过抽象我们可以屏蔽繁琐的底层细节，聚焦业务本质，同时提升模型的稳定性，减少业务系统变更带来的冲击。

清晰：清晰是指模型信息必须是清楚、明了有条理的；通过抽象，我们可以将繁杂无章的数据进行归纳总结，以结构化的方式清晰的描述业务。

准确：准确是指模型表达的语义和用户理解的语义是一致的；通过理清业务关系，明确统一业务概念，就可以对业务活动进行准确的描述。

完整：完整是指业务信息必须是完整的，没有信息丢失的；信息丢失会造成业务描述的不完整，最终导致无法满足业务诉求。

二、模型的好处

质量:  通过数据集成和一致性建设，提升数据指标的一致性及及时性

效率：提升计算、存储、查询效率，提升用户体验

成本：减少不必要的数据冗余、提升模型复用度，降低存储、计算以及维护开发、降低成本        

扩展：屏蔽业务及上游系统的变更影响，能灵活快速兼容业务变更以及支撑新业务

三、建模的方法

范式建模(Normal Forms)：符合数据库规范化设计的数据模型，强调模型的规范性，减少数据冗余，增强一致性，目前有1NF~6NF，大部分场景要求达到3NF。

维度建模：从便于分析的角度，按照维度、事实的形式来构建数据模型，主要以星型模式来展现

DataVault建模：面向细节的、可追踪历史的、一组有连接关系的规范化的表的集合。它综合了三范式建模和星型模型的优点，由中心表、链接表、附属表三部分构成，其核心是中心表，用于存储业务主键，链接表用于存储业务关系，附属表用于存储业务描述。

Anchor建模：对DataVault模型做了进一步规范化处理，其核心思想是所有的扩展只是添加而不是修改，模型规范到6NF，基本变成K-V结构化模型。

Anchors： 类似于Data Vault的Hub，代表业务实体，且只有主键。

Attributes: 功能类似于DataVault的Satellite,但是它更加规范化，将其全部KV结构化，一个表只有一个Anchors的属性描述

四、维度建模 4.1 基本概念

数据域：从业务的角度，对数据进行总体的归类和划分，形成的有边界的数据范围。面向业务分析，将业务过程或者维度进行抽象的集合。

业务过程：业务操作活动或事件，如下单、支付、退款等。业务过程一般是一个不可拆分的事务行为事件。

维度：是观察事物的视角或角度，包含与业务过程度量事件有关的环境信息。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。有时候实体对象也可以是维度。

事实：即度量。基于某一个业务活动事件下的规格、指数及度量标准，一般是数值类型。指标一般具有明确的业务含义的名词，如支付金额，用户数等

维度使用主键标识，主键分两种：代理键和自然键

① 代理键：无业务意义，如自增ID

② 自然键：具有业务意义，如商品ID

有时不清楚一个数值是事实属性还是维度属性，区别事实属性还是维度属性的小技巧：

1.是多值并参与计算

2.一个常量，一个约束或行标识 往往维度属性

3.连续值很大可能是事实，低基数的是维度属性

4.2 为啥选择维度建模（优缺点） 4.2.1 优点

维度建模同时满足（1）以商业用户可理解的方式发布数据；（2）提供高效的查询性能，这两大需求。

1、便于理解

维度建模是将层次化的数据结构展开为单一层次，构建出来的数据库结构表更加符合人的直觉、易于被人所理解，从而有利于数据的推广使用。易于达成共识，方便查询，不必理解业务系统规范化复杂的3NF模型。

按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中，维度是描述事实的角度，如日期、地址、商品等，事实是要度量的指标，如配送员人数、完成单量等。

2、快速的响应业务

面向分析构建的，每次不需要编写冗长的SQL，查询大宽表，减少join，方便分析人员和业务人员（不太懂技术，不会写复杂SQL）使用，能快速的响应业务需求。

3、标准框架

数据仓库工具书，定义了业界广泛理解的概念。

新员工可以快速的掌握数仓的结构，不需要熟悉具体的业务系统数据。工程师和分析师对事实、维度、粒度这些概念都比较了解，可以促进协作。

4.2.2 缺点

1、数据预处理开销和数据冗余

由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。

2、一致性维度发生变化，每个主题表都要同步相关维度，对模型冲击比较大，相比范式建模扩展性不好。

3、如果只是依靠单纯的维度建模， 不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

在建设数据仓库的过程中，明细层和集市层分别采用不同的建模方法，比如：

明细层采用传统的三范式关系模型：将业务过程描述清楚，将源数据（即业务系统）中隐含的、有歧义的概念进行清晰化。此层灵活地表达业务过程，要保证数据一致性、唯一性、正确性，以尽量少的代价与源数据保持数据同步。（面向技术人员）

集市层采用维度模型。集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合，该层次的数据模型会开放给业务人员使用，进行数据挖掘及业务分析。（面向不懂技术的业务人员，需要简单易理解）

4.3 维度建模-星型模型

星型模型VS雪花模型，根据事实表和维度表之间的关系，我们将常见的模型分为星型模型和雪花模型。星型模型更适用于做指标分析，而雪花模型更适用于做维度分析。

星型模型

雪花模型

概念

当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。

当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在办进行数据统计或分析的时候，需要和其他的表进行关联

图

查询速度

快

有数据的冗余，很多的统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。

慢

在分析数据的时候，需要join的表⽐较多所以其性能并不⼀定⽐星型模型⾼。

冗余度

高

星型架构是⼀种⾮正规化的结构，多维数据集的每⼀个维度都直接与事实表相连接，不存在渐变维度，所以数据有⼀点的冗余。如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余

低

它对星型模型的维表进⼀步层次化，原有的各维表可能被扩展为⼩的事实表，形成⼀些局部的 "层次 " 表，去重冗余。如将地域维表分解为国家，省份，城市等维表。

可读性

容易

差

表数量

少

多

4.4 维度建模-维度 4.4.1 维度之缓慢变化维

什么是缓慢变化维：随着业务的发展，维度表中的属性会随着业务的发展而变化，但变化的频率一般比较慢，故称为缓慢变化维。

处理缓慢变化维的方法

 

 4.4.2 维度层次

同一类属性存在多对一的关系，具有上卷的形式，可以设计为层次维度

1）固定深度的层次

层次已固定的维度属性，例如右侧的日期维度，日、月，季度，年。处理方案：采用列打平的方式来设计
2）可变深度的层次

层次不固定的维度属性，

例如物流业务线的组织架构，不仅层次不一致，而且会在某一个层次中间和末尾增加一层。

处理方案：

 1.采用类似固定深度层次的方案，提前预留足够的列打平设计。

 2.采用递归父子关系方式，同时保存每个叶子节点到各个层次的关系和深度值。

4.4.3 维度之常见应用

1、角色扮演维

同一个物理维度在不同的场景中，代表不同的业务含义，通常会被事实表多次引用，技术上通过创建视图来引用。

设计案例：日期维度可以作为下单日期，可以作为支付日期，物流站点维度可以作为快递员的组织归属站点，也可以作为快递员绑点站点。

2、杂项维度

1）业务系统的一些非关键的标识维度，不适合单独常见维度，可以合并到统杂项维度

2）利用杂项维度，减少维度模型的结构变更

设计案例：配送员汇总事实表，设置了杂项维度，合并【是否过风控】+【是否自然日】+【是否高峰期】等维度组成合并成一个维度，避免了维度模型的调整

3、退化维度

业务系统的标识符，没有维度表与它连接，所以叫退化维度

4、其它维度

微型维度、多值维度、步骤维度

4.5 维度建模-事实

事实就是一种度量

4.5.1 事实的分类

 可加型事实：   可以按维度进行聚合，例如金额、件数

 半可加型事实：仅在特定的维度下有含义，例如账户余额

 不可加型事实：不具备可加性，例如比率值

4.5.2 事实表的分类

事务事实表、周期事实表、累计快照事实

1、事务事实：记录的事务操作过程的事实，最原子的数据，粒度通常是每个事务记录一条记录，只有当天数据才会进入当天的事实表中，相当于每个分区里面都是每天的数据。

id

name

regist_time

dt

100356

张XX

2021-10-01 08:02:10

20211001

200389

李xxx

2021-10-02 11:09:20

20211002

2、周期事实表

具有规律性的、可预见的时间间隔来记录事实，用来观察在间隔周期内的度量，时间间隔如每天、每月、每年等，粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。

id

order_cnt

user_cnt

dt

130000356

32

28

20211001

224000389

12

12

20211001

3、累积快照事实表

适合流水线过程中的已明确关键里程信息或已建立好的可预测的工作流，不存储发生的每一个事务信息，累积事实表源于事务，提供了关键过程时间的连续场景描述，代表的是完全覆盖一个事件或产品的生命周期时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

例如订单累计快照事实表会有下单日期、付款日期，发货日期，收货日期等时间点。

order_id

poi_id

user_id

push_time

grap_time

arrived_time

status

dt

16589600009723

300876

100356

2021-10-01 11:02:10

2021-10-01 08:02:10

9999-01-01 01:00:00

30

20211001

16200000003455

300087

200389

2021-10-01 09:10:33

2021-10-01 09:12:33

2021-10-01 10:02:09

50

20211001

事实表的比对

事务事实表

周期快照事实表

累积快照事实表

时间特点

离散事务时间点

固定的时间间隔

时间跨度不确定

粒度

每行代表一个事务度量事件

每行代表一个周期内的实体状态

每行代表一个实体的生命周期

日期维度

事务事件

适用场景

针对业务过程的事务分析

针对实体的状态分析

针对实体的生命周期分析

更新策略

不更新

周期结束时定期更新

业务过程更新时同步更新

设计的注意事项

粒度：每行中的数据是一个特定级别的细节数据

存储：应该尽量将来源于 同一个业务过程的底层度量结果存储于一个维度模型中。

4.6 维度建模-建模步骤

业务建模=>逻辑建模=>物理建模。

4.6.1 业务建模（Conceptual Data Model）

梳理业务流程、业务概念统一、收集业务指标。

梳理业务流程，输入：（1）阅读BRD/MRD/PRD、技术方案、ER模型文档深入了解业务背景知识、各个系统的数据存储关系。（2）对相关业务人员进行调研，了解业务操作和日常工作，收集业务对数据的诉求，收集存量的报表。输出：（1）业务流程图；（2）业务知识文档；（3）特殊业务场景和坑点；（4）业务指标定义。

业务建模-划分主题

为什么划分主题？（1）明确主题边界，确认主题建设范围，分而治之，达成共识。例如：物流主题负责物流承运相关流程的核心数据，派单相关的划分到调度。（2）便于用户从较高层次理解使用数仓，提升检索数据效率。例如：数据地图提供按主题引导。（3）数据仓库管理的基础。例如：主题分工各负其责、业务过程归属，指标体系归类，元数据管理。

主题：指面向业务分析的场景下，将业务数据或分析视角数据进行重新抽象组织的集合，是从较高层次对企业业务进行划分的方式和组织。

常见分类如下：

业务主题：交易，履约、运力  (在B3层划分)

分析主题:   运力体验、盈亏分析，活动效果分析 (在B1层划分)

如何划分主题？

（1）按主业务流程进行划分

例如：提供物流履约服务就是主业务流程，根据业务上下游相关性，提供物流履约服务可以进一步拆解为销售、定价、交易、调度、履约、结算、售后(体验)等不同业务领域，可以对相应的业务领域构建对应的主题。

 此类主题的特点是有多个参与主体参与；例如：履约主题需要由商家、配送员、用户等共同参与。

（2）对支撑业务流程按参与主体划分

例如：对于物流来说，参与主体有商家、配送员、用户等；可以对参与主体分别构建主题，用于存放与参与主体相关的支撑性业务流程。

例如：对人员招募、人员注册、人员入职、人员在职、人员离职等业务过程构建人员运营主题。

（3）按分析的视角划分

结合业务分析的场景进行抽象的主题，例如：人员体验、盈亏分析，人员留存，可以对这些分析主题进行专题的建设。

4.6.2 逻辑建模（Logical Data Model）

梳理总线矩阵、划分业务过程、确定粒度/维度/事实/维度表/事实表设计。

1、构建总线矩阵

一致性维度：在数据仓库体系内部统一的维度关键字、一致的列名称、属性定义和属性值

一致性事实：在数据仓库体系内部每个度量统一的统计口径，对应唯一的业务概念术语

业务流程是由各个具体的事务流程组成，而事务是由各个业务系统支撑的业务过程来组成的，

可以转换成总线矩阵上的行、列最终形成维度模型

 行：代表公司组织的一个业务过程

列：业务过程的维度

2、维度表设计

确定维度、填充维度属性、审查相关属性。

是否应该分层，是否可以拆分或整合。

3、事实表设计

1）选择业务过程，在主题域内根据情况会抽象新增/合并业务过程。

2）确定事实表，根据需求设计合适的事实表类型，事务事实表、周期快照事实表、累积快照事实表。

3）确定粒度，对于事务表，尽量保持最明细的粒度。

4）确定事实表的维度，尽可能包含业务过程下所有维度；考虑是否退化维度；识别剩余的维度或维度属性是否必须； 避免出现蜈蚣表；

5）确定指标，统一同一类指标的单位。尽可能包含业务过程下所有原子指标，只选择和业务过程相关的原子指标，统一同类指标的单位。

4.6.3 物理建模（Physical Data Model）

定义物理模型、存储方式。

确定表名称/表文件格式/字段名称/字段类型及存储路径等

确定分区方式，一级分区/双分区/多级分区，分区字段的选择(时间年月日、业务字段)

确定数据初始范围

4.7 数仓整体分层 4.7.1 分层规范

层次

定义

对各层含义的具体理解

引擎

ODS

ods接入层,主要负责各种数据源的接入

接入层由工具完成，当前主要有mysql 和流量日志数据源。该层不对外开放

hive

ods准备区，主要完成进入dwd数据的准备工作，完成和接入层的解耦合。

由于接入层由工具完成，不受我们控制。我们需要在此基础上做一些解耦操作(生成快照表)，同时完成进入dwd的准备工作，例如过滤压测数据、脱敏操作等。

在建模方式上基本和源系统结构保持一致。对于部分临时性探索分析，不一定会构建dwd，可以考虑对外开放这部分数据权限；其它场景均应该访问dwd处理过后的数据

hive

DIM

一致性维度层，对业务过程中的维度进行统一定义，消除不一致性，是实现总线架构基础。维度分为普通维度和衍生维度，区别在于衍生维度需要通过复杂计算(跨事实表、跨时间周期汇总）等才能产生

基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应

hive

DWD

Data Warehouse Detail 明细数据层，作为数据仓库最核心的区域，主要作用是通过数据加工与整合，完成对业务的抽象，对外提供简单、准确、详尽、一致的数据模型。

这部分主要完成以下工作：
1) 按业务主题域，采用维度建模面向业务过程构建明细事实表，完成对业务的抽象，及逻辑的封装，屏蔽数据源变化

2）完成统一指标的定义，指标定义规范

注：DWD层的原子指标、衍生指标均不跨业务主题

3）数据质量保证

hive

DWS

Data Warehouse Summary汇总数据层，完成明细数据的汇总

主要对DWD层按照常用维度组合进行预聚合，不做任何逻辑封装，提升查询性能。

时间类的衍生指标也存于该层，例如最近30天接单量。

对于不可加指标(例如count distinct)，有三种实现方案，基于doris的ROLAP，基于kylin的MOLAP和基于hive的cube表，具体可以根据实际场景选择

通常会有三类汇总表，分别是最近1天、最近N天、历史截止当天

注：为了保证低耦合，高内聚，DWS层的聚合不跨业务主题

hive、kylin、doris

DM

为满足具体分析场景的数据特点和易用性，而构建的面向不同垂直领域的数据集市层，例如盈亏集市、AB集市、运力集市、商集市等；

基于DWD、DWS层和DIM的数据构建，内部数据可跨B3层主题域整合，或基于商业模型进行场景化的数据加工，满足业务、商分和产研的具体分析诉求，达成低成本、易使用的获取和分析数据的诉求；

hive、kylin、doris

APP

Application数据应用层，面向具体应用(报表、数据服务)构建，用于满足不同应用的个性化需求（例如行列转换，特殊排序要求)

 面向具体应用构建，满足性能和客户化展示需求

kylin、doris、mysql、es

4.7.2 为什么分层（分层好处）

分层能使结构更加清晰：每一层都有它的作用和职责，我们在使用表的时候能更快速地定位和理解。

分层能使血缘关系更加清晰：高层依赖低层，不允许跨层依赖（例如：不允许明细层表依赖应用层的表）这样我们的血缘关系会更加清晰，使用也比较方便。

方便维护数据的准确性：如果有一张表出了问题，我们能够根据层级快速定位影响，通过字段血缘，快速识别影响范围。当数据出现问题之后，可以不用修复所有的数据，只需要修复问题表回刷下游影响表即可。

减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少一些重复计算，可以节省计算资源。

把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层有不同定位，比较简单和容易理解。

屏蔽业务变动影响，屏蔽原始数据的异常。即使原始数据变动，在明细层兼容处理，不会影响模型和下游业务。

权限控制：对不同人员，选择性开放对应的层，可以粗粒度的管理权限。

本文《数仓建模（维度建模）》版权归aijiudu所有，引用数仓建模（维度建模）需遵循CC 4.0 BY-SA版权协议。