数据仓库 |1.3 数仓分层| 建模

1、数仓分层

分层

提高复用性、减少重复开发

数据集市与数据仓库的区别

数据集市：狭义ADS层；广义上指DWD DWS ADS 从hadoop同步到RDS的数据

数仓命名规范

表命名

ODS层命名为ods_表名
DWD层命名为dwd_dim/fact_表名
DWS层命名为dws_表名
DWT层命名为dwt_表名
ADS层命名为ads_表名
临时表命名为xxx_tmp
用户行为表，以log为后缀。
数据源_to_目标_db/log.sh
用户行为脚本以log为后缀；业务数据脚本以db为后缀。
数量类型为bigint
金额类型为decimal(16, 2)，表示：16位有效数字，其中小数部分2位
字符串(名字，描述信息等)类型为string
主键外键类型为string
时间戳类型为bigint

脚本命名

数据源_to_目标_db/log.sh
用户行为脚本以log为后缀；业务数据脚本以db为后缀。

表字段类型

数量类型为bigint
金额类型为decimal(16, 2)，表示：16位有效数字，其中小数部分2位
字符串(名字，描述信息等)类型为string
主键外键类型为string
时间戳类型为bigint

2、数仓理论

1.范式理论

范式的定义：符合某一种级别的关系模式集合，表示一个关系内部各属性之间的联系的合理化程度。通俗地讲，范式可以理解为一张数据表的表结构，符合的标准级别、规范和要求。

1）优点

采用范式，可以降低数据的冗余性。

为什么要降低数据冗余性？
十几年前，磁盘很贵，为了减少磁盘存储。
以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
一次修改，需要修改多个表，很难保证数据一致性

3）缺点

范式的缺点是获取数据时，需要通过Join拼接出最后的数据。

4）分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

函数依赖

完全函数依赖： 共同决定，任何单独一个推测不出来。

部分函数依赖：只依赖于其中一个，一半

传递函数依赖： a->b->c(c不能得到a)

三范式区别

第一范式：（保证数据的可用性）

1NF核心原则：属性不可切割； 商品| 数量可切割

第二范式：（减少数据冗余）

2NF核心原则：不能存在部分函数依赖（ (a,b) => c， a => c，部分函数依赖，拆分 a,b 和 a,c两个表）
　　联合主键(学号, 课名)，但姓名并不完全依赖于（学号，课名）；
　　　　变成完全函数依赖即可

第三范式：（减少了数据冗余 & 保证数据一致性）

3NF不能存在传递函数依赖

学号->系名->系主任，但系主任不能推出学号；（a -> b -> c， c不能推出a ；拆分为a,b 和b,c两个表）

　　把它拆开两张表

2. 关系建模与维度建模

数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示。

对比属性	OLTP	OLAP
读特性	每次查询只返回少量记录	对大量记录进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，Java EE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

关系建模

关系模型严格遵循第三范式（3NF），较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主

要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

维度模型主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。

通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。

维度建模

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

星型模型：(快)
　　事实表只有一级维度，数据表中只有1个维度表； 星型模式的核心是一个大的中心表（事实表），一组小的附属表（维表）。

雪花模型：(灵活)
　　事实表存在多级多个维度，比较靠近3NF； 雪花模式是星型模式的扩展，其中某些维表被规范化，进一步分解到附加表（维表）中。

星座模型：（可能是雪花也可能是星型）

　　多张事实表存在相同的维度表； 数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。
　　多个事实表(一个项目中大概5-6个)
　　事实表-维度(共享)-事实表

3.事实表和维度表

事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等），用户行为产生的业务过程。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等）。

维度表：时间、用户、商品、商家。事实表：250块钱、一瓶

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

事实表的特征：

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

实体表：用户表、商品表--->全量；一个个实实在在的个体；

　　一般是指一个现实存在的业务对象，比如用户，商品，商家，销售员等等。

　（同步策略）实体表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。

1）事务型事实表

构建流程： 选择业务过程 -> 声明粒度 -> 确定维度 -> 确定事实

以每个事务或事件为单位，一般指随着业务发生不断产生的数据。特点是一旦发生不会再变化；比如，交易流水，操作日志，出库入库记录等。例如一个销售订单记录，一笔支付记录等，作为事实表里

的一行数据。一旦事务被提交，事实表数据被插入，数据就不再更改，其更新方式为增量更新。

　　每日新增 订单详情表（用户和商品信息）、支付流水表(增量)

同步策略（因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，所以可以做成每日增量表，即每日创建一个分区存储。）

2）周期型快照事实表（存量型指标加购）

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

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

随着业务的发生（时间）而变化

　　订单表（订单状态）--> 新增和变化

这类表从数据量的角度，存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。

每日新增及变化量可以用，包括了当日的新增和修改。一般来说这个表，足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。所以要用利用每日新

增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。

3）累积型快照事实表（多事实关联订单）

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

况。当这个业务过程进行时，事实表的记录也要不断更新。

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

维度表

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

维表的特征：

维表的范围很宽（具有多个属性、列比较多）
跟事实表相比，行数相对较小：通常< 10万条
内容相对固定：编码表

维度整合

商品信息表： SKU、 SPU、 TM、 Category321
省份信息表：大区表、省份表
活动信息表：活动信息表、活动规则表

拉链表（方便获取历史切片数据）

用户表：数据量大的缓慢变化维度

时间维度表：

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

维度表(码表--编号的解释表)：对应的业务状态；商品一级分类表、商品二级分类表、商品三级分类表等都是；全量表

　　比如地区表，订单状态，支付方式，审批状态，商品分类等等

同步策略（维度表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。

说明：1）针对可能会有变化的状态数据可以存储每日全量。2）没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以就存一份固定值。)

4.数据仓库建模

数仓建模

1 业务调研

1) 所有的业务数据(最好有建表语句)
2) 与Java部门沟通
3) 与(项目经理)沟通
- 原子指标: 业务过程 + 聚合逻辑 + 度量（比如GMV，订单+sum+金额）
- 派生指标: 原子指标 + 统计周期 + 统计粒度 + 业务限定（各个城市的GMV、各个品类的GMV等等）
- 衍生指标: 由派生指标再加工 XX率

2 明确数据域(找事实表业务过程)

用户域:注册、登录
流量域:启动、页面、曝光、动作、错误
交易域:加购、下单、退单、支付、退款...
工具域:领券、用券
互动域:点赞、评价、收藏

3 构建业务矩阵

用户域:地区商品 ... 注册、登录
流量域:启动、页面、曝光、动作、错误
交易域:加购、下单、退单、支付、退款...
工具域:领券、用券
互动域:点赞、评价、收藏

4 维度建模(ODS -> DWD/DIM)
DWD:

事务型事实表：选择业务过程 -> 声明粒度 -> 确定维度 -> 确定事实
- 缺点:存量型指标、多事实关联
周期型快照事实表：存量型指标加购
累积型快照事实表：多事实关联订单

DIM:

维度整合
- 商品信息表:SKU SPU TM Category321
- 省份信息表:大区表省份表
- 活动信息表:活动信息表活动规则表
拉链表: 方便获取历史切片数据
- 用户: 数据量大的缓慢变化维数据

5 指标体系建设(ADS -> DWS)

原子指标: 业务过程 + 聚合逻辑 + 度量
派生指标: 原子指标 + 统计周期 + 统计粒度(维度组合) + 业务限定
衍生指标: 由派生指标再加工 XX率
业务过程相同, 这一类指标(一张DWS表)

数仓建模经典书籍：

《数据仓库工具箱--第3版》

　　　　　　---维度建模权威指南

1.选择业务过程
　　星型模型(一层维度表围绕事实)
　　左事实表 + 维度表 
2.声明粒度


　　dwd层确定维度和事实 
3.确定维度
4.确定事实


dws层维度退化


dwt主题层
ads指标结果层

ODS层

1）HDFS用户行为数据

2）HDFS业务数据

3）针对HDFS上的用户行为数据和业务数据，我们如何规划处理？

（1）保持数据原貌不做任何修改，起到备份数据的作用。

（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）

（3）创建分区表，防止后续的全表扫描

DWD层

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

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

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

（1）选择业务过程

在业务系统中，挑选感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

如果是中小公司，尽量把所有业务过程都选择。

如果是大公司（1000多张表），选择和需求相关的业务线。

（2）声明粒度

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

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

典型的粒度声明如下：

订单当中的每个商品项作为下单事实表中的一行，粒度为每次。

每周的订单次数作为一行，粒度为每周。

每月的订单次数作为一行，粒度为每月。

如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。

（3）确定维度

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

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

维度表：需要根据维度建模中的星型模型原则进行维度退化。

（4）确定事实

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

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

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

在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。

	时间	用户	地区	商品	优惠券	活动	编码	度量值
订单	√	√	√			√		件数/金额
订单详情	√	√	√	√				件数/金额
支付	√	√	√					金额
加购	√	√		√				件数/金额
收藏	√	√		√				个数
评价	√	√		√				个数
退款	√	√		√				件数/金额
优惠券领用	√	√			√			个数

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

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

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

DWS层

DWS层统计各个主题对象的当天行为，服务于DWT层的主题宽表。

（1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额

（2）处理办法：都是将省份表和订单表进行join，group by省份，然后计算。相当于类似的需求重复计算了两次。

那怎么设计能避免重复计算呢？

地区宽表的字段设计为：下单次数、下单金额、支付次数、支付金额等。只需要和每个事实表一次join。

（3）总结：

需要建哪些表：以维度为基准，去关联对应多个事实表

宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。

（4）DWS层宽表包括：每日设备行为、每日会员行为、每日商品行为、每日活动统计、每日地区统计。

DWT层

DWT层统计各个主题对象的累积行为。

（1）需要建哪些表：和DWS层一样。以维度为基准，去关联对应多个事实表

（2）宽表里面的字段：我们站在维度表的角度去看事实表，重点关注事实表度量值的累积值、事实表行为的首次和末次时间。

例如，订单事实表的度量值是下单次数、下单金额。订单事实表的行为是下单。我们站在用户维度表的角度去看订单事实表，重点关注订单事实表至今的累积下单次数、累积下单金额和某时间段内的累积次数、累积金额，以及关注下单行为的首次时间和末次时间。