个推 TechDay 治数训练营直播精彩回顾：带你入门数仓建设，跑通数据建模

近日，2022 年个推 TechDay"治数训练营" 系列直播课第一期圆满举办。个推资深大数据研发工程师为大家深入浅出地介绍了数据仓库的前世今生以及数据建模的常用方法。

本文对 "治数训练营" 第一期《数据仓库与维度建模》的干货内容进行了总结，同时也挑选了直播间的精彩提问做了 Q&A 梳理，带大家一起回顾首期课程。

01 数据仓库快速入门

数据仓库（Data Warehouse），简称 "数仓"，是大数据从业者绕不开的一个概念。"数据仓库之父"Bill Inmon 最早提出数仓的概念，认为 "数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策"。

此外，大数据架构专家 Ralph Kimball 在《The Data Warehouse Tookit》一书中，也对数仓进行了定义："数据仓库是一个将源系统数据抽取、清洗、规格化，然后提交到维度数据存储的系统，为决策的制定提供查询和分析功能的支撑和实现"。

Bill Inmon 对数仓的定义更强调整体特性，Ralph Kimball 则是从实施流程角度来定义数仓。无论哪个定义，我们都能从中看到企业建设数据仓库的意义重大。企业通过建设数仓，不仅能够将分散在各业务系统的数据进行集中化管理，打破数据孤岛；还能为后续高效分析和应用数据，通过大数据赋能业务发展奠定基础。

02 数仓建设与数据建模

那么，企业如何建设数据仓库？如何建设一个贴合业务需求的、高效、稳定、好用的数据仓库？这就需要考虑数据模型的选择和数据建模的问题。

"数据建模" 是指对实体以及实体和实体之间的关系进行数据化描述和抽象的过程。"数据模型"，则是指组织和存储数据的方法。

目前主流的数据建模方法有两种，分别是范式建模和维度建模：

范式建模

范式建模由 Bill Inmon 提出，指站在企业角度面向主题的抽象，我们一般使用 E-R 实体关系模型将事物抽象为 "实体"" 属性 ""关系"，来表示事物和事件关联。范式建模并非针对某个具体业务流程中实体对象关系的抽象，它需要建模人员全面地、整体地了解企业的业务和数据，不仅实施周期长，对建模人员的能力要求也比较高。

维度建模

维度建模由 Ralph Kimball 提出，主张从分析决策的需求出发构建模型，为分析需求服务。因此它重点关注如何使用户更快速地完成数据分析，同时保持较好的大规模复杂查询的响应性能。相较范式建模，维度建模建设周期短，支持敏捷迭代，一般不会对数仓架构做过多复杂的设计。

在构建数仓时，我们要根据具体的数据分析场景和业务处理系统来选择相应的数据建模方法。比如，就 OLTP 系统（On-line Transaction Processing：联机事务处理）而言，由于其主要是面向随机读写的数据操作，关注事务的处理，因此我们推荐使用 OLTP 系统及传统数据库的企业通过范式建模的方法来设计数据模型，以解决在事务处理中的数据冗余和一致性问题。而 OLAP 系统（On-line Analytical Processing：联机分析处理）面向批量读写数据的操作，不关注事务处理一致性，主要是关注数据的整合以及大数据查询和处理中的性能，因此一般采用维度建模的方法。

具体如何进行范式建模和维度建模呢？我们结合案例分别来看。

03 范式建模方法及实例剖析

首先来看范式建模的基本过程。

在进行范式建模时，我们往往要遵从不同的规范要求设计出合理的模型，这些不同的规范要求就是 "范式"。目前行业中存在一范式、二范式、三范式等不同的模型建设规范。越高的范式带来的数据库冗余越小，但是在数据计算方面会更复杂。企业大多采用三范式建模，在保证灵活度以及数据计算速度的同时，降低数据处理的复杂度。

范式建模的过程可以被拆解为以下四步：

1.抽象出主体

2.梳理主体之间的关系

3.梳理主体的属性

4.画出 E-R 关系图

比如，我们要使用范式建模的方式设计某课程管理系统的数据模型。

该系统主要用来管理某学校教师、学生和课程等相关数据，涉及课程选修、考试成绩、教师授课、学生班级等方面。那我们首先要梳理出实体，为教师、课程、学生、班级；其次梳理出实体之间的关系，包括教师讲授课程、学生选修课程、学生隶属班级等；再次要罗列出各实体和关系的属性，比如 "学生" 这个实体的属性有姓名、性别、年龄等，"学生选修课程" 这个关系的属性有选修时间、总课时等；第四步，则是画出 E-R 图，用矩形表示 "实体"，用菱形表示 "关系"，用椭圆形表示 "属性"，以可视化的方式清晰展示出主体和主体之间的关系。

04 维度建模方法及实例剖析

相比范式建模，维度建模稍为复杂，包括事实表和维度表两块内容。

事实表

首先看事实表。事实表分三种，包括事务性事实表、周期性快照事实表、累计快照事实表。

事务性事实表通常用一条记录表示某个时间点发生的事件或行为。比如电商业务场景中的订单支付业务，一般就采用事务性事实表来组织和存储数据。

周期性快照事实表的一条记录描述的则是一个实体在某一段时间内的状态或现状，比如某顾客每月的积分余额就属于一条典型的周期性快照事实表记录。

累计快照事实表的一条记录则是对某业务流程中发生的多个事件的累计记录，一般是为了满足某个流程节点运转效率的统计需求。

我们以一个事务性事实表的设计过程为例来了解事实表的设计方法：

1. 选择与数据分析需求有关的业务过程。"业务过程" 是指在业务流程中不可拆分的行为事件。比如，电商业务场景下，购物的业务流程中就包括加购、下单、支付、商家发货、用户确认收货等业务过程。如果我们要分析销售额，那 "支付" 就是必选的业务过程。

2. 声明粒度。我们要尽量选择最细粒度，精确定义事实表的每一行所表示的业务含义，以确保事实表有最大的灵活性。比如，用户可能在一个订单里面购买多个商品，那每个购买的商品就是一个子订单，我们一般选择将子订单作为声明粒度。

3. 确定维度。维度是指业务过程所处的环境信息，比如用户在某个时间购买了某个店铺的某个商品，那店铺所属行业、商品所在类目等均可以被认为是维度。

4. 确定事实，即确定业务过程的度量指标。比如 "支付" 这个业务过程的度量指标为支付金额，更复杂的电商业务场景下，可能还包括分摊邮费、折扣金额等指标。

需要说明的是，每个数据仓库都包含一个或者多个事实表，事实表是对分析主题的度量，它包含了与各维度表相关联的外键，并通过 Join 方式与维度表关联。

维度表

维度表则是用户分析数据的窗口，记录了事实表中相关事务、事件的属性及属性含义。

维度表的设计过程，主要分为以下四步：

1. 选择维度。比如要生成一个商品维度表，那我们选择的维度就是商品维度。

2. 确定主维表。比如要建商品维度表，那主维表就是来自于业务系统的商品表。

3. 确定相关维度表。主维表确定之后，其他的相关维度表也就随之确定。比如商品维度表的相关维度表有商品类目表、所属品牌表、商品所属行业表等。

4. 确定维度属性。这些属性一般来自于主维表和相关维表。我们将主维表和相关维表的属性集成，并对相同属性合并（比如，商品类目表和所属品牌表中可能都会有所属行业属性，那我们就可以对所属行业这个属性进行合并），然后将最终得到的属性放到要生成的维度表里。