数仓建模和数仓分层
数仓建模和数仓分层
KNOWU数仓建模
简介
建模: 主要指的如何构建表, 一般在进行建模的时候, 都会有一个规范来规定这个建模方式。数据仓库建模方法论可分为:维度建模、范式建模、Data Vault模型、Anchor模型。企业中最流行、也是最经典的数仓建模经典是维度建模。
常见的建模规范主要两种:
- 三范式建模:
- 适用于 关系型数据库, 或者业务库 (OLTP系统)
- 例如: 三范式规定在建模过程中, 尽可能避免冗余的出现, 建议每个表一般都要有一个主键
- 维度建模:
- 适用于分析性数据库 (OLAP)
- 例如: 可以允许出现有一定冗余, 每个表可以没有主键 (只要利于分析的建模 就没啥大的问题)
维度建模数据模型
在维度建模中, 数据模型主要三种模型:
- 星型模型:
- 特点: 只有一个事实表, 也就是说只有一个分析的主题, 在事实表周围围绕了多个维度表, 维度表与维度表没有任何的关联
- 请问, 星型模型是数仓发展在什么期在最容易产生模型: 初期阶段
- 雪花模型:
- 特点: 只有一个事实表, 也就是说只有一个分析的主题, 在事实表周围围绕了多个维度表, 维度表可以接着关联维度表
- 请问, 雪花模型是数仓发展在什么期在最容易产生模型: 出现畸形的时候
- 这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。好处 划分更加明确了
- 星座模型:
- 特点: 有多个事实表, 也就说有多个分析的主题, 在事实表周围围绕了多个维度表, 在条件合适情况下, 多个事实表之间可以共享维度表。数仓模型建设后期,大部分维度建模都是星座模型。
- 请问, 星座模型是数仓发展在什么期在最容易产生模型? 一般是在 中 后 期最容易产生模型
维度建模流程
维度建模步骤:选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。
粒度
用于确定某一事实表中的行表示什么,是业务最小活动单元或不同维度组合,即业务细节程度。
事实表
什么是事实表?
要分析的主题是什么 , 事实表就是对应主题的表
事实表有那些特征呢? 一般事实表都是由一坨主键(其他表)聚集组成的
事实表的三大分类:
- 事务事实表:
- 事务事实表记录的事务层面的事实,保存的是最原子的数据,也称“原子事实表”或“交易事实表”
- 沟通中常说的事实表,大多指的是事务事实表。
- 周期快照事实表:
- 周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,时间间隔如每天、每月、每年
- 累积快照事实表:
- 累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度,它通常具有多个日期字段,用来记录整个生命周期中的关键时间点
注意:**这里需要值得注意的是,在事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。
维度表
什么是维度表?
在分析事实表的时候, 可以需要结合其他表来进行分析, 而其他的表就是维度表
维度表的分类:
- 高基数维度数据 : 维度表中数据量一般比较庞大, 例如商品表, 用户表
- 低基数维度数据: 维度表中数据量一般比较小, 地区表, 日期表
维度表,一致性维度,业务过程的发生或分析角度,我们主要关注下退化维度和缓慢变化维。
(1)退化维度(DegenerateDimension)
在维度类型中,有一种重要的维度称作为退化维度,亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。
☆(2) 渐变维(Slowly Changing Dimensions)
维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为渐变维或缓慢变化维(SCD)。
目的: 用于处理历史变化数据, 是否需要存储历史变更数据
SCD常用的三种处理方式:
- SCD1: 直接覆盖, 不保存历史变更数据, 仅适合于错误数据的处理
SCD2: 采用拉链表方案, 建表时需要多出两个字段(起始时间和结束时间)
在为维度成员增加新行时,需为其分配新的主代理键。并且,至少需要在维度行再增加三列:有效日期、截止日期、行标识。**这个地方可联想拉链表设计。
在发生变更数据后, 对之前数据进行过期处理, 然后新增最新变更后的数据即可
好处:
- 维护简单, 利于分析
弊端:
- 会有冗余数据的出现
适用于需要保存多个历史版本的场景
SCD3:
TYPE3 增加属性列
- 当发生数据变更后,在表中新增一个字段, 用于记录最新变更数据即可,只保存了最近两次的历史记录
- 好处:
- 尽可能避免冗余
- 弊端:
- 维护复杂, 不利于维护多个历史版本
- 效率降低
- 适用于保存少量历史版本, 而且磁盘空间不足的情况下
数据仓库的分层架构
请问为什么数据仓库要进行分层呢?
- 功能划分更加明确
- 维护更加方便
宽泛hive分层架构共计有三层:
ODS层: 源数据层
作用: 对接数据源, 将数据源中数据加载到ODS层中, 形成一张张表, 一般和数据源中数据保持同样粒度(数据一致)
主要用于放置事实表数据, 和少量维度表数据
注意: 在导入到ODS层, 可能也会对数据进行预处理工作(清洗) – 并不一定存在
例如:
1
21) 如果数据直接来源于MYSQL数据源, 可能一般不需要进行预处理工作 本身数据就是结构化数据
2) 如果数据直接来源于某个文件的, 可能需要对文件中数据进行判定, 如果有一些脏乱差的数据, 可能需要提前进行预处理工作, 转换为结构化数据
DW层: 数据仓库层
作用: 进行数据的分析工作 数据来源于ODS层
细化分层:
DWD层: 明细层
- 作用: 根据要分析的主题, 从ODS层抽取相关的数据, 对数据进行清洗转换处理工作, 然后将数据加载到DWD层, 一般将此层称为 大聚合层, 一般将所有相关的数据全部糅杂在一个表中, 在此过程中, 可以进行一定的维度退化操作
1
2
3
4
5什么叫转换处理呢?
比如说: 对于时间而言, 在ODS表中有一个时间字段, 字段数据为: 2020-12-10 15:30:30
说明:
在ODS层这个时间字段上, 糅杂了太多字段数据, 包含 年 月 日 小时 分钟 秒
此时, 需要将字段导入到DWD层时候, 将其转换为 年 月 日 小时 ...DWM层: 中间层
- 作用: 主要是用于对DWD层进行进一步聚合操作, 同时此层可以进行维度退化的操作, 此层的表一般就是周期快照事实表
1
2
3
4例如:
比如分析的维度中有时间维度:
需要分别计算 年 月 日 小时
可以先将数据按照 小时进行聚合操作, 形成一张按照小时聚合的表, 当需要按照日来聚合的时候, 只需要将每个小时数据进行累加在一起即可, 从而提升效率DWS层: 业务层
- 作用: 主要对DWM层或者DWD层数据, 进行再次细化的聚合统计操作, 在此层需要针对各个维度都进行聚合统计结构了, 将所有维度统计的结果, 放置在一起, 形成宽表数据
- 注意: 此层一般就是最终分析结果的数据了
APP(DA)层: 数据应用层
作用: 主要是用于存储DW层分析之后的结果数据, 用于对接后续的应用(图表, 机器学习, 推荐 …..)
注意: 如果不需要在针对DWS层, 在此进行统计工作, 注意DWS层就是最终结果数据
1
2什么时候需要使用APP层:
当DWS层统计结果, 被划分在多个不同结果表, 需要对DWS层数据进行再次的统计工作, 此时需要将统计的结果存储在APP层
DIM层: 维度层
作用: 存储维度表数据
说明: 当维度表较多的时, 建议将其放置在DIM层

