#博学谷IT学习技术支持#

4. 数仓建模

4.1 概述

数据仓库建模的方法常用的有两种：三范式建模法、维度建模法，三范式建模法主要是应用于传统的企业级数据仓库，这类数据仓库通常使用关系型数据库实现，是由Inmon提出的，应用于自顶向下的数据仓库架构; 维度数据模型就是基于维度分析来创建模型，是由Kimball提出，应用于自下向上的数据仓库架构。本课程采用维度建模的方法。

维度建模，简称DM（Dimensional modeling），数据仓库大师Kimball的观点：维度数据模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术，是围绕性能和易理解性构建的。是面向最终用户的。也就是说，维度模型是按照用户看待或分析数据的角度来组织数据。

维度建模的两个核心概念：事实表和维度表。

4.2 事实表

4.2.1 概述

事实表记录了特定事件的数字化信息，一般由数值型数字和指向维度表的外键组成。事实表的设计依赖于业务系统。数据分析的实质就是基于事实表开展的计算操作。

一般要给事实表设计一个代理键作为每行记录的唯一标识，相当于主键。代理键一般由系统生成，和业务无关。

• 事实表中的数值信息类型

  • 可加数值类型

    • 可加事实指的是该度量可以按照和事实表关联的任一维度进行汇总。比如商品的单价，可以按照品类维度、店铺维度汇总平均值和总价格等等。

  • 半可加数值类型

    • 指的就是该度量在某些维度下不可进行汇总，或者说汇总起来没有意义，比如说余额，余额在时间维度下的汇总就没有意义。
    • 记录静态数据（库存数据，金融账户余额）的所有度量针对于日期属性等维度天然具有非可加性，但是例如库存数据针对产品种类或者商店维度进行汇总，是可加的，所以这种数据就是半可加事实。

  • 不可加数值类型

    • 指的是该度量在所有与该事实表关联的维度下都不可进行汇总，比如说比率型数据，对于这种数据，如果确实是有汇总的必要，可以将其分子分母分别存储，然后在最后汇总之后再进行除法操作，从而得到“汇总”后的比率型数据。对这类数值的计算通常是在OLAP应用中。

• 事实表中的空值

  • 事实表中的外键不能存在空值，否则会违反参照完整性，关联的维度表必须用默认的代理键而不是空值表示未知的条件。
  • 所有聚合函数，比如sum、count、min、max、avg等均可针对包含空值的字段进行度量计算，其中sum、count(字段名)、min、max、avg会忽略空值，而count(1)或count(*)在计数时会将空值包含在内。

4.2.2 分类

4.2.2.1 事务事实表

Transaction fact table，事务事实表与周期快照事实表、累积快照事实表使用相同的维度，但是它们在描述业务事实方面是有着非常大的差异的。

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”或“交易事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。用户可以通过事务事实表对事务行为进行特别详细的分析。

沟通中常说的事实表，大多指的是事务事实表。

4.2.2.2 周期快照事实表

Periodicsnapshot fact table，周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。

周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。比如说时间周期是1周，那么这个周期快照事实表的一条记录就是这一周的对于某个度量的统计值。周期快照事实表的维度个数比事务事实表要少。

周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。

4.2.2.3 累积快照事实表

Accumulatingsnapshot fact table，累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。例如订单累计快照事实表会有付款日期，发货日期，收货日期等时间点。

事务事实表中一个完整的交易记录会有一系列不同状态的数据来记录整个交易过程；而累积快照事实表只会有一条记录，数据会一直更新直到过程结束。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。

由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

举例来说：订货日期、预定交货日期、实际发货日期、实际交货日期、数量、金额、运费。

4.2.2.4 无事实事实表

没有事实发生，表面看没有事实的事实表是没有意义的，但是无事实的事实表却有其他的用途：讲述不同维度之间的对应关系，帮助业务模型落地到数据模型过程中，更好地梳理维度之间的对应关系，并且能更快获得关系数据。

最常见的例子就是维度与维度之间的关系表，或者说是多对多表的中间表。

表面上没有一个可分析的度量值，所以被称为“无事实”的事实表。但实际上这样的事实表中都会隐藏着一个count的信息，因此它也可以作为一个事实表来进行统计。

4.2.2.5 总结

特点	事务事实	周期快照事实	累积快照事实
时间/时期	时间	时期	时间跨度较短的多个时点
粒度	每行代表一个事务事件	每行代表一个时间周期	每行代表一个业务周期
事实表加载	新增	新增	新增和修改
事实表更新	不更新	不更新	新事件产生时更新
时间维	业务日期	时期末	多个业务过程的完成日期
事实	事务活动	时间周期内的绩效	限定的多个业务阶段内的绩效

---

4.3 维度表

4.3.1 概述

维度是指观察数据的角度，一般是一个名词，比如对于销售金额这个事实，我们可以从销售时间、销售产品、销售店铺、购买顾客等多个维度来观察分析。

维度表的记录数比事实表少，但是每条记录可能会包含很多字段。

维度表一般也需要设计一个代理键，映射业务数据中的主键。业务系统的主键可以是自然键（指已经存在的属性组成的键，比如身份证），也可以是代理键。

4.3.2 分类

主要包含两大类数据：

1．高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

2．低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表、地理维表等。数据量可能是个位数或者几千条几万条。

时间维度表

描述事件发生的时间，数据仓库就是一个随时间变化的数据集合，因此可能需要一个时间维度表。年月日时分秒。

地理维度表

描述地理位置信息数据，国家、省市县镇村、邮编等。

产品维度表

描述产品属性。比如书的分类，有科技、教育、小说等分类属性。

人员维度表

描述人员相关信息，销售人员、市场人员、开发人员等。

4.4 渐变维（SCD）

4.4.1 什么是渐变维

维度可以根据变化剧烈程度主要分为无变化维度、缓慢变化维度和剧烈变化维度。例如一个人的相关信息，身份证号、姓名和性别等信息数据属于不变的部分，政治面貌和婚姻状态属于缓慢变化部分，而工作经历、工作单位和培训经历等在某种程度上属于急剧变化字段。

大多数维度表随时间的迁移是缓慢变化的。比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，在设计维度和使用维度的过程中，就要考虑到缓慢变化维度的处理。

缓慢渐变维，即维度中的属性可能会随着时间发生改变，比如包含用户住址Address的

DimCustomer维度，用户的住址可能会发生改变，进而影响业务统计精度，DimCustomer维度就是缓慢渐变维（SCD）。

SCD有三种分类，我们这里以顾客表为例来进行说明：

假设在第一次从业务数据库中加载了一批数据到数据仓库中，当时业务数据库有这样的一条顾客的信息。

顾客 BIWORK ，居住在北京，目前是一名 BI 的开发工程师。假设 BIWORK 因为北京空气质量 PM2.5 等原因从北京搬到了三亚。那么这条信息在业务数据库中应该被更新了。

那么当下次从业务数据库中抽取这类信息的时候，数据仓库又应该如何处理呢？

我们假设在数据仓库中实现了与业务数据库之间的同步，数据仓库中也直接将词条数据修改更新。后来我们创建报表做一些简单的数据统计分析，这时在数据仓库中所有对顾客 BIWORK 的销售都指向了 BIWORK 新的所在地 - 城市三亚，但是实际上 BIWORK 在之前所有的购买都发生在

BIWORK 居住在北京的时候。

通过这个简单的例子，描述了因一些基本信息的更改可能会引起数据归纳和分析出现的问题。

4.4.2 SCD1（缓慢渐变类型1）

通过更新维度记录直接覆盖已存在的值。不维护记录的历史。一般用于修改错误的数据。

在数据仓库中，我们可以保持业务数据和数据仓库中的数据始终处于一致。可以在 Customer 维度中使用来自业务数据库中的 Business Key - CustomerID 来追踪业务数据的变化，一旦发生变化那么就将旧的业务数据覆盖重写。

DW 中的记录根据业务数据库中的 CustomerID 获取了最新的 City 信息，直接更新到 DW 中。

4.4.3 SCD2（缓慢渐变类型2）

在源数据发生变化时，给维度记录建立一个新的“版本”记录，从而维护维度历史。SCD2不删除、不修改已存在的数据。SCD2也叫拉链表。

当然在数据仓库中更多是对相对静态的历史数据进行数据的汇总和分析，因此会尽可能的维护来自业务系统中的历史数据，使系统能够真正捕获到这种历史数据的变化。以上面的例子来说，可能需要分析的结果是 BIWORK 在 2012年的时候购买额度整体平稳，但是从2013年开始购买额度减少了，出现的原因可能与所在的城市有关系，在北京的门店可能比在三亚的门店相对要多一些。像这种情况，就不能很简单在数据仓库中将 BIWORK 当前所在城市直接更新，通过起始时间来标识，Valid To（封链时间）为 NULL 的标识当前数据，也可以用2999，3000，9999等等比较大的年份。

4.4.4 SCD3（缓慢渐变类型3）

实际上SCD1 and 2 可以满足大多数需求了，但是仍然有其它的解决方案，比如说 SCD3。

SCD3希望只维护更少的历史记录。

比如说把要维护的历史字段新增一列，然后每次只更新 Current Column 和 Previous

Column。这样，只保存了最近两次的历史记录。但是如果要维护的字段比较多，就比较麻烦，因为要更多的 Current 和 Previous 字段。所以 SCD3 用的还是没有 SCD1 和 SCD2 那么普遍。

它只适用于数据的存储空间不足并且用户接受有限维度历史的情况。

---

4.5 常见模型

4.5.1 星型模型

是一种多维的数据关系。一个事实表为中心，多个维度表环绕周围。

一个星型模型中可以有一个或多个事实表，每个事实表可以引用任意数量的维度表。

星型模型将业务流程分为事实和维度。事实是对业务的度量，是定量的数据，比如价格、销售数量、距离、速度、质量等。维度是对事实数据属性的描述，比如日期、产品、客户、地理位置等。

4.5.2 雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展，是对星型模型的维度表做进一步规范化处理后形成的，这些被分解的表都连接到主维度表而不是事实表。

如何将维度表进行规范化处理呢？

即把低基数（重复比较多、辨识度比较低）的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，比如主键列具有唯一值，所以具有最高的基数，而性别枚举值（日期、地区等）这样的列的基数就很低。

规范化的影响

规范化的过程是将维度表中重复度比较高的字段组成一个新表，所以规范化不可避免增加了表的数量，减少了数据的存储空间，提高了数据更新的效率。但是查询时就需要连接更多的表。

折中的方式

底层使用雪花模型，上层用表连接建立视图来模拟星型模型。这样既通过规范化节省了存储空间，又降低了用户查询数据的复杂性。但是当外部查询条件不需要连接整个维度表时，该方法将会带来性能损失。

总结，雪花模型中，一个维度被规范化成多个关联的表，星型模型中，每个维度由一个单一的维度表所表示。

5. 数据仓库分层

5.1 为什么要分层？

作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能够清晰明确被设计者和使用者感知到。直观来讲就是如图这般层次清晰、依赖关系直观。

但是，大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。如下的右图，在不知不觉的情况下，我们可能会做出一套表依赖结构混乱，甚至出现循环依赖的数据体系。

因此，我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序，这就是谈到的数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

1.清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解

2.减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算

3.便于维护：当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

4.统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

5.复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

为了满足前面提到好处，通常将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP）。简单来讲，我们可以理解为：ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。下面详细介绍这三层的设计。

5.2 分层方法

5.2.1 源数据层（ODS）

此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。

5.2.2 数据仓库层（DW）

DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。

此层可以细分为三层：

1．明细层DWD（Data Warehouse Detail）：存储明细数据，此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

2．中间层DWM（Data WareHouse Middle）：存储中间数据，为数据统计需要创建的中间表数据，此数据一般是对多个维度的聚合数据，此层数据通常来源于DWD层的数据。

3．业务层DWS（Data WareHouse Service）：存储宽表数据，此层数据是针对某个业务领域的聚合数据，应用层的数据通常来源与此层，为什么叫宽表，主要是为了应用层的需要在这一层将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和DWM 层的数据。

在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS 的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

5.2.3 数据应用层（ DA 或 APP）

前端应用直接读取的数据源；根据报表、专题分析的需求而计算生成的数据。

5.2.4 维表层（Dimension）

最后补充一个维表层，维表层主要包含两部分数据：

1.高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

2.低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

6. 数据仓库设计案例

这里我们以电商网站的数据仓库为例，针对用户访问日志这一部分数据进行举例说明。

在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。

为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、 H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。

在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表。

然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。

最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。

---

7. 阿里巴巴数仓分层

在阿里巴巴的数据体系中，建议将数据仓库分为三层，自下而上为：数据引入层（ODS，

Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，

Application Data Service）。

7.1 数据引入层ODS（Operation Data Store）

存放未经处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到MaxCompute(阿里云大数据计算服务，原名ODPS)的职责，同时记录基础数据的历史变化。

7.2 数据公共层CDM（Common Data Model）

又称通用数据模型层。包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

7.2.1 公共维度层（DIM）

基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。

公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。

7.2.2 公共汇总粒度事实层（DWS）

以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。

公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。

7.2.3 明细粒度事实层（DWD）

以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

明细粒度事实层的表通常也被称为逻辑事实表。

7.3 数据应用层ADS（Application Data Service）

存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

7.4 总结

该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。整体数据分类架构如下图所示。

从交易数据系统的数据经过数据集成，同步到数据仓库的ODS层。经过数据开发形成事实宽表后，再以商品、地域等为维度进行公共汇总。

数据流向图

8. 新零售数仓分层

8.1 ODS数据源

略。

8.2 DW数据仓库

8.2.2 DWB基础数据层

数据降维后生成的明细宽表，作为中间数据使用。

8.2.3 DWS服务数据层

按照主题划分的日统计宽表，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据。

8.3 DM数据集市

数据集市层，主要职责是建设宽表模型、汇总表模型，比如用户主题宽表、销售主题宽表等。

主要作用是支撑数据分析查询以及支持应用所需数据。

8.4 RPT报表应用

同ADS层、APP层。

根据报表、专题分析的需求而计算生成的个性化数据。