目录
- 数据仓库分层
- 数据仓库为什么要分层
- 数据集市与数据仓库概念
- 数仓理论
- 维度建模
- 维度表
- 事实表
- 事实表的细分
- 维度模型分类
- 数仓实操
- ODS
- DIM和DWD
数据仓库分层
1. ODS层:
存放原始数据,保持原貌不做处理
2. DWD层:
对数据进行清洗(例如去除空置、脏数据,数据脱敏等)。保存业务事实明细,表中一行信息代表一次业务行为,例如一次下单
3. DWS层:
对业务事实按天进行轻度汇总。例如统计某个用户在一天的下单次数是多少,支付次数是多少,所以表中一行信息代表一个主题对象一天的汇总行为
4. DWT层:
对业务事实进行累计汇总。例如统计某个用户在最近一月,一年,或n天的下单次数是多少,支付次数是多少。所以表中一行信息代表一个主题对象的累积行为
5. DIM维度层:
保持维度数据,主要是对业务事实的描述信息,例如何人,何时,何地等
6. ADS层:
为各种统计报表提供数据。即根据现实需求,统计相应指标,例如统计用户的日活,月活,留存率等
数据仓库为什么要分层
- 把复杂问题简单化
- 减少重复开发
- 隔离原始数据
数据集市与数据仓库概念
数据集市
是一种部门级别的数据仓库,一般只能为某个局部范围的管理人员服务
数据仓库
是企业级别的,能为企业的各个部门提供服务
数仓理论
维度建模
(1)维度模型以数据分析作为出发点
,不遵循三范式,故数据存在一定的冗余
(2)维度模型面向业务
,将业务用事实表和维度表呈现出来
为什么说维度模型面向业务?
举例说明:
例如2020年11月11号,张三在某购物平台购买了3件商品,花了3000元。这就是一个典型的下单业务事件
这个下单的业务事件可通过以下维度模型进行表示。
我们只需要用到一个订单事实表,该订单事实表中需要存储user_id
,用user_id去关联用户维度表,那么我们就知道是谁下了单;需要存储time_id
,用time_id去关联时间维度表,那么我们就知道是谁在什么时间下了单;需要存储product_id
,用product_id去关联商品维度表,那么我们就知道是谁在什么时间买了什么商品;除此之位,还需要存储下单时购买的商品数量(度量值)
,那么我们就知道该用户购买了几件商品;还需要存储下单时购买的商品花费的总金额(度量值)
,那么我们就知道该用户下单花费了多少钱了。到此我们就可以用这个维度模型将这个下单业务事件清晰的表述出来了
(3)维度模型
的表分为2类,事实表和维度表,图中中间的为事实表,四周的为维度表
(4)事实表存储的是业务事件
(例如下单、支付、退款、评价等)
(5)维度表中存储的是对业务事件的描述信息
,也就是说何人何时何地等
(6)事实表中的字段大致有2类
,一类是各种维度表的外键,另一类是度量值
维度表
- 维度表中存储的是
对业务事件的描述信息
- 每一张维表对应现实世界中的一个对象或者概念。例如:用户、商品、日期、地区等
- 维表的特征
(1)维表的范围很宽,即具有多个属性、列比较多
(2)跟事实表相比,行数相对较小:通常< 10万条
(3)内容相对固定:编码表
事实表
- 事实表存储的是
业务事件
(例如下单、支付、退款、评价等)。具体来说,表中的每一行数据代表一个业务事件(例如一次下单、一次支付、一次退款、一次评价等) - 而事实表中“事实” 这2个字表示的是业务事件中可统计的度量值(例如次数、个数、金额等)
- 事实表的特征:
(1)内容相对的窄,即列数较少(主要是外键id和度量值)
(2)非常的大
(3)经常发生变化,每天会新增加很多
事实表的细分
- 事务型事实表
以每个事件为单位。例如一个销售订单记录,一笔支付记录等,作为事实表里的一行数据。特点为
一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新
- 周期型快照事实表
周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据。例如购物车,有加减商品,随时都有可能变化,但是我们更关心每天结束时这里面有多少商品
- 累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。例如,数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时,事实表的记录也要不断更新
维度模型分类
- 星型模型
- 雪花模型
(1)雪花模型与星型模型的区别主要在于维度的层级,标准的星型模型维度只有一层,而雪花模型可能会涉及多级
(2)雪花模型,比较靠近3NF,但是无法完全遵守,因为遵循3NF的性能成本太高
- 星座模型
(1)星座模型与前两种情况的区别是事实表的数量,
星座模型是基于多个事实表
(2)基本上是很多数据仓库的常态,因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表,他们之间是否共享一些维度表,所以星座模型并不和前两个模型冲突
总结:
模型的选择
(1)首先就是星座不星座这个只跟数据和需求有关系,跟设计没关系,不用选择
(2)星型还是雪花,取决于性能优先,还是灵活更优先。目前实际企业开发中,不会绝对选择一种,根据情况灵活组合,甚至并存(一层维度和多层维度都保存),但是整体来看,更倾向于维度更少的星型模型。尤其是Hadoop体系,减少Join就是减少Shuffle,性能差距很大
数仓实操
ODS
DIM和DWD
- 选择业务过程
即选择什么样的业务过程,就确定什么样的事实表。例如选择订单业务,那么就确定订单事实表
我们借助表格进行实操,这个表格已称之为业务总线矩阵
这里假设选择2个业务过程,订单和评价
- 声明粒度
(1)即确定事实表中每行数据是什么,确实时尽可能去选择最小粒度。例如和订单相关的表一般会有2张,其中一张呢,就是订单表,表中的每行数据就代表一个订单;另一张表是订单详情表,表中的每行数据就代表一个商品项,那根据最小粒度原则,那么就确定该订单事实表的每行数据就代表一个商品项,调整订单事实表,为订单明细事实表
(2)数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别
- 确定维度
(1)确定每张表中的维度外键
(2)如果要确定维度外键,那么首先要选取维度,那么维度是怎么选择的呢?
维度的选择是根据后续需求中是否要分析相关维度的指标。例如,后续需要统计什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多,那么需要确定的维度就包括:时间维度、地区维度、用户维度、商品维度
(3)根据业务表关系图,查看和该订单明细表直接或者间接关联维度具体有哪些,有关联的话,在业务总线矩阵上进行关联
业务表关系图
(1)数仓中,时间维度和所有的事实表都有关联
(2)从业务关系图中,看到所有的维度都和订单明细事实表都有关联
- 确定事实
即确定每张事实表的度量值(度量值就是一些可累加的量词。例如次数、个数、件数、金额)