☀️ 数仓建模理论，大数据邻域通用的维度建模技巧【建议收藏学习】

前言：

十年生死两茫茫，千行代码，Bug何处藏。
纵使产品经理祭苍天，又怎样？
朝令改，夕断肠。
相顾无言，惟有泪千行。
每晚灯火阑珊处，夜难寐，加班狂

正文：

数仓项目开发的流程分为：

• 业务建模：类似需求分析，将客户的需求进行剥离

• 领域建模：大体设计一下有几张表，几张源表。哪张表针对哪个主题

• 逻辑建模：确定库名、确定表明、表里有哪些字段、字段的类型、表与表之间的关系
  RDBMS(业务db，存储业务数据)，经常使用到的建模工具是PD (Power designer)

• 物理建模：如何具体的实施，源数据库是Mysql还是Oracle、通过sqoop导入到hive表中去。在数仓部分又会有哪些数据库、哪些表、会如何实施。在各个层有哪些表，表的字段如何统计出来

本文主要介绍维度建模

维度建模为逻辑建模的环节

关系建模

关系建模的特点

1.关系建模表多
2.表与表之间的关系复杂

PS:例如查询下图中 表A与B的关联关系 需要将A、B表之间的所有表进行关联查询

因为查询会进行join操作，join操作又会触发shuffle操作，所以关系建模不太适合hadoop体系

维度建模

维度建模的特点

1.维度建模表少，容易上手
2.表与表之间的关系简单，便于理解

上图中 黄点的表为该模型的事实表

事实表

事实表由外键和度量值构成，外键就是指各个维度表的id，度量值一般为商品数量，消费金额等可以累加的数值

事实表中每一行代表一个业务事件（下单、支付、退款、评价等）。事实表示的就是业务事件中的度量值（可统计次数、个数金额等）

例如：小明5月20日在淘宝花了50元买了一瓶二锅头。
维度表：时间、用户、商品
事实表：50元、1瓶

事实表的特征

1. 非常大
2. 内容相对较窄（列数少，主要是外键id和度量值）
3. 经常发生变化，每天会新增加很多

事实表的分类：

1. 事务型事实表
以每个事务或事件为单位

例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

2. 周期快照型事实表
周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

3. 累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。

例如﹐数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

维度模型的分类

1. 星型模型
   有一张事实表，周围环绕着一系列的维度表组合而成的表结构。
2. 雪花模型
   有一张事实表，周围环绕着一系列的维度表，维度表中复杂的字段通过其他的维度表进行详述，将这样组合而成的表结构。
3. 星座（星系）模型
   有多张事实表，每张事实表周围环绕着一系列的维度表，维度表又可以拥有子维度表，将这样组合而成的表结构。

PS：在真实的数仓项目中，星型模型和雪花模型使用得较多，星座模型使用得较少。

各模型的适用场景

星型模型的适用场景：

优势：
业务简单
效率高
缺点：
数据有冗余 （多余的，重复的，累赘的数据。）

雪花模型的适用场景：

优势：
关系清晰
数据冗余少，甚至没有任何冗余
缺点：
业务比较复杂
效率较低

星座模型的适用场景：

优势：
关系复杂的场合
数据量特别庞大
缺点：
可读性差，关系太复杂，查询的效率较低

模型的选择

星型还是雪花，取决于性能优先，还是灵活更优先。目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。(关系型数据可以依靠强大的主键索引）

数仓和数据库关系：
数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。(OLTP)
数据仓库：数据仓库系统的主要应用 是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

建模阶段具体的划分

1. ODS层 （ 原始数据存储层，直接加载原始日志、数据保持原貌不做处理）

ODS层（original data store）可以通过flume采集的日志数据(因为日志是一整条一行的样式，所以ods层的日志表一个字段即可，表命名以ods_xxx为准。)
Sqoop导入业务数据（业务数据因为是结构化数据，所以需要将表结构建立为mysql中对应的业务表结构，表命名同样以 ods_业务表名 命名）

PS：
mysql的业务数据表名为 order_record(订单记录) 导入到hive中命名为 ods_order_record
log日志为操作记录 load到hive表中，表的命名为 ods_operation

ods的作用：一、数据的接收存储 二、数据存根备份

a)通过flume采集到hfds相应目录下的日志文件
b)通过sqoop导入到hdfs的一些业务db中的数据
c)创建ODS层的db, 以及db下相应的表（与rdbms源库中的表名类似，表字段一般同名，类型修改成hive表中的类型）

2. DWD层 （data warehouse detail, 数仓细节层）

DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

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

a). 选择业务

在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
如果是中小公司，尽量把所有业务过程都选择。
如果是大公司（1000多张表〉，选择和需求相关的业务线。

b). 声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下:
订单事实表中一行数据表示的是一个订单中的一个商品项。
已支付事实表中一行数据表示的是一个支付记录。

1.建库，建表，表中的数据来自于ods层相应表中的数据
2.对数据进行脱敏，按要求清洗掉脏数据

PS：
对ODS层数据进行清洗，去除空值数据（每条数据中id为空的）、脏数据、超过极限范围的数据（订单金额大于最高订单金额）

c).确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是:后续需求中是否要分析相关维度的指标。
例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。
需要确定的维度就包括:时间维度、地区维度、用户维度。

4).确定事实

确定每张表中的度量值，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加的字段），例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。如何判断是否能够关联上呢?在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。

3. DWS层（data warehouse service，数仓服务层）

DWS层与DWT层统称为宽表层，意义就是减少重复计算

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。
如何判断是否能够关联上呢?在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。

a) 建库，建表，表中的数据来自于dwd层相应表中的数据
b) 表一般是经过轻度聚合之后的结果
（在这层通常会有以某一个维度为线索，组成跨主题的宽表，比如，一个用户的当日的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物车数、下单数、支付数、退款数、点击广告数组成的多列表。）
用户行为宽表（60-70个字段）、商品宽表、支付宽表

DWS和 DWT层的区别:
DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等
DWT 层存放的是所有主题对象的累积行为，例如每个地区最近7天（15天、30天、60天）的下单次数、下单金额等。

4. DM层 （data market，数据集市层）

表是关于特定主题最终统计后的结果，表中的每个字段就是统计指标。（最终宽表）

建库，建表，表中的数据来自于dwd,dws层相应表中的数据 。

PS：
1.有些公司在建模时会出现DIM层（维度层，方便统一对维度表进行管理）
2.ADS层 也叫 DM层

有收获？希望烙铁们来个三连击，让更多的同学看到这篇文章

1、烙铁们，关注我看完保证有所收获，不信你打我。

2、点个赞呗，可以让更多的人看到这篇文章，后续还会有很哇塞的产出。

本文章仅供学习及个人复习使用，如需转载请标明转载出处，如有错漏欢迎指出
务必注明来源（注明： 来源：csdn ， 作者：-马什么梅-）