【电商数仓】关系建模与维度建模、维度表和事实表、几种维度模型、数仓建模原则

文章目录

1 关系建模与维度建模
- （1）关系建模
- （2）维度建模
2 维度表和事实表
- （1）维度表
- （2）事实表
- - 事务型事实表
  - 周期型快照事实表
  - 累积型快照事实表
3 维度模型分类
- （1）星型模型
- （2）雪花模型
- （3）星座模型
- （4）模型的选择
4 数据仓库建模
- （1）ODS层
- （2）DIM层和DWD层
- - 选择业务过程
  - 声明粒度
  - 确定维度
  - 确认事实
- （3）DWS层与DWT层
- （4）ADS层

1 关系建模与维度建模

如何规范数仓的表格，想要构建数仓，需要将数仓分层。某一层中存放哪些表，表里有哪里字段，这些事情就是通过建模来确定的。

关系建模和维度建模是两种数据仓库的建模技术。关系建模由Bill Inmon所倡导，维度建模由Ralph Kimball所倡导。

（1）关系建模

从MySQL中导出来的表格称为业务数据，都是满足三范式要求的，对这些表的规划、建模称为关系建模。

关系建模将复杂的数据抽象为两个概念——实体和关系，并使用规范化的方式表示出来。关系模型如图所示，从图中可以看出，较为松散、零碎，物理表数量多，但是冗余度很低，这就是关系型数据库的建模方式。

关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。

（2）维度建模

维度模型如图所示，从图中可以看出，模型相对清晰、简洁。

维度模型以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。表结构简单，故查询简单，查询效率较高。

维度建模一定要选定一个中心，这个中心就是需要做的业务，如电商的核心业务就是订单，那么在对电商业务进行维度建模的时候，就可以将订单放到中心的位置。描述订单的方式一般为：和人，何时，何地，下的什么订单，一个用户，一个维度；一个时间，一个维度等等，做的事情称为“下单”。

维度建模其实是通过另外一种方式来描述业务，这时每一个维度都可以被列成一个表格。中心的表格称为事实表，周围的表都是用来描述事实表的一些信息，称为维度表。数仓就采用这种建模方式，主要是为了减少join操作，增加检索效率。

数仓的第一步就是将原来的业务数据重新进行一次维度建模，将数据重新规划，目的就是为了减少查询的时间。维度建模发生在DWD（明细数据层）和DIM（维度层）。

2 维度表和事实表

（1）维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。

维度表的特征：

维表的范围很宽（具有多个属性、列比较多）
跟事实表相比，行数相对较小：通常 < 10万条，用数学语言描述就是 f(a,b,c,d) = e, 其中abcd为4个维度，e为事实
内容相对固定：编码表

时间维度表：

日期ID	day of week	day of year	季度	节假日
01-01	2	1	1	元旦
01-02	3	2	1	无
01-03	4	3	1	无
01-04	5	4	1	无
01-05	6	5	1	无

（2）事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），把维度去掉，剩下的就是度量值。

例如，2020年5月21日，小明在京东花了250块钱买了一瓶海狗人参丸。维度表：时间、用户、商品、商家。事实表：250块钱、一瓶。

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。

事实表的特征：

非常的大
内容相对的窄：列数相对较少（主要是外键id和度量值）
经常发生变化，每天会新增加很多

事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等，只关注每个时间点的数据。

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便后期统计分析。

累积型快照事实表

**累计快照事实表用于跟踪业务事实的变化。**例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新

订单id	用户id	下单时间	打包时间	发货时间	签收时间	订单金额
		3-8	3-8	3-9	3-10

3 维度模型分类

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

（1）星型模型

一个中心表，外加几个维度，标准的维度表，维度只有一层，事实表只要向外扩展一步，就可以查找所有信息。

（2）雪花模型

雪花模型会将一些维度信息进行拆分，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高。

雪花模型与星型模型的区别主要在于维度的层级，标准的星型模型维度只有一层，而雪花模型可能会涉及多级。

一般选择星型模型，因为数仓数据量大，要减少join操作，查询速度永远是数仓的第一需求。

（3）星座模型

星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表。

基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座只反映是否有多个事实表，他们之间是否共享一些维度表。

所以星座模型并不和前两个模型冲突。

（4）模型的选择

首先是星座，这个只跟数据和需求有关系，跟设计没关系，不用选择。

星型还是雪花，取决于性能优先，还是灵活更优先。

目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存，即一层维度和多层维度都保存。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。关系型数据可以依靠强大的主键索引，一般采用星座 + 雪花。

4 数据仓库建模

（1）ODS层

用户行为数据和业务数据都存储到HDFS上

针对HDFS上的用户行为数据和业务数据，做如下处理

针对HDFS上的用户行为数据和业务数据
访问频率十分低，所以数据可以采用压缩，解压缩非常慢也可以，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右，一般采用gzip压缩）
创建分区表，防止后续的全表扫描

（2）DIM层和DWD层

在这两层需要规划自己需要哪些表格，哪些表格有哪些列，那么就需要进行建模

DIM层DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：

选择业务过程→声明粒度→确认维度→确认事实

选择业务过程

在业务系统中，挑选感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。在这个阶段，要确定事实表要追踪的是什么事情。

声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

粒度粗，数据量小，便于统计，代价是统计的信息没有那么细，维度信息更小。

典型的粒度声明如下：

订单事实表中一行数据表示的是一个订单中的一个商品项。

支付事实表中一行数据表示的是一个支付记录。

确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

确认事实

此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

说明：长方形为事实表，其中订单表相关是做重要的事实表，圆圈代表维度表。

电商数仓中的维度与事实表最终设计成如下表，其中维度为行，事实表为列。

维度/事实	时间	用户	地区	商品	优惠券	活动	度量值
订单	√	√	√				运费/优惠金额/原始金额/最终金额
订单详情	√	√	√	√	√	√	件数/优惠金额/原始金额/最终金额
支付	√	√	√				支付金额
加购	√	√		√			件数/金额
收藏	√	√		√			次数
评价	√	√		√			次数
退单	√	√	√	√			件数/金额
退款	√	√	√	√			件数/金额
优惠券领用	√	√			√		次数

至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。

DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。

DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

（3）DWS层与DWT层

有了明细以后，下一步准备站在各个维度，统计关心的指标，如问题引出中的两个需求。

DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。

问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额
处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。

那怎么设计才能避免重复计算。

针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。

总结：
- 需要建哪些宽表：以维度为基准。
- 宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
- DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

（4）ADS层

对电商系统各大主题指标分别进行分析。