2023.11.22 数据仓库2-维度建模

2.1项目架构图

集群管理工具: Cloudera Manager

数据源: 业务系统的Mysql与SQLServer数据库；

数据抽取: 使用DataX实现关系型数据库和大数据集群的双向同步；

数据存储: HDFS

计算引擎: Hive

交互查询引擎: Presto

OLAP: PG

数据可视化: Fine Report

调度系统: DolphinScheduler(海豚调度)

2.2数仓结构图

ODS层: 源数据层
- 作用: 对接数据源, 将数据源中数据加载到ODS层中, 形成一张张表, 一般和数据源中数据保持同样粒度(数据一致)
- 主要用于放置事实表数据, 和少量维度表数据
- 注意: 在导入到ODS层, 可能也会对数据进行预处理工作(清洗) -- 并不一定存在
- 例如:
  复制代码
```
1) 如果数据直接来源于MYSQL数据源, 可能一般不需要进行预处理工作 本身数据就是结构化数据
2) 如果数据直接来源于某个文件的, 可能需要对文件中数据进行判定, 如果有一些脏乱差的数据, 可能需要提前进行预处理工作, 转换为结构化数据
```
DW层: 数据仓库层
- 作用: 进行数据的分析工作数据来源于ODS层
- 细化分层:
  - DWD层: 明细层
    - 作用: 根据要分析的主题, 从ODS层抽取相关的数据, 对数据进行清洗转换处理工作, 然后将数据加载到DWD层, 一般将此层称为大聚合层, 一般将所有相关的数据全部糅杂在一个表中, 在此过程中, 可以进行一定的维度退化操作
    复制代码
```
什么叫转换处理呢? 
    比如说: 对于时间而言, 在ODS表中有一个时间字段, 字段数据为:  2020-12-10 15:30:30
    说明:
        在ODS层这个时间字段上, 糅杂了太多字段数据, 包含 年  月  日 小时 分钟 秒
    此时, 需要将字段导入到DWD层时候, 将其转换为  年 月 日 小时 ...
```
  - DWM层: 中间层
    - 作用: 主要是用于对DWD层进行进一步聚合操作, 同时此层可以进行维度退化的操作, 此层的表一般就是周期快照事实表
    复制代码
```
例如: 
    比如分析的维度中有时间维度: 
        需要分别计算 年  月  日 小时
    可以先将数据按照 小时进行聚合操作, 形成一张按照小时聚合的表, 当需要按照日来聚合的时候, 只需要将每个小时数据进行累加在一起即可, 从而提升效率
```
  - DWS层: 业务层
    - 作用: 主要对DWM层或者DWD层数据, 进行再次细化的聚合统计操作, 在此层需要针对各个维度都进行聚合统计结构了, 将所有维度统计的结果, 放置在一起, 形成宽表数据
    - 注意: 此层一般就是最终分析结果的数据了

APP(DA/ADS/RPT)层: 数据应用层
- 作用: 主要是用于存储DW层分析之后的结果数据, 用于对接后续的应用(图表, 机器学习, 推荐 .....)
- 注意: 如果不需要在针对DWS层, 在此进行统计工作, 注意DWS层就是最终结果数据
  复制代码
```
什么时候需要使用APP层: 
    当DWS层统计结果, 被划分在多个不同结果表, 需要对DWS层数据进行再次的统计工作, 此时需要将统计的结果存储在APP层
```
DIM层: 维度层
- 作用: 存储维度表数据
- 说明: 当维度表较多的时, 建议将其放置在DIM层

3.建模设计

ODS层使用关系建模开发，DW层和ADS层采用维度建模开发。

维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实

1)选择业务过程

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

2)声明粒度

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

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

典型的粒度声明如下：

订单事实表中一行数据表示的是一个订单中的一个商品项。

支付事实表中一行数据表示的是一个支付记录。

3)确定维度

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

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

4)确定事实

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

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

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

4.维度建模

维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。

什么是事实表:

事实表: 指的主题,要统计的主题是什么, 对应事实就是什么, 而主题所对应的表, 其实事实表

事实表一般是一堆主键(外键)的聚集

事实表一般是反应了用户某种行为表

比如说:

订单表, 收藏表, 登录表, 购物车表 ...

事实表分类:

事务事实表 : 最初始确定的事实表其实就是事务事实表

周期快照事实表: 指的对数据进行提前聚合后表, 比如将事实表按照天聚合统计结果表

累计快照事实表: 每一条数据, 记录了完整的事件从开始到结束整个流程, 一般有多个时间组成

什么是维度表:

维度表: 当对事实表进行统计分析的时候, 可能需要关联一些其他表进行辅助, 这些表其实就是维度表

维度表一般是由平台或者商家来构建的表, 与用户无关, 不会反应用户的行为

比如说: 地区表商品表时间表, 分类表...

维度表分类:

高基数维度表: 如果数据量达到几万或者几十万甚至几百万的数据量, 一般这样维度表称为高基数维度表

比如: 商品表 , 用户表

低基数维度表: 如果数据量只有几条或者几十条或者几千条, 这样称为低基数维度表

比如: 地区表时间表分类表配置表

数据发展模式y以及对应的模型

● 星型模型:

○ 特点: 只有一个事实表, 也就意味着只有一个分析的主题, 在事实表周围围绕了多张维度表, 维度表与维度表没有任何关联

○ 数仓发展阶段: 初期

● 雪花模型:

○ 特点: 只有一个事实表, 也就意味着只有一个分析的主题, 在事实表周围围绕了多张维度表, 维度表可以接着关联其他的维度表

○ 数仓发展阶段: 异常, 出现畸形状态在实际数仓中, 这种模型建议越少越好, 尽量避免这种模型产生

● 星座模型:

○ 特点: 有多个事实表, 也就意味着有了多个分析的主题, 在事实表周围围绕了多张维度表, 在条件吻合的情况下, 事实表之间是可以共享维度表

○ 数仓发展阶段: 中期和后期

维度建模从需求出发，重点关注快速完成需求分析，围绕性能和易理解性构建模型，以事实表与维度表的形式重新组织数据。

在OLAP应用中主要有两大优势：

1):前期建模成本较低，从业务需求出发，快速迭代；

2):查询性能高，通过数据冗余降低查询的复杂度。

主要劣势: 数据冗余, 数据一致性维护增大

因此，从整体来说维度建模的开发和使用成本较低，但是维护成本较高，比较适合在接近业务分析的数据集市层、分析层来使用。

5.数仓建设规范

数据库划分规范

MySQL:dim/sale/member

SQL Server: order/stock

Hive:

dim:用于存放维表表信息及数据

ods:用于存放 ods层表信息及数据

dwd:用于存放 dwd层表信息及数据

dwm:用于存放 dwm层表信息及数据

dws:用于存放 dws层表信息及数据

ads:用于存放 ads层表信息及数据

PostgreSQL: dm

表命名规范

命名规则: 分层_主题_实体+业务+维度_分区

分层：ods dwd dwm dws ads

主题：dim/sale/sold/sell/mem/shop/order/stock

数据域：dim/goods/category/store/marketing/saleorder/abnormal/pay/mem/shop/order

实体+业务+维度：

示例：

store_goods_statistics_day

store_member_statistics_day

分区：

i : 分区表（increment增量）

f : 全量表（full全量）

表字段类型规范

数量类型整数为:bigint

金额类型为:decimal(27, 2)，表示：27位有效数字，其中小数部分2位

字符串(名字，描述信息等)类型为:string

日期类型为:string

时间类型为:timestamp