数据仓库知识点总结（数仓分层建模、维度建模等）

数据仓库知识点总结

• 推荐学习《华为数据之道》《数据仓库工具箱-维度建模权威指南》两本书。
• 此文档是数据仓库建模的知识点总结文档，在持续更新中（2021-10-13）。
  

1.数据仓库分层理论

1.1数仓分层架构的好处

• 1.清晰的数据结构：

​ 每一个数据分层都有对应的作用域，在使用数据的时候能更方便的定位和理解（易定位与理解）

• 2.数据血缘追踪

​ 当提供给业务系统或下游系统的数据服务中的数据异常时，清晰的血缘关系可以快速的定位问题所在，血缘管理也是元数据管理重要的部分。数据血缘关系管理

• 3.减少重复开发

​ 遵循数据加工原则，下层包含了上层数据加工所需要的全量数据，避免重复造轮子

• 4.数据关系条理化

​ 源系统之间存在着复杂的数据关系，例如当客户信息同时存在于多个系统时，数仓会把相同主题的数据进行统一建模，从而将复杂的数据关系变为清晰的数据模型。或者采用主数据管理系统对客户信息进行统一管理，抽象为一致性客户维度数据一致性

• 5.屏蔽原始数据影响

数据逐层加工原则，使得原始数据离应用层还有多层的数据加工，原始数据出问题，因为存在多个层级，也可以保持应用层的稳定性。

1.2 数据仓库核心分层

​ 数仓分层方式，各有不同，但可以提炼出一下共性：

• 1）源系统归集到数仓的缓冲层，或为贴源层

• 2）具备数据标准化及合并全量数据的标准层

• 3）具备主题划分及明细数据整合的主题层

• 4）具备提供数据服务给下游系统使用的集市层，或称为应用层

  数据仓库的核心分层为ODM贴源层、SDM标准层、FDM主题层、ADM应用层

ODM

​ 如何在ODM层保证数据正常入库：

• 1）数据入库的全流程校验机制（重要）

  ​ 进行数据抽取时，将落地的文本数据与源系统抽取记录数进行比对，即可完成数据抽取的完整性校验。数据入库时，把入库的记录数与文本数据的记录进行匹配，既可完成数据入库的完整性校验。

• 2）使用元数据管理工具

  ​ 定时同步源系统的数据结构到数仓进行比对，当发现差异及时预警。

• 3）处理好映射关系

  ​ 将输入抽取及数据入库的处理流程固化，未来源系统出现新增活着吧变更需求时。处理好映射关系，无需重复开发处理流程。

• 4）建设预警机制

  ​ 短信预警通知

• 数仓设计

• 数据资产

• 数据质量

• 指标系统

• 数据地图

2.数据仓库建模方法论

2.1 ER模型

数据仓库之父Bill lnmon提出，在范式理论上符合3NF。具有以下几个特点：

• 全面了解企业业务和数据
• 实施周期非常长
• 对建模人员能力要求非常高

2.2 维度模型

由Ralph Kimball提出，他的书：《数据仓库工具箱》是数据仓库建模的经典书籍 。维度建模从分析决策的需求出发构建模型，为分析需求服务。主要分为以下步骤：

• 选择业务过程
• 选择粒度，预判需要细分的程度
• 确定维度，选择好粒度之后，需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选
• 选择事实，确定分析需要衡量的指标

2.3 Data Vault模型

待补充

2.4 Anchor 模型

待补充

3.维度建模方法论

在不成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。所以在数据仓库的建设过程中，建议以Kimball的维度建模为核心理念去建设。

数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实

3.1模型层次（数仓的分层理论）

数仓主要分为三层

• 操作数据层（ODS）

  将操作系统数据几乎无处理地存放在数据仓库系统中

• 公共维度模型层（CDM）

  明细数据层：DWD

  汇总数据层：DWS，

  采用维度退化，将维度退化到事实表中，减少事实表和维表的关联，提高明细数据表的易用性；同时在汇总数据层，加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工

• 应用数据层（ADS）

3.2 模型实施过程

构建维度模型的四个阶段

• 高层模型设计
• 详细模型设计
• 模型审查、再设计和验证
• 详细设计文档，ETL设计和开发

3.2 维度设计

度量称为**“事实”，将环境描述为“维度”**。维度的作用一般是查询约束、分类汇总以及排序

作为维度建模的核心，在企业级数仓中必须保证维度的一致性

维度的基本设计方法：

• Step1：选择维度或者新建维度，
• Step2：确定主维表
• Step3：确定相关维表、
• Step4：确定维度属性

对于维度表的属性具有层次结构的情况，一般有两种处理方式：

规范化与反规范化：

• 规范化：

  雪花模型，采用雪花模型，除了可以节约一部分存储空间外，对于OLAP系统来说，没有其他效用。出于易用性和性能的考虑，维度一般不做规范化处理。用空间换时间。

• 反规范化：

  将维度的属性层次合并到单个维度中的操作称为反规范化，例如：星型模型

OLAP系统的主要目的是如何方便用户进行统计分析，若采用雪花模型，则用户在统计分析过程中需要大量的关联操作，使用复杂度高，同时查询性能也很差，这时候就需要采用反规范化处理，方便易用。

依据维度设计的原则，尽可能丰富维度属性，同时进行反规范化处理。

维度表的水平整合与垂直整合

既然有了整合也会有拆分

维度表的水平拆分与垂直拆分

• 依据维度的不同分类的属性差异情况
• 依据业务关联程度，关联性较低的维度没有必要放在一起

缓慢变化维应对维度的变化

在Kimball维度建模理论中，必须使用代理键作为每个维度表的主键，用于处理缓慢变化维。

• 但是在分布式计算系统里，不存在事务概念，对于每个表的记录生成稳定的全局唯一的代理键难度很大。
• 使用代理键会大大增加ETL的复杂性，对ETL任务的开发和维护成本很高

不使用代理键如何处理缓慢变化维的问题呢？

可以采用快照的方式，每天保留一份全量快照数据。按日做分区。

优点：

- 简单，有效，开发维护成本低
- 使用方便，理解性好

缺点：

• 存储极大的浪费，需要有对应的数据生命周期制度，清楚无用的历史数据

微型维度

枚举值

维度的层次

• 均衡层次结构

  层次固定，例如地理信息

• 非均衡层次结构

  层次不固定

层次结构扁平化

层次桥接表
不建议使用桥接表，很多时候，简单。直接的技术方案往往是最好的解决方案

行为维度

多值维度

多值属性：属性字段值/多表/联合主键

杂项维度

3.3 事实表设计

度量：

• 可加

  与事实表关联的任意维度都可以进行汇总

• 半可加

  只能按照部分维度汇总，不能对所有维度汇总。例如，库存可以按照商品和地点进行汇总，但是不能按照时间维度汇总

• 不可加

  度量完全不具备可加性。例如比率型事实

事实表类型：

• 事务事实表

  也称为原子事实表，用来描述业务过程

• 周期快照事实表

  以时间间隔来记录事实，例如每天，每月，每年等

• 累积快照事实表

  表示过程开始和结束之间的关键时间点，随着生命周期的不断变化，记录也会随着过程的变化而被修改。

事实表设计原则

• 1.将不可加的事实分解，例如订单的优惠率，可以分解为订单原价金额和订单优惠金额两个事实
• 2.在选择维度和事实之前必须声明粒度
• 3.在同一个事实表中的粒度必须相同
• 4.事实的单位要一致
• 5.对事实的NULL值要处理
• 6.使用退化维度提高事实的易用性

事实表设计方法

• 选择业务过程及确定事实表类型

• 声明粒度

  最细粒度

• 确定维度

• 确定事实

• 冗余维度

在淘宝订单付款事务事实表中，通常会冗余大量维度字段，以及商品类目，卖家店铺信息等维度信息

单事务事实表，即针对每个业务过程设计一个事实表

多事务事实表，将不同的事实放入到同一个事实中，即同一个事实表包含不同的业务过程。

聚集型事实表

• 一致性
• 避免单一表设计
• 聚集粒度可不同

4 数仓模型

4.1 数仓模型需要关注以下5点：

• One Data：

​ 数仓所有的数据只加工一次。对于维度：要保证维度一致性；对于明细层数据：保证相同粒度的度量只加工一次；对于汇总层的数据：相同粒度的指标只存一份，避免重复建设。

• OneIndex：

​ 数仓指标具有唯一性，通过原子指标+派生指标来规范所有的指标系统，避免数据不一致的问题。

• OneService：

​ 数据服务划清了数据和应用的边界，应用通过数据服务，直接获取计算结果，强制把公共计算逻辑下沉到数据层面，提高数据共享能力，避免通过不同层次获取数据导致的数据准确性和安全性问题。

• OneLine

​ 最大程度保障数据流转的透明性，不同层级做不同层级的数据处理逻辑，不可逆向依赖，方便后续数据血缘关系、数据地图建立，避免数据杂乱，无法溯源。

• OneEntity

​ 主要是模型方面的建设，同一个用户，在同一个模型中，可能存在重复的记录，如何识别两个ID是同一个用户，做到所有用户只有唯一的ID标识。

4.2 缓慢变化维与拉链表

说到缓慢变化维，就需要说明一下什么是维度。维度与事实是在Kimball《维度建模权威指南》里定义的，维度指的是上下文，而事实指的是度量。请见下图：

而拉链表则是针对数据仓库中表存储数据的方式而定义的，目的是为了记录历史数据的每个状态，记录一个事务从开始，一直到当前状态的所有变化信息。

因此，两者不能混为一谈。

拉链表的使用场景

• 1.数据量比较大
• 2.表中的部分字段会被更新
• 3.需要查看某一个时间点或时间段的历史快照信息，查看某一个订单在历史某一个时间节点的状态

例子：

有一张订单表，6月20号有3条记录：

订单创建日期	订单编号	订单状态
2012-06-20	001	创建订单
2012-06-20	002	创建订单
2012-06-20	003	支付完成

到6月21号，表中有5条记录：

订单创建日期	订单编号	订单状态
2012-06-20	001	支付完成（从创建到支付）
2012-06-20	002	创建订单
2012-06-20	003	支付完成
2012-06-21	004	创建订单
2012-06-21	005	创建订单

到6月22号，表中有6条记录：

订单创建日期	订单编号	订单状态
2012-06-20	001	支付完成（从创建到支付）
2012-06-20	002	创建订单
2012-06-20	003	已发货（从支付到发货）
2012-06-21	004	创建订单
2012-06-21	005	支付完成（从创建到支付）
2012-06-22	006	创建订单

如果不使用拉链表，则

• 1.只保留一份全量表，无法查看历史记录
• 2.每天一份全量，则造成数据冗余，存储空间浪费
• 3.设计成历史拉链表保存该表，则如下：

订单创建日期	订单编号	订单状态	dw_begin_date	dw_end_date
2012-06-20	001	创建订单	2012-06-20	2012-06-20
2012-06-20	001	支付完成	2012-06-21	9999-12-31
2012-06-20	002	创建订单	2012-06-20	9999-12-31
2012-06-20	003	支付完成	2012-06-20	2012-06-21
2012-06-20	003	已发货	2012-06-22	9999-12-31
2012-06-21	004	创建订单	2012-06-21	9999-12-31
2012-06-21	005	创建订单	2012-06-21	2012-06-21
2012-06-21	005	支付完成	2012-06-22	9999-12-31
2012-06-22	006	创建订单	2012-06-22	9999-12-31

说明：

• dw_begin_date表示该条记录的生命周期开始时间
• dw_end_date表示该条记录的生命周期结束时间
• dw_end_date=‘9999-12-31’ 表示该条记录目前处于有效状态
• 如果查询当前所有有效的记录，则select * from order_history where dw_end_date=‘9999-12-31’
• 如果查询2012-06-21的历史快照，则select * from order_history where dw_begin_date<=‘2012-06-21’ and dw_end_date>=‘2012-06-21’，这条语句会查询到以下记录：

订单创建日期	订单编号	订单状态	dw_begin_date	dw_end_date
2012-06-20	001	支付完成	2012-06-21	9999-12-31
2012-06-20	002	创建订单	2012-06-20	9999-12-31
2012-06-20	003	支付完成	2012-06-20	2012-06-21
2012-06-21	004	创建订单	2012-06-21	9999-12-31
2012-06-21	005	创建订单	2012-06-21	2012-06-21

和源表在6月21号的记录完全一致：

订单创建日期	订单编号	订单状态
2012-06-20	001	支付完成（从创建到支付）
2012-06-20	002	创建订单
2012-06-20	003	支付完成
2012-06-21	004	创建订单
2012-06-21	005	创建订单

由此，拉链表即能满足对历史数据的需求，又能很大程度的节省存储资源。

Kimbal缓慢变化维一共有8种，但是只有三种被广泛使用

• 类型1 重写

  与业务数据保持一致，直接update为最新的数据。缺点是无法保留历史痕迹。

• 类型2 增加新行

  更新历史数据时间戳，新增行记录新值。

  • 自然键第一次出现时

    新增一行数据，created为业务系统的创建时间，updated为9999-12-31

  • 类型2的维度发生变化时

    将自然键当前记录的updated由9999-12-31刷新为最新时间

    新增一行记录，记录最新数据，created为最新时间，updated为9999-12-31

• 类型3 增加新列

下面是不常用的几种类型

• 类型0 不做任何变化

• 类型4 微型维度

• 类型5 类型1+微型维度

  增加当前微型维度主键，做为主维度的一个属性。从而避免主维度表行的爆炸性增长

• 类型6 类型1+类型2+类型3

• 类型7 双类型1+类型2

SCD类型	维度表行动	对事实分析影响
类型0	属性值无变化	事实与原始值相关联
类型1	重写属性值	事实与当前值相关联
类型2	为新属性值增加新行	事实与发生时的有效值关联
类型3	增加新列来存储当前和原先值	事实与当前和先前值关联

• 拉链表的实现流程

根据业务主键找出去重后的全量数据，判断业务主键是否存在于全量数据表。如果不存在，则找出新增记录，为新增记录分配代理键，并标记为当前记录 ，将数据插入维度表。如果存在，则列出维度变化类型。

判断维度表的业务主键是否存在于全量数据表

4.3 星型模型与雪花模型

雪花模型，在星型模型的基础上，维表上关联了其他维表。这种模型维护成本比较高，性能方面比较差，尤其是基于Hadoop体系构建数仓，减少Join就是减少Shuffle，性能差距会很大

4.4.数据中台总体设计方案

• 粒度性
• 模型易用性
• 模型的一致性
• 中性与共享性
• 历史性

明细数据与汇总数据

汇总数据区DWS

轻度汇总区信息，支持数据集市的数据需求。避免DM模型频繁从基础层取数，汇总，需要对DW基础表所存储的详细数据做进一步加工统计。多表连接合并，求和、平均值等。

轻度汇总数据采用逆范式宽表设计，采用维度建模的方法。尽可能包含更多的属性（维度）和指标。

建设多维集市考虑使用多维数据库（Multi Dimensional DataBase，MDD）

ETL模型分为两种

• 同步架构

• 异步架构

ETL加载方式：

• 完全刷新

• 镜像增量

• 事件增量

• 镜像比较

变化数据获取（Changing data capture）。变化数据获取有时间戳、快照。触发器和日志四种。

大体可以分为两类：

• 侵入式的

  侵入式的CDC操作会给源系统带来性能的影响。基于时间戳的CDC、基于触发器的CDC、基于快照的CDC是侵入性的。

• 非侵入式

  基于日志的CDC是非侵入性的。例如Oracle Golden Gate（OGG）。

5.数据治理

• 数据标准

  制定业务标准、技术标准、安全标准、资源管理标准，从而保障数据生产、管理、使用合规。

• 数据架构

  提升模型灵活性，保障数据一致性，消除跨层引用和模型冗余等问题。

• 数据安全

  加强敏感数据和数据共享环节的安全治理

• 元数据建设

  打通从数据采集到构建再到应用的整条链路，并为数据使用人员提供数据地图、数据可视化等元数据应用产品，解决了“找数”，“取数”，“元数据变动影响评估”等难题。

5.1 数据模型

5.2 数据质量

5.3 数据治理

• 数据治理工作，一定要先摸清楚数据的家底，规划好路线图，切记一上来就搭平台。

• 数据治理即是技术部门的事，也是业务部门的事，一定要建立多方共同参与的组织架构和制度流程，数据治理的工作才能真正落实到人，不至于浮在表面。

• 数据治理不要贪图大而全，要从核心系统，重要的数据开始做起

  二八原则：8成的数据业务，其实是靠2成的数据在支撑；8成的数据质量问题，其实是由2成的系统和人产生的。在数据治理过程中，如果能找出这2成的数据和这2成的系统和人，将会起到事半功倍的效果。
  

• 不要过度迷恋与工具，组织架构，制度流程、现场的实施和运维也非常重要。数据治理是对人的行为的治理

• 数据标注难落地是数据治理中的普遍性问题，实施过程中要区分遗留系统和新建系统，分别来执行不同的落地策略

• 数据质量问题的解决，要形成每一个环节都有确定责任人的闭环机制和反馈机制

• 数据治理工作，一定从需求开始，想办法让客户直观地看到成果

5.3.1 数据治理之元数据管理

一、元数据的定义

• 元数据（Meta Data）是描述数据的数据

  例如，要想描述清楚一个实际的数据，以某张表为例，需要知道表名、表别名、表的所有者、数据存储的物理位置、主键、索引