数仓建模理论（一）

目录

本文介绍数据建模的基础方法论，并通过建模实例的建模实践，输出对模型结构、设计模式的经验技巧与自我理解。

一、概述

1、为什么需要数据建模

如何将数据有序、有结构地分类组织和存储是数据建设者面临的一个挑战，如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置。数据模型就是数据组织和存储的方法，合适的数据模型能获得以下好处：

• 性能 :良好的数据模型能帮助我们快速查询所需要的数据，减少数据的 I/O吞吐。
• 成本 : 良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
• 效率 :良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
• 质量 : 良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

因此，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

二、典型的数据仓库建模方法论

1、维度数据模型

维度建模从需求出发，重点关注快速完成需求分析，围绕性能和易理解性构建模型，以事实表与维度表的形式重新组织数据。

维度数据模型的代表有：星型模型、雪花模型。星型模型是非规范化的设计，在设计与建设过程中不受关系数据库范式规则的约束，简单的关联逻辑便可以支持高度复杂的维度组合需求，在查询性能方面具有明显的优势；雪花模型是将一个维度规范化成多个关联的表，规范化的过程就是将维表中冗余的数据进行解耦从而分离出一些新表，以减少数据冗余。

在OLAP应用中主要有两大优势：

① 前期建模成本较低，从业务需求出发，快速迭代；

② 查询性能高，通过数据冗余降低查询的复杂度。

主要的劣势表现在：

① 通过降低规范化、尽可能多的冗余维度信息在一张“大宽表”之中，使整个模型臃肿，当遇到不断变化的业务时，数据的维护成本大；

② 由于数据的大量冗余，如何保证数据一致性也是一个问题，无疑增加了模型的管理成本。

因此，从整体来说维度建模的开发和使用成本较低，但是维护成本较高，比较适合在接近业务分析的数据集市层、分析层来使用。

2、关系数据模型

关系数据模型的基本假设是数据仓库的需求会发生变化，因此关系模型设计所要求的高度抽象、独立性，在面对频繁变化时体现出了其优势。另外，关系数据模型所遵循的三范式在减少数据冗余方面有天然优势，在数据量不断膨胀增长的背景下，规范化的数据模型对于降低不必要的数据存储十分有意义。

关系模型在OLAP应用中，主要存在2大问题：

① 关系数据模型对数仓建模者的视野有较高要求，需要对企业的业务系统和架构充分理解，因此模型构建在学习成本方面有一定的劣势。

② 对于分析型需求来说，关系模型需要进行大量的关联、查询的性能问题也很凸显。

因此，关系模型在OLAP建设体系中更适合基础数据层的建设，目的是将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理。

ER模型在实践中最典型的代表是 Teradata 公司基于金融业务发布的 FS-LDM (Financial Services Logical Data Model)，它通过对金融业务的高度抽象和总结，将金融业务划分为10大主题，企业基于此模型做适当调整和扩展就能快速落地实施。

3、Data Vault 数据模型

Data Vault 是ER模型的衍生，设计的出发点是为了实现数据整合，但不能直接用于数据分析决策，它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合 ，同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。 Data Vault 模型由以下几部分组成。

• Hub:是企业的核心业务实体，由实体key、数据仓库序列代理键、装载时间、数据来源组成。

• Link:代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述 1:1、 l:n 和 n:n 的关系，而不需要做任何变更。它由 Hub的代理键、装载时间、数据来源组成。

• Satellite:是Hub的详细描述内容，一个Hub可以有多个Satellite。它由 Hub 的代理键、装载时间、来源类型、详细的Hub描述信息组成。

优势：① 保留数据来源与装载时间的信息，保证数据的历史性与数据源系统的可追溯。

② 模型设计结合3NF及维度模型的理念，其灵活性、可扩展性、一致性更好满足企业数仓要求。

劣势：① 对于数据开发工作者的模型设计要求更高，需把握不同模块的设计思路并形成统一的方法论。

② 模型更高的解耦程度会提高业务分析的使用开发成本，需要不断加强企业内部对于的模型认知。

Data Vault 模型在灵活性、可扩展性以及降低数据冗余方面展现出了一定的优势，但是查询成本较高，理论上来看这是一种适用于企业级数据仓库或数据中台的建模方式，Data Vault模型比ER模型更容易设计和产出，它的ET加工可实现配置化。

4、Anchor 数据模型

Anchor模型的提出者认为数据仓库需要提供稳定性高且具有一致性的服务，但是面对外部业务环境不断变化的矛盾，数仓的维护将变得十分复杂且耗时，为了应对这些变化和挑战，数据模型的设计必须具备模块化、灵活性、可追溯历史的特性。

Anchor数据模型是对 Data Vault 数据模型的进一步标准化，将模型规范到 6NF 的抽象程度，这样高度规范化的模型其优势和劣势变得更加凸显。

优势：① 模型的扩展机制保障了其变更管理的健壮性与灵活性，能够达到高度可扩展性。

② 6NF 的规范化程度使得模型以k-v 的结构存储数据，数据的冗余性得到极大的降低。

劣势：① 获取极大扩展性的同时，统计分析的查询需求便会存在大量的关联多表操作，计算性能方面有所影响。

② 模型的复杂度较高，对于元数据管理及后续的数据治理带来更大的挑战。

③ 过度的规范化对于模型设计者、使用者来说提高了门槛。

Anchor 模型具有极大的可扩展性与复用度，按照这种方式建设数仓后能够大大降低模型的维护成本，这种模型通常适用于基础明细层的设计，但是这种高度规范化的建模方法对于建模者的要求也是难以衡量的，因此在企业数仓中很少展开实际应用。

三、外部经验-阿里数据模型

阿里的数据仓库建设经历了多个发展阶段。

第一个阶段 : 完全应用驱动的时代，构建在Oracle/mysql上，以满足报表需求为目的，将数据以与源结构相同的方式同步到 Oracle (称作ODS 层)，基于ODS数据进行统计，基本没有系统化的模型方法体系，完全基于Oracle/mysql数据库特性进行数据存储和加工，部分采用一些维度建模的缓慢变化维方式进行历史数据处理，这时候的数据架构只有两层，即ODS+DSS。

第二个阶段 : 随着业务的快速发展，数据量也在飞速增长，开始尝试工程领域比较流行的ER模型+维度模型方式，构建出一个四层的模型架构，即ODL (操作数据层) +BDL (基础数据层) +IDL (接口数据层) +ADL(应用数据层)。 ODL和源系统保持一致 : BDL引入ER模型，加强数据的整合，构建一致的基础数据模型， IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装。

第三个阶段 :阿里的业务和数据飞速发展，自主研发的分布式计算平台MaxCompute发布，开始建设自己的第三代模型架构，选择了以维度建模为核心理念的模型方法论，同时对其进行了一定的升级和扩展，构建了阿里的公共层模型数据架构体系。

1、体系架构

1.1 模型架构：

阿里公共层建设的指导方法是一套统一的集团数据整合及管理的方法体系(在内部这一体系称为“OneData”)，以OneModel统一数据构建及管理方法论为主干，OneID核心商业要素资产化为核心，oneService提供统一数据接入和数据查询服务。

其包括一致性的指标定义体系 、模型设计方法体系以及配套工具，把表数据模型分为三层 :操作数据层( ODS)、公共维度模型层( CDM )和 应用数据层( ADS)， 其中公共维度模型层包括明细数据层( DWD )和汇总数据层( DWS )。

• 数据引入层（ODS，Operational Data Store，又称数据基础层）：将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。
• 数据公共层（CDM，Common Dimenions Model）：CDM层细分为维度层（DIM）、明细数据层（DWD）和汇总数据层（DWS），存放明细事实数据、维表数据及公共指标汇总数据。其中，明细事实数据、维表数据一般根据ODS层数据加工生成，公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
  • 维度层（DIM，Dimension）：基于雪花模型以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，建立一致的数据分析维表。
  • 明细数据层（DWD，Data Warehouse Detail）：以业务过程作为建模驱动，基于每个业务过程特点构建最细粒度的明细事实表。可以结合企业的数据使用特点，将维度退化至事实表中，减少事实表和维表的关联 ，提高明细数据表的易用性，即宽表化处理。
  • 汇总数据层（DWS，Data Warehouse Summary）：以分析主题对象作为建模驱动，基于上层应用和产品指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，建立汇总宽表、明细事实表。
• 数据应用层（ADS，Application Data Store）：存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。

1.2 体系架构：

OneModel方法论是以维度建模为理论基础，构建总线矩阵，划分和定义业务板块、数据域、业务过程、维度、度量/原子指标、业务限定、时间周期、派生指标，设计出维度表、明细事实表、汇总事实表的过程。

业务板块：由于阿里生态庞大，根据业务的属性划分出了几个相对独立的业务板块，业务板块之间的指标或业务重叠性较小。如电商业务板块涵盖淘系、 B2B系和AliExpress系等。

规范定义：结合行业的数据仓库建设经验和阿里数据自身特点，设计出的一套数据规范命名体系，规范定义将会被用在模型设计中。

模型设计：以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实，同时在落地表模型时，基于阿里自身业务特点， 设计出一套表规范命名体系。

2、规范定义

规范定义指以维度建模作为理论基础 ， 构建总线矩阵，划分和定义数据域、业务过程、维度、度量 / 原子指标、修饰类型、修饰词、时间周期、派生指标。

3、指标体系

OneModel的一个核心内容是派生指标的构建方法，派生指标由原子指标、时间周期、业务限定、统计粒度统一定义。

4 实施过程

4.1 指导方针

首先，在建设数据仓库时，要进行充分的业务调研和需求分析，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功；其次，进行数据总体架构设计，主要是根据数据域对数据进行划分，按照维度建模理论，构建总线矩阵、抽象出业务过程和维度；再次，对报表需求进行抽象整理出相关指标体系，依据工具完成指标规范定义和模型设计；最后，就是代码研发和运维。

4.2. 实施工作流

4.2.1 数据调研

• 业务调研

数据仓库的建设是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样会面临着这个问题，所以构建大数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点 ，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。在数仓建设项目启动前，可以请相关的业务人员介绍具体的业务，以便明确各个团队的分析、运营人员的需求。可以详细了解以下信息：

1. 组织架构和分工界面。各个部门对数仓的需求不同，需要对不同部门分别进行调研（例如，数据分析、运营、维护部门）。
2. 整体业务架构，各个业务模块之间的联系与信息流动的流程，梳理出整体的业务数据框架。
3. 各个已有的业务系统的主要功能及获取的数据。

以电商业务为例，公司的电商业务板块分为招商、供应链、营销、服务四个板块，梳理出各业务板块的需求数据框架如下图所示。

此外，还需要进一步了解各业务板块中已有的业务流程，业务流程通常与业务板块紧密耦合，对应一个或多个表及其所属数据源，可以作为构建数仓的原始数据来源。

• 需求调研

在未考虑数据分析师、业务运营人员数据需求的情况下，单纯根据业务调研建设的数据仓库，可能可用性较差。完成业务调研后，需要进一步收集数据使用者的需求，进而对需求进行深度思考和分析，并改进数据仓库。

需求分析的途径有两种：

• 通过与分析师、业务运营人员的沟通获知需求。
• 对报表系统中现有的报表进行研究分析。

4.2.2 架构设计

数据域划分

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、退款。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。例如：零售事业群的业务行态分两大块，线上自营电商和线下商超，所涉及的主要业务流程有：

构建总线矩阵

在进行充分的业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情 :明确每个数据域下有哪些业务过程;业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

4.2.3 规范定义

规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。

4.2.4 模型设计

模型设计主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。