数仓建模方法论

1.数仓建模的理由

数据建模的主要目的是降低成本，提高数据的利用效率。尤其是大数据时代的到来，数据的多样化，巨量，更需要有效的有针对性数据建模方法。

大数据的数仓建模正是通过建模的方法，更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点，一般我们会从以下面四点考虑：

• 性能：能够快速查询所需的数据，减少数据I/O的吞吐。
• 成本：减少不必要的数据冗余，实现计算结果的复用，降低大数据系统中的存储成本和计算成本。
• 效率：改善用使用数据的体验，提高使用效率。
• 质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。

因此，毋庸置疑，大数据系统、数据平台都需要数据模型方法来帮助更好的组织和存储数据，数据建模的工作，也正是围绕上述四个指标取得最佳的平衡而努力。

2.数据建模的方法

数据仓库本质是从数据库衍生出来的，所以数据仓库的建模也是不断衍生发展的。

从最早的借鉴关系型数据库理论的范式建模，到逐渐提出维度建模等等，越往后建模的要求越高，越需满足3NF、4NF等。但是对于数据仓库来说，目前主流还是维度建模，会夹杂着范式建模。

数据仓库建模方法论可分为：E-R模型、维度模型、Data Vault模型、Anchor模型。

2.1 E-R模型

1). 简介

ER模型，全称为实体联系模型、实体关系模型或实体联系模式图（ERD）（英语：Entity-relationship model）由美籍华裔计算机科学家陈品山发明，是概念数据模型的高层描述所使用的数据模型或模式图。

ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。

ER模型分为实体、属性、关系三个核心部分。实体是长方形体现，而属性则是椭圆形，关系为菱形。

ER模型的实体（entity）即数据模型中的数据对象，例如人、学生、音乐都可以作为一个数据对象，用长方体来表示，每个实体都有自己的实体成员（entity member）或者说实体对象（entity instance），例如学生实体里包括张三、李四等，实体成员（entity member）/实体实例（entity instance） 不需要出现在ER图中。

ER模型的属性（attribute）即数据对象所具有的属性，例如学生具有姓名、学号、年级等属性，用椭圆形表示，属性分为唯一属性（ unique attribute）和非唯一属性，唯一属性指的是唯一可用来标识该实体实例或者成员的属性，用下划线表示，一般来讲实体都至少有一个唯一属性。

ER模型的关系（relationship）用来表现数据对象与数据对象之间的联系，例如学生的实体和成绩表的实体之间有一定的联系，每个学生都有自己的成绩表，这就是一种关系，关系用菱形来表示。

ER模型中关联关系有三种：

1对1（1:1） ：1对1关系是指对于实体集A与实体集B，A中的每一个实体至多与B中一个实体有关系；反之，在实体集B中的每个实体至多与实体集A中一个实体有关系。

1对多（1:N） ：1对多关系是指实体集A与实体集B中至少有N(N>0)个实体有关系；并且实体集B中每一个实体至多与实体集A中一个实体有关系。

多对多（M:N） ：多对多关系是指实体集A中的每一个实体与实体集B中至少有M(M>0)个实体有关系，并且实体集B中的每一个实体与实体集A中的至少N（N>0）个实体有关系。

举一个简单的例子：

2). ER实体详解

ER的实体还可以分为弱实体和复合实体：

弱实体：一个实体必须依赖于另一个实体存在，那么前者是弱实体，后者是强实体，弱实体必须依赖强实体存在，例如上图的学生实体和成绩单实体，成绩单依赖于学生实体而存在，因此学生是强实体，而成绩单是弱实体。

弱实体和强实体的联系必然只有1:N或者1:1，这是由于弱实体完全依赖于强实体，强实体不存在，那么弱实体就不存在，所以弱实体是完全参与联系的，因此弱实体和强实体之间的联系也是用的双线菱形。

根据弱实体的描述，修改上面的实例：

复合实体：复合实体也称为联合实体或者桥接实体，常常用于实现两个或者多个实体间的M:N关系，它由每个关联实体的主体组成，用长方体内加一个菱形来表示。

下图就是一个典型的复合实体，因为只是举例，相对粗糙，用户和商品两个实体是M:N的关系，中间又订单这个实体联系，因此订单这个实体是一个复合实体，同时如果用户实体不存在，就没有订单实体存在，因此对于用户实体来说订单是弱实体，同理商品实体如果不存在，同样不存在订单实体，因此对商品实体而言订单是弱实体，具体如下：

2). ER属性补充讲解：

er图的属性还细分为复合属性、多值属性和派生属性、可选属性，同时还有用来表示联系的属性，称为联系属性。

复合属性(composite attribute)：复合属性是指具有多个属性的组合，例如名字属性，它可以包含姓氏属性和名字属性，如下图：

复合属性也有唯一属性，例如学生的所在班级属性，由于多个年级都有班级，所以单单班级属性是不唯一的，但是和年级组成的复合属性后则可以匹配成唯一属性。

多值属性（multivalued attribute）：一个实体的某个属性可以有多个不同的取值，例如一本书的分类属性，这本书有多个分类，例如科学、医学等，这个分类就是多值属性， 用双线椭圆表示。

派生属性(derivers attribute)：是非永久性存于数据库的属性。派生属性的值可以从别的属性值或其他数据（如当前日期）派生出来，用虚线椭圆表示，如下图。

下面的社团人数就是典型的派生属性，随着学生实例的参加的社团变化，社团人数属性也会变化，一般来讲派生属性不存在于数据库中，而是通过相应的公式进行计算得到，如果要放到数据库中，那么隔一段时间就要进行更新，否则会出现数据错误。

可选属性(optional attribute)：并不是所有的属性都必须有值，有些属性的可以没有值，这就是可选属性，在椭圆的文字后用（O）来表示，如下图的地址就是一个可选属性。

关系属性：关系属于用户表示多个实体之间关系所具有的属性，一般来讲M:N的两个实体的关系具有关系属性，在1:1和1：M的实体关系中关系属性并不必要。

ER实体关系模型案例

假设在电商购物系统中，对商品、用户设计ER实体关系模型图来表示商品信息、用户购买商品之间的业务联系，完成数据库逻辑模型设计。

设计ER实体关系模型图，步骤如下：

1. 抽象出实体

2. 找出实体之间的关系

3. 找出实体的属性

4. 画出E-R关系图

转化为传统数据库表：

所以，ER模型完全可以使用图数据库代替。

2.2 维度建模

1). 维度建模简介

维度模型是数据仓库领域大师Ralph Kimall所倡导，他的《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。 维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。

维度建模的概念是比较少的，下面简单介绍一下。

2).事实表

发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表每一行都对应于一个度量事件，反之亦然。

事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。

图中的订单表就是一个事实表，可以理解他就是在现实中发生的一次操作型事件，每完成一个订单，就会在订单中增加一条记录。

事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型(条/个/次)，且记录数会不断增加，表数据规模迅速增长。

3).维度表

维度表示要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按类别进行分析，或按区域分析。这区域，类别就分别就构成一个维度。上图中的用户表，商家表，时间表这些都属于维度表。这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

例如：交易金额分析

男性用户的订单金额、联想商品的订单金额、第一季度的订单金额、收集的订单金额、家里下单的订单金额。

维度表的特征：每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。

总得来说，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析的，以查询为主，不涉及数据更新操作。

需要强调的是：

• 事实表的设计是以能够正确记录历史信息为准则。

• 维度表的设计是以能够以适合的角度来聚合主题内容为准则。

4).维度模型

a.星型模型

星型模型(star schema)是最常用的维度建模方式。星型模型是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。

星型模型的维度建模是由一个事实表和一组维表组成，且具备以下特点：

• 维表只和事实表关联，维表之间没有关联；
• 每个维表主键为单例，且该主键放置在事实表中，作为两边连接的外键；
• 以事实表为核心，维度表围绕核心呈星型分布；

b.雪花模型

雪花模型(snowflake schema)是对星型模型的扩展。雪花模型的维表可以拥有其他维度表，虽然这种模型相比星型更加规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比 星型模型要低。所以一般不是很常用。

c.星座模型

星座模型是星型模型延伸而来，星型模型是基于一张事实表的，而星座模型是基于多张事实表的，而且共享维度信息。前面的两种维度建模方法都是多维表对应于单事实表，但是在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展的后期，绝大部分维度建模都采样这种星座模式。

5). 维度变化

你的应用必须反映出移植到仓库中的数据源所发生的数据变化。维表中的数据特别容易变化。但你怎么维护记录的历史变化呢?

• 第一个也是最简单的方法是重写现有的记录而不跟踪变动。幸运的是，这个方法被许多维度所接受。例如，如果一个部门名称从“财务”变为“财务和会计”，你很可能并不需要记录这种历史变化。但是，从客户和学生的角度看，常常有必要保持跟踪姓名、婚姻状态、教育程度和其它属性的变化——你的应用必要能够获得当前的以及历史的数值。拉链表最常用。
• 管理维度慢慢改变的第二个方法是数值发生变化时创建一个新的记录，并将旧的记录标记为旧记录。
• 第三个也是最后的一个方法是维护在维表的同一行中不同列的变化域的历史数值。

6). 事实变化。

通常人们认为事实表中的记录是静态的——一旦这条记录录入到了仓库中你的工作就结束了，是吗?不幸的是这个回答是“它取决于。”在某些情况下像在一个数据仓库跟踪病人的住院情况，所有的记录通常都是静态的。如果你从1月1日到2月5日住院，那这条记录不太可能改变。

但是考虑到零售行业，所有的销售都不是最终的——我肯定你知道有些人经常将它们购买的货物因为各种原因而退回商店。一些公司管理这种交易为一系列信用和负债来结算每笔交易。但在其它的情况下你必须更新或删除事实表记录，甚至在它们添加到了数据仓库之后。例如，如果一个股票交易记录不正确，用一个相反的交易来结算是不能接受的。还有另一个问题要考虑：你可能不希望你的客户知道你的交易系统中存在的问题。甚至你希望他们只在数据被修正后才看到数据。

处理方法一:

将数据放在暂存区域直到它经过了质量检查，然后将其移植到仓库中。然而有时甚至是最全面的测试也无法捕获数据源中的所有错误，你可能需要通过处理这些包含错误数据的部分来更新多维数据集。这就是为什么有必要保持你的分析服务部分尽可能的小以便处理可以相对快一些。

处理方法二：

采用一个回写分区。采用多维数据集回写，你没有真的改变关系数据仓库中的数据;而是在一个单独的分区中添加了一条记录。当用户查询一个特殊的测量值组时，分析服务将只读分区的数据和回写分区的数据结合起来，然后显示结果。当然，执行这样的查询计算会额外增加分析服务器的执行时间，并会造成性能下降。

2.3 Data Vault建模

Data Vault是一种由Dan Linstedt提出的数据仓库建模方法，主要应用于企业级数据仓库建模。

不同于三范式数据仓库模型、维度模型，Data Vault模型主要用于存储来自多个业务系统的完整历史数据。它不区分数据在业务层面的准确与否，装在数据也不做验证和清洗，因此，Data Vault模型可用于跟踪所有数据的来源。

它的每一行数据都需要包含来源系统和装在时间，用于审计和跟踪数据来源系统。

2.3.1 Data Vault模型定义

按照Dan Linstedt的定义，Data Vault模型是面向细节的、可追踪历史的、一组有链接关系的规范化的表的集合。它综合了三范式建模和星型模型的优点，其设计理念是满足企业对数据模型灵活性、可扩展性、一致性和对需求的适应性要求，是专门针对企业级数据仓库需要的一套建模方法。

Data Vault模型只按照业务数据的原始状态存储数据，不做任何过滤、清洗、转换，比如：同一个客户在不同系统有不同地址，Data Vault模型会存储多个不同版本的客户地址数据。

该模型的主要特点：

• 与源系统完成独立。

• 所有数据基于时间戳，即便数据质量很低，也不能清洗掉数据。

• 可以适应源数据的各种变化，并可以灵活的实现模型扩展。

• 数据的来源可以完全追踪，并且数据处理作业可以支持重载。

2.3.2 Data Vault模型体系

Data Vault模型由中心表(hub)、链接表(link)、附属表(satellite)三部分组成，其核心是中心表，用于存储业务主键，链接表用于存储业务关系，附属表用于存储业务描述。

a. 中心表

中心表用于存储企业每个业务实体的业务主键，业务主键需要能够唯一标识一个业务实体。按照此定义，中心表与源系统无关，即无论业务主键是否用于多个业务系统，其在Data Vault模型中也只有一份数据。处于设计上的考虑，中心表一般由主键，业务主键，装载时间戳，数据来源系统四个字段构成，其中主键根据业务主键唯一分配，一般是与业务无关的序列数值。

b. link表

链接表是不同中心表之间的关系链接，链接表一般由一组外键字段构成，表示一种业务关系，比如：交易表、客户关联账户等。链接表主要包括主键、外键1、...、外键n、装载时间戳、数据来源等字段构成，其中主键对应多个外键的唯一组合，一般是与业务无关的序列数值。

c. satellite表

附属表用于保存中心表和链接表的描述属性，包含了所有历史变化数据，附属表有且仅有一个唯一外键关联到中心表或者链接表。附属表主要包括主键、外键、属性1、 ... 、属性n 、是否失效、失效时间戳、装载时间戳、数据来源系统，主键用于唯一标识附属表中的一行记录，一般是与业务无关的序列数值。

2.3.3 Data Vault 模型设计

根据Data Vault模型体系构成，Data Vault模型设计也由此分为三大部分。

a.中心表设计

1) 明确模型需要覆盖的业务范围。 

2) 按业务范围划分若干原子业务实体，比如：客户、产品、投资品种等。

3) 从业务实体中抽象业务主键，业务主键必须是可唯一标识业务实体且不会发生变化。

4) 按照业务主键生成中心表。

b. 链接表设计

1) 分析业务实体间的业务关系，并识别对应的中心表，这些业务关系可以是一对一、一对多、多对多多种关系。

2) 按业务关系涉及的中心表，提取中心表主键，组成构成链接表的外键，并确定链接表的主键。

说明：链接表内可以保存交易数据，也可以用附属表描述交易数据。

c. 附属表设计

附属表的设计相对比较简单，主要是从中心表、链接表出发，提取与中心表、链接表相关的上下文描述信息。由于同一业务实体的各类描述信息可能会经常变化、变化频率也不尽相同，因此需要按变化频率将不同属性信息分割，建立多个附属表。

为了访问数据的方便，可能需要设计PIT表，PIT表不是必须的，但是如果一个中心表有多个附属表，就有可能用到PIT表。PIT表的主键是有附属表关联的中心表提取而来，有几个附属表就会有几个字段用于记录附属表的变化时间戳。

2.4 Anchor模型

Anchor模型是Data Vault模型的进一步规范化，核心思想是所有的扩展只是添加而不会修改，因此将模型规范到6NF，基本变成了k-v结构化模型。
我们看一下Anchor模型的组成。
1.Anchors：类型于Data Vault的Hub，代表业务实体，且只有主键。
2.Attributes：功能类型于Data Vault的Satellite，但是它更加规范化，将其全部k-v结构化，一个表只有一个Anchors的属性描述。
3.Ties：就是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力。
4.Knots：代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。