【数仓理论】

一、数仓建模方法论

1.1 ER模型(Entity Relationship、实体关系模型、范式模型)

ER模型是Bill Inmon提出的一种建模方法,实体关系模型将复杂的数据抽象为两个概念 ---- 实体和关系
该模型在范式理论上符合3NF,这种模型目的是减少数据冗余,保证数据的一致性,这种模型不适合直接用于分析统计

范式一共有6种,范式级别越高,数据冗余越低:
第一范式(1NF)、第二范式(2NF)、第三范式(3NF)
巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)

如下图为根据ER模型所建立的模型,较为松散,物理表多(需多表join,所以不适合分析统计)
【数仓理论】_第1张图片

1.1.1 第一范式(1NF)

第一范式(1NF)的核心原则:属性不可切割
如下图,“5台电脑”要拆分为数量“5”和商品“电脑”两个字段
【数仓理论】_第2张图片

1.1.2 第二范式(2NF)

第二范式(1NF)的核心原则:不能存在非主键字段“部分函数依赖”于主键字段【除主键外其他字段完全依赖于主键】
如下图,主键是(学号,课名),姓名完全依赖于学号,部分依赖于(学号,课名),因此是不满足第二范式的,需将姓名拆分出来
【数仓理论】_第3张图片

1.1.3 第三范式(3NF)

第三范式(1NF)的核心原则:不能存在传递函数依赖【决定某字段值的必须是主键】
如下图,系主任传递依赖于学号(系主任依赖于系名,系名依赖于学号,因此为传递依赖)
【数仓理论】_第4张图片

1.2 维度模型(重点)

维度模型是Ralph Kimball提出的一种建模方法,维度模型将复杂的业务抽象为两个概念 ---- 事实和维度
该模型关注的重点在于用户如何更快的完成需求分析及数据分析
如下图为根据维度模型所建立的模型,中间是事实表,周围是一圈维度表,模型更清晰、简洁
【数仓理论】_第5张图片

1.2.1 事实表

事实表是数据仓库维度建模的核心,紧紧围绕着业务过程来设计,其包含与该业务过程有关的维度引用(维度表外键)以及该业务过程的度量(通常是数字类型)
以上图为例,维度表外键对应OderId,ProductId,LocationId等,度量对应SalesAmount
事实表的三种类型分为:事务事实表、周期快照事实表、累计快照事实表

事务事实表(重点)

事务型事实表用来记录各业务过程,它保存的是各业务过程的最细粒度的操作事件。

设计事务事实表时一般可遵循以下四个步骤:
选择业务过程→声明粒度→确认维度(维度外键)→确认事实(度量)

周期快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,主要用于分析一些存量型(例如商品库存,账户余额)或者状态型(空气温度,行驶速度)指标。一般是直接从业务系统同步获得。

比如有一张记录账户余额变动的表,每次计算账户余额要进行聚合操作,而使用周期快照事实表则可以直接获得其余额,不用再进行聚合操作
对于空气温度、行驶速度这些状态型指标,由于它们的值是连续的,所以无法使用事务型事实表统计而只能定期对其进行采样,构建周期型快照事实表。

累计快照事实表

累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表,如交易流程中的下单、支付、发货、确认收货业务过程。
累积型快照事实表通常具有多个日期字段,每个日期对应业务流程中的一个关键业务过程(里程碑)。

订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额
1001 1234 2020-06-14 2020-06-15 2020-06-16 2020-06-17 1000 1000

累积型快照事实表主要用于分析业务过程(里程碑)之间的时间间隔等需求。使用累积型快照事实表进行统计,就能避免事务事实表的关联操作,从而变得十分简单高效。

1.2.2 维度表

事实表围绕业务过程进行设计,而维度表则围绕业务过程所处的环境进行设计
维度表主要包含一个主键和各种维度字段维度字段称为维度属性

设计维度表时一般可遵循以下三个步骤:
确定维度表→确定主维表和相关维表→确定维度属性

1)确定维度表:

确定与每个事实表相关的维度

  1. 如果存在多个事实表与同一个维度都相关的情况,这种情况需保证维度的唯一性,即只创建一张维度表。
  2. 如果某些维度表的维度属性很少,例如只有一个**名称,则可不创建该维度表,而把该表的维度属性直接增加到与之相关的事实表中,这个操作称为维度退化
2)确定主维表和相关维表:

主维表与相关维表指的是业务系统中某维度相关的表

3)确定维度属性:

确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择,也可通过进一步加工得到。

1.3 维度表的星型模型、雪花模型

规范化是指使用一系列范式设计数据库的过程,其目的是减少数据冗余,增强数据的一致性。通常情况下,规范化之后,一张表的字段会拆分到多张表。
反规范化是指将多张表的数据冗余到一张表,其目的是减少join操作,提高查询性能。

在设计维度表时,如果对其进行规范化,得到的维度模型称为雪花模型,如果对其进行反规范化,得到的模型称为星型模型
雪花模型与星型模型是针对于维度表来说的,区别在于是否进行规范化
如下图,item表和location表,雪花模型对其进行了规范化,拆分出来了一张表
【数仓理论】_第6张图片
数据仓库系统的主要目的是用于数据分析和统计,所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型,用户在统计分析的过程中需要大量的关联操作,而采用星型模型,则方便、易用且性能好。所以出于易用性和性能的考虑,维度表一般是很不规范化的

1.4 维度表的变化

维度属性是会随时间变化的,比如客户的手机号。
保存维度数据的历史状态,通常有以下两种做法,分别是全量快照表拉链表

全量快照表

离线数据仓库的计算周期通常为每天一次,所以可以每天保存一份全量的维度数据。
优点: 简单有效,方便理解和使用
缺点: 浪费存储空间,尤其是当数据的变化比例比较低时。

拉链表

拉链表,记录每条信息的生命周期,一旦生命周期结束,就重新开始一条新的记录,把当前日期放入生效开始日期,如果当前信息至今有效,在生效结束日期中填入一个极大值(如9999-12-31)。
该方式更加高效的保存维度信息的历史状态。
【数仓理论】_第7张图片
拉链表适合于:数据会发生变化,但是变化频率不高的维度。

二、数据的同步策略

数据的同步策略有全量同步增量同步

2.1 全量同步

全量同步,就是每天都将业务数据库中的全部数据同步一份到数据仓库,这是保证两侧数据同步的最简单的方式。

2.2 增量同步

增量同步,就是每天只将业务数据中的新增及变化数据同步到数据仓库。采用每日增量同步的表,通常需要在首日先进行一次全量同步。

通常维度表使用全量同步,事实表使用增量同步

同步策略
事务事实表 增量同步
周期快照事实表 全量同步
累计快照事实表 增量同步
维度表中的全量快照表 全量同步
维度表中的拉链表 增量同步

三、数仓设计

1.1 数仓分层规划

【数仓理论】_第8张图片
维度建模的事实表存放在DWD层,维度表存放在DIM层
数仓分层的好处:

  1. 每一层都有自己的作用,方便理解,数据结构清晰
  2. 便于进行数据血缘追踪,当出现问题时能够较快的定位问题(解耦合)
  3. 开发一些通用的中间层,能够减少大量的重复计算

1.2 数仓构建流程

【数仓理论】_第9张图片
数据仓库模型设计除横向的分层外,通常也需要根据业务情况进行纵向划分数据域。
划分数据域(主题域) 的意义是便于数据的管理和应用。
通常可以根据业务过程或者部门进行划分。

1.3 业务总线矩阵

业务总线矩阵中包含维度模型所需的所有事实(业务过程)以及维度,以及各业务过程与各维度的关系。
矩阵的行是一个个业务过程,矩阵的列是一个个的维度,行列的交点表示业务过程与维度的关系。
【数仓理论】_第10张图片

你可能感兴趣的:(数据仓库)