数仓建模理论

---

第一章 数仓分层

一、为什么要分层

（1）数据仓库分层

• ODS层：原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。
• DWD层：对ODS层数据进行清洗（去空值，脏数据，超过极限范围的数据）、脱敏等。保存业务事实明细，一行信息代表一次业务行为，列如一次下单。
• 以DWD为基础，按天进行轻度汇总。一行信息代表一个主题对象一天的汇总行为，例如一个用户一天下单次数
• 以DwS为基础，对数据进行累积汇总。一行信息代表一个主题对象的累积行为，例如一个用户从注册那天开始至今一共下了多少次单
• ADS层，为各种统计报表提供数据

（2）数据仓库为什么要分层

• 把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题。
• 减少重复开发：规范数据分层，通过的中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性
• 隔离原始数据: 不论是数据的异常还是护具的敏感性，是真实数据与统计数据解耦开。

二、数据集市与数据仓库概念

• 数据集市（Data Mart），现在市面上的公司和书籍都对数据集市有不同的概念。
• 数据集市则是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级，一般只能位为某个局部范围内的管理人员服务。
• 数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段

• 从属型数据集市：数据仓库的数据来自业务系统，而数据集市的数据来自数据仓库

• 独立性数据集市：独立性是没有数据仓库的它是直接从业务系统直接获取数据。

• 从属型数据集市的优点：各个部门的数据集市都来自于中央数据仓库，所以说各个部门取到的数据都是经过统一处理之后的数据。所以每个部门获取到的数据是一致的。

• 从属型数据集市的优点：搭建一个从属型数据集市开发周期是比较长的，首先必须要有一个中央的数据仓库

• 独立性数据集市的优点：开发周期更短，不需要搭建中央的数据仓库

• 独立性数据集市的缺点：每个部门获取或者处理逻辑的不尽相同，这样一来就会导致每个部门之间的数据一致性相对来说是比较差的，这样就会导致一个现象数据孤岛

三、数仓命名规范

（1）表命名

• ODS层命名为ods_表名
• DIM层命名为dim_表名
• DWD层命名为dwd_表名
• DWS层命名为dwd_表名
• DWT层命名为dwt_表名
• ADS层命名为ads_表名
• 临时表命名为tmp_表名

（2）脚本命名

• 数据源_to_目标_db/log.sh
• 用户行为脚本以log为后缀；业务数据脚本以db为后缀。

（3）表字段类型

• 数量类型位bigint
• 金额类型位decimal(16,2),表示：16位有效数字，期中小数部分2位
• 字符串(名字，描述信息等)类型位string
• 主键外键类型位string
• 时间戳类型位bigint

第二章 数仓理论

一、范式理论

（1）范式概念

• 定义：数据建模必须遵循一定的规则，在关系建模中，这种规则就是范式。
• 目的：采用范式，可以降低数据的冗余性。
• 为什么要降低数据冗余性？
  （1）十几年前，磁盘很贵，为了减少磁盘存储。
  （2）以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
  （3）一次修改，需要修改多个表，很难保证数据一致性
• 缺点：范式的缺点是获取数据时，需要通过Join拼接出最后的数据。
• 分类：目前夜间范式有：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
• 范式遵循条件： 逐个遵守。也就是必须遵循第一范式的基础上再去遵循第二范式，依次类推。通常情况下遵循范式到第三范式就可以了。

（2）函数依赖

1、完全函数依赖：设X，Y是关系R的两个属性集合，X是X的真子集，存在x→Y，但对每一个X都有X’!→Y，则称Y完全函数依赖于X。记做: xSy.
设X，Y是关系R的两个属性集合，X是X的真子集，存在x→Y，但对每一个X都有X‘！→Y，则称Y完全函数依赖于X。记做：Χ^F->Y

• 人类语言：比如通过，(学号，课程) 推出分数，但是单独用学号推断不出来分数，name就可以说：分数完全依赖于(学号，课程)。
• 即：通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB。

2、部分函数依赖

• 假如Y函数依赖于X,但同时Y并不完全函数依赖于X，那么我们就称Y不依赖于X,记做：X^P-Y
• 人类语言：比如通过，(学号，课程)推出姓名，因为其实直接可以通过，学号推出姓名，所以:姓名 部分依赖于(学号，课程)
• 即:通过AB能得出C，通过A也能得出c，或者通过B也能得出c，那么说C部分依赖于AB.
  3、传递函数依赖
• 传递函数依赖：设X，Y，Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。记做:X^T->Z
• 人类语言：比如：学号推出系名，系名推出系主任，但是，系主任推不出学号，系主任主要依赖于系名。这种情况可以说:系主任传递依赖于学号

（3）三范式理论

• 第一范式
  1、第一份那还是INF核心原则就是：属性不可切割
  
  很明显上图所示的表格设计师不符合第一范式的，商品列中的数据不是原子数据项，是可以进行分割的，因此对表格进行修改，让表格符合第一范式的要求，修改结果如下图所示：
  
  实际上，INF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS）,列如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定符合1NF的。

• 第二范式
  2、第二范式2NF核心原则：不能存在"部分函数依赖"
  
  以上表格明显存在，部分依赖。比如，这张表的主键是（学号，课名），分数确实完全依赖于（学号，课名），但是姓名并不完全依赖于（学号，课名）
  

• 第三范式
  3、第三范式3NF核心原则：不能存在传递函数依赖
  在下面这张表中，存在传递函数依赖：学号->系名->系主任，但是系主任推不出学号。
  
  上面表需要子再次拆解：
  

二、关系建与维度健模

• 关系建模和维度健模是两种数据仓库的健模技术。关系建模是由Bill Inmon所倡导，维度健模由Ralph Kimabll所倡导。

（1）关系建模

• 关系建模将复杂的数据抽象为两个概念-- 实体和关系，并使用规范化的方式表示出来。关系模型如图所示，从图中可以看出，较为凌散、零碎，物理表数量多。
• 关系模型严格遵循第三范式（3NF）,数据冗余程度低，数据的一致性容易得到保证。由于数据分布与众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低

（2）维度健模

• 维度模型如图所示，从图中可以看出，模型相对清晰、简洁。
  
• 维度模型以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。表结构简单。故查询简单，查询效率较高。
• 以上图为例中间的这张表称为事实表。这个事实表周围的表称为维度表。事实表里面存储是具体的业务事实，比如说订单这个操做、支付操做、退单操做等等称之为业务事实，周围的维度表存储的是业务事实的描述信息
• 事实表当中的字段可以分为两类：一类是各种维度表的外键简称维度外键，另一类是数字类型的字段简称度量值。

三、维度表和事实表

（1）维度表

• 维度表：一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。
• 例如：用户、商品、日期、地区等。
• 维表的特征：
  1、维表的范围很宽（具有多个属性、列比较多）
  2、跟事实表相比，行数相对较小
  3、内容相对固定：编码表
• 时间维度表：
  

（2）事实表

• 事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务时间的度量值（可统计次数、个数、金额等）。

• 每一个事实表的行包括：具有 可加性的数值的度量值、与维度表相连接的外键。通常具有两个和两个以上的外键。

• 事实标的特征：
  1、非常大
  2、内容相对的窄：列数较少（主要是外键id和度量值）
  3、经常发生变化，每天会新增加很多。

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

• 周期型快照事实表：周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
  例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

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

四、维度模型的分类

• 在维度健模的基础上有分为三种模型：星型模型、雪花模型、星座模型。
  1、星型模型
  
• 雪花模型与星型模型的区别主要在于维度的层级，标准的星型模型维度只有一层，二雪花模型可能会涉及多级。

2、雪花模型

• 雪花模型，比较靠近3NF,但是无法完全遵守，因为遵守3NF的性能成本太高。
• 雪花模型主要是对维度表进行规范化。
  3、星座模型
  
• 星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表。
• 基本上是很多数据仓库的常态，因为很多仓库都是多个事实表的。所以星座不只是反应是否有多个事实表，他们之间是否共享一些维度表。
• 所以星座模型并不和前两个模型冲突。
• 模型的选择
  星型还是雪花，取决于性能优先，还是灵活更优先。目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存(一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。(关系型数据可以依靠强大的主键索引)

五、数据仓库建模

（1）ODS层

• HDFS用户行为数据
  
• HDFS业务数据
  
• 针对HDFS上的用户行为数据和业务数据，我们如何规划处理？
  1、保持数据原貌不做任何修改，起到备份数据的作用。
  2、数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
  3、创建分区表，防止后续的全表扫描

（2）DIM层和DWD层

DIM层DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
维度建模一般按照以下四个步骤：
选择业务过程→声明粒度→确认维度→确认事实
（1）选择业务过程
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
（2）声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
典型的粒度声明如下：
订单事实表中一行数据表示的是一个订单中的一个商品项。
支付事实表中一行数据表示的是一个支付记录。
（3）确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
（4）确定事实
此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。
DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。
DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

（3）DWS层和DWT层

• DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。
  1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额
  2）处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。
  那怎么设计能避免重复计算呢？
  针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。
  3）总结：
  （１）需要建哪些宽表：以维度为基准。
  （２）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
  （３）DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

（4）ADS层

• 对电商系统各大主题指标分别进行分析。