《大数据之路：阿里巴巴大数据实践》第二篇数据模型篇-读书笔记

E .F .Codd是关系数据库的鼻祖，他首次提出了数据库系统的关系模型，开创了数据库关系方法和关系数据理论的研究。随着一大批大型关系数据库商业软件（如Oracle、Informix、DB2等）的兴起，现代企业信息系统几乎都使用关系数据库来存储、加工和处理数据。数据仓库系统也不例外，大量的数据仓库系统依托强大的关系数据库能力存储和处理数据，其采用的数据模型方法也是基于关系数据库理论的。虽然近年来大数据的存储和计算基础设施在分布式方面有了飞速的发展，NoSQL技术也曾流行一时，但是不管是Hadoop、Spark还是阿里巴巴集团的MaxCompute系统，仍然在大规模使用SQL进行数据的加工和处理，仍然在用Table存储数据，仍然在使用关系理论描述数据之间的关系，只是在大数据领域，基于其数据存取的特点在关系数据模型的范式上有了不同的选择而已。关于范式的详细说明和定义，以及其他一些关系数据库的理论是大数据领域建模的基础，有兴趣的读者可以参考相关的经典数据库理论书籍，如《数据库系统概念》。

8.3 从OLTP和OLAP系统的区别看模型方法论的选择

OLTP系统通常面向的主要数据操作是随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题；而OLAP系统面向的主要数据操作是批量读写，事务处理中的一致性不是OLAP所关注的，其主要关注数据的整合，以及在一次性的复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法。

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

8.4.1 ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计一个3NF模型，用实体关系（Entity Relationship，ER）模型描述企业业务，在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点：

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

采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。

其建模步骤分为三个阶段。

高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
中层模型：在高层模型的基础上，细化主题的数据项。
物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

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

金融业务划分为10大主题：当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道

8.4.2 维度模型

维度模型是数据仓库领域的Ralph Kimball大师所倡导的，他的（The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling）是数据仓库工程领域最流行的数据仓库建模的经典。

维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤。

选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
选择事实。确定分析需要衡量的指标。

8.4.3 Data Vault模型

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

Hub：是企业的核心业务实体，由实体key、数据仓库序列代理键、装载时间、数据来源组成。
Link：代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述1:1、1:n和n:n的关系，而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。
Satellite：是Hub的详细描述内容，一个Hub可以有多个Satellite。它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。

Data Vault模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。通过Dan Linstedt的比喻更能理解。Data Vault的核心思想：Hub可以想象成人的骨架，那么Link就是连接骨架的韧带，而Satellite就是骨架上面的血肉。看如下实例（来自Data Vault Modeling Guide，作者Hans Hultgren），如下图所示。

8.4.4 Anchor模型

Anchor对Data Vault模型做了进一步规范化处理，Lars. Rönnbäck的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了k-v结构化模型。我们看一下Anchor模型的组成。

Anchors：类似于Data Vault的Hub，代表业务实体，且只有主键。
Attributes：功能类似于Data Vault的Satellite，但是它更加规范化，将其全部k-v结构化，一个表只有一个Anchors的属性描述。
Ties：就是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力。
Knots：代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。

在上述四个基本对象的基础上，又可以细划分为历史的和非历史的，其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。

Anchor模型的创建者以此方式来获取极大的可扩展性，但是也会增加非常多的查询join操作。创建者的观点是，数据仓库中的分析查询只是基于一小部分字段进行的，类似于列存储结构，可以大大减少数据扫描，从而对查询性能影响较小。一些有数据表裁剪（Table Elimination）特性的数据库如MariaDB的出现，还会大量减少join操作。但是实际情况是不是如此，还有待商榷。下面是一个Anchor模型图（来自Anchor Modeling-Agile Information Modeling in Evolving Data Environments，作者Lars. Rönnbäck），如下图所示。

8.5 阿里巴巴数据模型实践综述

阿里巴巴集团很早就已经把大数据作为其战略目标实施，而且其各个业务也非常依赖数据支撑运营，那么阿里巴巴究竟采取何种方法构建自己的数据仓库模型呢？阿里巴巴的数据仓库模型建设经历了多个发展阶段。

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

第二个阶段：随着阿里巴巴业务的快速发展，数据量也在飞速增长，性能成为一个较大的问题，因此引入了当时MPP架构体系的Greenplum，同时阿里巴巴的数据团队也在着手进行一定的数据架构优化，希望通过一些模型技术改变烟囱式的开发模型，消除一些冗余，提升数据的一致性。来自传统行业的数据仓库工程师开始尝试将工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团，构建出一个四层的模型架构，即ODL（操作数据层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL和源系统保持一致；BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型；IDL基于维度模型方法构建集市层；ADL完成应用的个性化和基于展现需求的数据组装。在此期间，我们在构建ER模型时遇到了比较大的困难和挑战，互联网业务的快速发展、人员的快速变化、业务知识功底的不够全面，导致ER模型设计迟迟不能产出。至此，我们也得到了一个经验：在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。

第三个阶段：阿里巴巴集团的业务和数据还在飞速发展，这时候迎来了以Hadoop为代表的分布式存储计算平台的快速发展，同时阿里巴巴集团自主研发的分布式计算平台MaxCompute也在紧锣密鼓地进行着。我们在拥抱分布式计算平台的同时，也开始建设自己的第三代模型架构，这时候需要找到既适合阿里巴巴集团业务发展，又能充分利用分布式计算平台能力的数据模型方式。我们选择了以Kimball的维度建模为核心理念的模型方法论，同时对其进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。

数据公共层建设的目的是着力解决数据存储和计算的共享问题。阿里巴巴集团当下已经发展为多个BU，各个业务产生庞大的数据，并且数据每年以近2.5倍的速度在增长，数据的增长远远超过业务的增长，带来的成本开销也是非常令人担忧的。

阿里巴巴数据公共层建设的指导方法是一套统一化的集团数据整合及管理的方法体系（在内部这一体系称为“OneData”），其包括一致性的指标定义体系、模型设计方法体系以及配套工具。

9.阿里巴巴数据整合及管理体系

OneData即是阿里巴巴内部进行数据整合及管理的方法体系和工具。

阿里巴巴大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面独特优势。借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层。

9.1 概述

9.1.1 阿里巴巴的大数据建设方法论的核心是

从业务架构到模型设计；
从数据研发到数据服务；
数据可管理
数据可追溯；
数据避免重复建设；
产品化；

9.1.2 定义及价值

数据公共层建设

建设统一的、规范化的数据接入层（ODS）和数据中间层（DWD和DWS），通过数据服务和数据产品，完成服务于阿里巴巴的大数据系统建设；
标准化（Standard）；
共享的（Shared）；
数据服务（Service）；
降低数据互通成本；
释放计算；
降低存储；
解放人力；
节省资源；
消除业务/技术痛点；

体系结构

业务板块：根据业务的属性划分出几个相对独立的业务板块，业务板块之间的指标或者业务重叠性较小。如电商业务板块涵盖淘系、B2B系和AliExpress系等；
规范定义：由于业务庞大，结合行业的数据仓库建设经验和阿里数据自身特点，设计出的一套数据规范命名体系，规范定义将会被用在模型设计中；
模型设计：以维度建模的理论为基础，基于维度建模总线架构，构建一致性的维度和事实（进行规范定义）。同时，在落地表模型时，基于阿里自身业务特点，设计出一套表规范命名体系

9.2 规范定义

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

9.2.1 名词术语

9.2.2 指标体系

指标分类

原子指标
派生指标
修饰类型
修饰词
时间周期

9.2.3 基本原则

（1）组成体系之间的关系

派生指标由原子指标、时间周期修饰词、若干其他修饰词组合得到；

原子指标、修饰类型、修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域；
派生指标可以选择多个修饰词，修饰词之间的关系为”或“或者”且“，有具体的派生指标语义决定；
派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关；
一般而言，事务型指标和存量型指标（见下文定义）只会唯一定位到一个业务过程，如果遇到同时有两个行为发生、需要多个修饰词、生活才呢个一个派生指标的情况，则选择时间靠后的行为创建原子指标，选择时间靠前的行为创建修饰词；
原子指标有英文字段名、数据类型和算法说明；
派生指标继承原子指标的英文名、数据类型和算法要求；

（2）命名约定

命名所用术语。指标名称，尽量使用英文简写，其次是英文，当指标英文名太长时，可以考虑使用汉语拼音首字母命名，如中国制造，用zgzz。在OneData工具中维护着常用的名词术语，用来进行命名；
业务过程。英文名：用英文或者英文的缩写或者中文拼音简写；中文名：具体的业务过程中问即可；

关于存量型指标（见下文定义）对应的业务过程的约定：实体对象英文名 + _stock。如在线会员数、一星会员数等，其对应的业务过程为mbr_stock；在线商品数、上坡 inSKU种类小于5的商品数，其对应的业务过层为itm_stock。
原子指标。英文名：动作 + 度量；中文名：动作 + 度量。原子指标必须挂靠在某个业务过程下：

修饰词。只有时间周期才会有英文名，且长度为2位，加上“_”为3位，例如_1d。其他修饰词无英文名。
如下图为时间周期常用修饰词

派生指标。英文名：原子指标英文名 + 时间周期修饰词（3位，例如_1d） + 序号（4位，例如_001）；中文名：时间周期修饰词 +【其他修饰词】+ 原子指标；
在OneData工具中，英文名与中文名都会由OneData工具自动生成

（3）算法

原子指标、修饰词、派生指标的算法说明必须让各种使用人员看的明白，包括：
算法概述 - 算法对应的用户容易理解的阐述；

操作细则

（1）派生指标的种类

事务型指标：是指对业务活动进行衡量的指标。例如新发商品数、重发商品数、新增注册会员数、订单支付金额、这种指标需要维护原子指标以及修饰词，自此基础上创建派生指标；
存量型指标：是指对实体对象（例如商品、会员）某些状态的统计。例如商品总数、注册会员总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间为周期一般为“历史截至当前某个时间”；
复合型指标：是在事务型指标和存量型指标的基础上符合而成的。例如浏览UV-下单买家数转化率，有些需要创建新原子指标，有些则可以在事务型或者存量型原子指标的基础上增加修饰得倒派生指标；

（2）复合型指标的规则

比率型：创建原子指标，如CTR、浏览UV-下单买家数转化率满意率等。例如“最近1天店铺首页CTR”，原子指标为“CTR”，时间周期为“最近一体那”，修饰类型为“页面类型”，修饰词为“店铺首页”。
比例型：创建原子指标，如百分比、占比。例如”最近1天无线支付金额占比“，原子指标为”支付金额占比“，修饰类型为”终端类型“，修饰词为“无线”；
变化量型：不创建原子指标，增加修饰词，在此基础上创建派生指标。例如，“最近1天订单支付金额上1天变化量”，原子指标为“订单支付金额”，时间周期为“最近1天”，修饰类型为“统计方法”，修饰词为“上1天变化量”；
变化率型：创建原子指标。例如，“最近7天海外买家支付金额上7天变化率”，原子指标为“支付金额变化率”，修饰类型为“买家地域”，修饰词为“海外买家”；
统计型（均值、分位数等）：不创建原子指标，增加修饰词，在此基础上创建派生指标；在修饰类型“统计方法”下增加修饰词，如人均、日均、行业平均、商品平均、90分位数、70分位数等。例如，“自然月日均UV”，原子指标为“UV”，修饰类型为“统计方法”，修饰词为“日均”。
排名型：创建原子指标，一般为top_xxx_xxx，有时会同时选择rank和top_xxx_xxx组合使用。创建派生指标时选择对应的修饰词如下：
统计方法（降序、升序）；
- 排名名次（Top 10）;
- 排名范围（如行业、省份、一级来源等）；
- 根据什么排名（如搜索次数，PV）；