数仓建模理论

数仓概念

数仓作用：管理、存储、分析数据

和MySQL的区别：

1. MySQL能够存储的数据量相对较少
2. MySQL只能存储最新的数据，但是数仓能够保存全流程中的数据，可以积累大量的历史数据。
   这样就能够多一个时间的维度来对数据进行分析

数仓的核心架构

Hive的数据保存在hdfs

数仓分层

1. ODS
2. DWD
3. DWS
4. DIM
5. ADS

每层的数据都是从上一层中来的，ODS作为第一层，其数据是从ODS中来的

对于ADS产生的分析结果，将结果放到Mysql中，通过datax同步到MySQL中进行展示。

数仓每天都需要进行数据的同步和分析，为了实现对数仓的管理，使用Dolphin Scheduler定时对数仓进行操作

数仓建模

数仓模型的定义：数据的组织和存储方法

意义：对数据进行有序的组织和存储，数据能够得到高性能、低成本、高效率、高质量的使用

高性能：快速查询所需要的数据

低成本：好的数据模型能够减少重复计算，实现计算结果的复用

高效率：能够改善用户使用数据的体验，调高数据使用效率

高质量：改善数据统计口径的混乱，减少计算错误的可能性

ER模型

用实体关系来描述企业业务，用规范化的方式表现出来，在数据范式理论上符合3NF

1. 实体关系：实体表示一个对象，关系表示两个实体之间的关系

2. 数据库范式：减少冗余，提高数据一致性

3. 优点：减少数据的冗余，增强数据的一致性

4. 缺点：因为把表切分的较多，从而导致数据的查询效率降低，不适用于大规模数据的分析统计

一般用于关系型数据库中

维度模型

把业务通过事实和维度两个概念进行呈现

1. 事实：对应业务过程
2. 维度：对应业务过程发生时所处的环境
3. 业务过程：一个个不可拆分的行为时间，例如下单、取消、付款等行为，简单来说就是一个个动作

3W1H中的what就代表这事实，其余的where、when、how就代表着维度

维度建模的理念就是将夺多表组合成一张表，从而提高数据的分析查询效率，但是会带来数据冗余

事实表

事实表内有两类数据

1. 包含业务过程中的维度应用（即维度表的外键）
2. 该业务过程中的度量（通常是可累加的数字），表示该行为进行了几次

特点：通常列少行多，行的增速快

分类：

1. 事务事实表
2. 周期事实表
3. 累计快照事实表

事务事实表

记录业务过程中的原子操作事件、粒度最细的操作事件。即记录的内容最为详细。
例如某个用户某个时间下了一笔订单买的某个商品
其保存了最细粒度的记录，能够保证最大限度的灵活性，可以支持需求更细节层次的需求。

粒度：表示实施表中一行数据所表达的业务的细节程度

理论上事务事实表能够实现所有业务的分析需求

缺点：在某些场景（多个大表join）下的性能可能较差，

1. 存量型指标（存、取，对应两个事务事实表），从而造成性能的下降
2. 多事务型关联指标（多个业务过程联合进行计算的过程，会涉及到多个表）

设计流程：

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

1. 选择业务过程：明确了需要创建多少个事实表，每个业务过程都是不可拆分的行为，一个业务过程对应一个事实表
2. 声明粒度：事实表的每行数据需要表示什么，尽可能选择最细粒度
   一个较为典型的粒度声明：一个订单中的一个商品项
3. 明确维度： 明确表中会有多少个维度外键，维度要尽可能丰富
   维度的丰富程度决定了维度模型能够支持的指标的丰富程度，丰富的维度能够方便适用于后续分析各种不同类型的需求
4. 确定事实：业务过程中的度量值（例如次数、个数、件数、金额等）

周期型快照事实表

一般是按照需求来进行的
通过有规律性的，可预见的时间间隔来记录事实，一般用于分析一些存量型数据（商品库存、账户余额）或是一些状态型的指标（空气温度、行驶速度，这类每时每刻都在发生变化的数据，无法拿到他对应的最细粒度，只能通过定时进行记录）
对于存量型指标，通常可以在MySQL中就已经有表通过计算并保存最新的结果，定期将这个计算的结果全量统计存储到数仓中即可。这样在数仓中就避免了大量数据进行计算的场景，只需要在数仓中进行单表查询即可。

涉及流程

1. 确定粒度：由采样周期和维度进行描述
   一般采样周期为天，维度一般是按照统计指标来决定，例如每个账户的余额，可以确定维度为账户和余额。
   确定完采样周期和维度之后，即可确定该表的粒度为采样周期-账户-余额（2024-01-01 张三 1000.00, 2024-01-02 张三 1200.00）
2. 确认事实
   可以通过统计指标决定，例如每个账户对应的余额，对应的事实就是账户余额
   事实类型:表示度量值的类型
   1. 可加事实：可以对所有维度进行累加，这里的可以累加表示在这个维度上累加出来的数据是有意义的，例如事务事实表中的所有度量，其要求所有的维度累加都有意义
   2. 半可加事实：只能够对事实表的一部分维度进行累加，例如周期快照事实表，对采样周期进行累加是无意义的，所有天的累计余额没有意义
   3. 不可加事实：完全不能进行累加，例如一些比例型的事实，需要将其转化成可加事实，例如转换成分子分母，对分子分母进行累加

累积快照事实表

基于一个业务流程中的多个关键业务过程联合处理构建的事实表，例如下单、支付、发货，确认收货，四个事务事实累计在一起可以定义成购买商品的一个业务流程。
这个购买的业务流程中可能还会包含有其他的业务过程，但是最关键的业务过程就是这几个，通过这几个就能够定义这个业务流程。

对于一个累计快照事实表，一般会有多个日期字段，每个日期字段对应一个业务流程中的一个关键业务过程。

主要用于分析多个关键业务过程之间的时间间隔等需求。

累积性快照事实表，一张表中包含了多个业务过程，对于求多个业务过程中关联性的一些数据而言，可以避免多表连接，通过单表查询即可完成。

设计流程

1. 选择业务过程：明确一个业务流程中需要关联哪些关键业务过程，将这些关键业务过程组合成一张累计事实表
2. 声明粒度：定义每行数据表示什么，同样尽量选择最小粒度
3. 确认维度：每个业务过程都需要一个日期维度
4. 确认事实：明确每个业务过程的度量值

和之前的事务型事实表的设计流程基本一致。

维度表建模

一个维度表包含一个主键和各种维度字段（维度属性）

设计流程

1. 确定维度：决定了需要创建多少个维度表
   在设计事实表的时候，就已经确定了每个事实表相关的维度。理论上每个维度都对应一个维度表。
   但是可能存在多个事实表和同一个维度都相关，这时候需要保证维度的唯一性，只创建一张维度表。
   如果某些维度表对应的维度属性很少，例如只有一个商品名称，这个时候可以不创建这个维度表，直接把这个维度属性加到事实表中，这个行为称为维度退化。

2. 确定主维度表和相关维度表
   和业务过程（事实表）直接关联的就是主维表，其余与这个主维表相关的表即为相关维度表
   对于维度表而言，其粒度=主维表的粒度，维度表的主键=主维表的主键

3. 确定维度属性：确定维度表的字段，维度属性时后续进行统计分析的约束条件、字段分组的主要来源
   确定维度属性时，需要遵循以下的要求：

   1. 尽可能生成丰富的维度属性：维度属性越多，数据模型能够支持的指标就越丰富
   2. 尽量不要使用编码，而是使用明确的文字说明，一般编码作为主键，辅以对应的文字说明
   3. 尽量沉淀出通用的维度属性：有些维度属性可能需要组合在一起使用，例如通过收入、身高、评价等一系列指标来评价一个人，这个字段可能组合起来之后还有新的含义，为了避免之后每次需要使用的时候都要进行重复处理，可以把这几个字段组合在一起作为一个维度属性沉淀到维度表中。

规范化

通过一系列范式设计数据库，经过规范化后，一张表的字段可以被拆分到多张表中

反规范化

将多张表的数据冗余到一张表中，目的在于减少join的操作，提高查询性能。

在建模维度表的时候，如果对表进行规范化，一张表会被拆分，得到雪花模型。如果对表进行反规范化，多张表会被合并成一张表，得到的是星形模型。

雪花模型是比较接近3NF的，但是实际上无法完全遵守，因为此时查询的性能成本太高了。一般用的最多的还是星形模型。

维度变化

维度属性不是静态的，而是会随着时间发生变化，例如同一个身份证号码的人可以改名。数仓能够记录对应的维度数据的历史状态，一般有两种方法：

全量快照表

每天保存一份全量的维度数据，和全量同步的概念差不多

1. 优点：简单有效，维护成本相对较低
2. 缺点：浪费存储空间，如果数据变化比例较低，存放了大量冗余数据
3. 使用场景：当表的数据量较小的时候，可以使用全量快照表

拉链表

能够更加高效的保存维度信息的历史状态

1. 定义： 记录每条数据的生命周期
2. 特点： 一般每条数据都会有一个开始时间和一个失效时间，如果当前记录现在依旧有效，则在失效时间处填入一个极大值（例如9999-12-31）
3. 适用于数据会发生变化，但是变化频率不高的维度（缓慢变化维）
4. 优点：没有数据冗余，节省磁盘空间
5. 缺点：对于特定日期，需要判断该记录是否有效需要进行额外的计算，使用起来相对较为麻烦

多值维度

事实表中的一条数据，能够和维度表中的多条记录对应的，被称为多值维度。例如事实表中一条记录为用户下的一个订单，该订单可能包含有多个商品，在商品维度表中就会有多条数据与之对应。一般这个问题都是由事实表的粒度不够低所产生的。

一般有两种解决方法

1. 降低事实表的粒度，让事实表中包含有该维度中的内容，例如事实表从一个订单变为一个订单中的一个商品项。
2. 事实表中采用多字段保存多个维度值，每个字段保存一个维度id，即记录每个商品的id。该方法只适用于维度属性较少的情况。

一般只使用第一种方法

多值属性

维度表中的某个属性同时有多个值，例如商品可以同时上架多个平台，该平台属性就同时会产生多个值。

一般两种解决方法

1. 将多值属性方法一个字段中，该字段是KV（key-value）型的。例如商品pdd:店铺A，tb:旗舰店等。
2. 将多值属性放到多个字段中，每个字段对应一个属性。这种方法只适用于多值属性个数固定的情况。例如用户只可选择三个兴趣，就可以用三个列来存放这三个兴趣。

数仓设计

数仓分层

数仓分层：是复杂问题简单化，使数据体系更清晰。

1. ODS Operation Data Store 原始数据层：存放未经过处理的原始数据。其在结构上与源系统保持一致，是数仓的数据准备区。
2. DWD Data Warehouse Detail 明细数据层： 基于维度建模 理论进行建模，存放维度模型中的事实表，保存各业务过程的最小粒度操作记录。对应的事务事实表
3. DIM Dimenstion 公共维度层： 基于维度建模理论，存放对应的维度表，保存一致的维度信息。
4. DWS Data Warehouse Summary 汇总数据层：以分析的主体对象作为建模驱动，构建公共统计粒度的汇总表。对应快照事实表以及一些多次需要的计算中间表，面向需求。
5. ADS Application Data Service 数据应用层： 存放各项统计指标结果。

数仓构建流程

DWD和DIM层（事实表和维度表）使基于业务驱动的

DWS是根据需求驱动的

汇总模型：就是看需求分析中有多少步骤是重复的，将重复的内容汇总创建一个新的中间表，方便使用。

1. 业务调研

   1. 熟悉业务流程：列举该业务流程中包含的所有业务过程
   2. 熟悉业务数据：将数据和业务过程对应起来，明确业务过程会对哪些数据产生什么样的影响。
   3. 需求分析：明确所需要的业务过程和对应的维度。

2. 明确数据域，联系较为紧密的数据主题的集合，对业务过程的整合抽象
   方便数据的管理和应用。一个业务过程只能属于一个数据域。

3. 构建业务总线矩阵
   总线矩阵的每一行表示一个业务过程，每一列表示一个维度，交叉的地方表示该事实表有这个维度。总线矩阵有多少个列创建多少个维度表，行数表示创建多少个事务维度表。
   

4. 明确统计指标

   1. 原子指标：
      • 基于某一个业务过程的度量值，该指标不可再分。
      • 核心功能是定义了指标的聚合逻辑。
      • 一般只是用于辅助定义指标，一般不会有实际的统计需求与之对应，一般会有一些前提。
      • 三要素：业务过程、度量值、聚合逻辑
      • 举例：订单总额：
        • 业务过程：用户下单
        • 度量值：订单金额
        • 聚合逻辑：sum() 求和
   2. 派生指标 根据派生指标就能写出sql完成相关的统计
      • 基于原子指标 派生指标=原子指标+统计周期+业务限定+统计粒度
      • 统计周期：多长时间内的
      • 业务限定：限定统计范围 where
      • 统计粒度：group by
   3. 衍生指标 在一个或者多个派生指标上通过逻辑运算所得到的，例如比例等指标，需要再进一步计算的指标
   4. 指标体系对数仓建模的意义 当统计需求足够多的时候，必定会出现一部分统计需求对应的派生指标相同的情况。可以将一些公共的派生指标保存下来，目的就是可以减少重复计算，提高数据的复用性，公共派生指标一般保存在DWS层。

5. 维度模型设计
   业务总线矩阵，事实表存在DWD，维度表存在DIM

6. 汇总模型设计
   根据指标体系进行整理。一张汇总表包含

   • 业务过程相同
   • 统计周期相同
   • 统计粒度相同

   的多个派生指标

一个事实表对应多个汇总表