大数据之路读书笔记-09阿里巴巴数据整合及管理体系

大数据之路读书笔记-09阿里巴巴数据整合及管理体系

面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性， 直是大数据系统建设不断追求的方向。
OneData 即是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统 、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似的大数据项目快速落地实现。下面重点介绍OneData 体系和实施方法论。

---

9.1 概述

阿里巴巴集团大数据建设方法论的核心 ：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理 、可追溯、可规避重复建设。目前，阿里巴巴集团数据公共层团队已把这套方法论沉淀为产品，以帮助数据 PD 、数据模型师和 ETL 工程师建设阿里的大数据。这一体系包含方法论以及相关产品。

9.1.1 定位及价值

建设统一的、规范化的数据接人层（ ODS ）和数据中间层（ DWD和DWS ），通过数据服务和数据产品，完成服务于阿里巴巴的大数据系统建设 ，即数据公共层建设。提供标准化的（ Standard ）、共享的（ Shared ）、数据服务（ Service ）能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛。

9.1.2 体系架构

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

9.2 规范定义

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

9.2.1 名词术语

名词术语解释如表 9.1 示。

名词术语	解释
数据域	指面向业务分析，将业务过程或者维度进行抽象的集合。其中 业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域
业务过程	指企业的业务活动事件，如下单、支付、退款都是业务过程 请注意，业务过程是一个不可拆分的行为事件 通俗地讲，业务过程就是企业活动中的事件
时间周期	用来明确数据统计的时间范用或者时间点，如最近 30 天、自然周、截至当日等
修饰类型	是对修饰词的一种抽象划分 修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC端等修饰词
修饰词	指除了统计维度以外指标的业务场景限定抽象 修饰词隶属于一种修饰类型，如在日志域的访问终端类型下 有修饰词 PC 端、无线端等
度量/原子指标	原子指标和度量自含义相同，基于某一业务 事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词 ，如支付金额
维度	维度是度量的环境，用来反映业务的一类属性 这类属性的集合构成一个维度也可以称为实体对象 维度属于一个数据域，如地理维度（其中包挤国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）
维度属性	维度属性隶属于一个维度 如地理维度里面的国家名称、国家 ID 、省份名称等都属于维度属性
派生指标	派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期 可以理解为对原子指标业务统计范围的圈定 如原子指标 支付金额，最近 1天海外买家支付金额则为派生指标（最近1天为时间周期 海外为修饰词 买家作为维度，而不作为修饰词）

9.2.2 指标体系

本文在讲述指标时，会涵盖其组成体系（原子指标、派生指标、修饰类型、修饰词、时间周期），将它们作为一个整体来解读。
1.基本原则
( l ）组成体系之间的关系
● 派生指标由原子指标、时间周期修饰词、若干其他修饰词组合得到（见图 9.3 ）。
● 原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。
● 派生指标可以选择多个修饰词，修饰词之间的关系为“或”或者“且”，由具体的派生指标语义决定。
● 派生指标唯一归属一个原子指标 ，继承原子指标的数据域， 与修饰词的数据域无关。
一般而言，事务型指标和存量型指标（见下文定义）只会唯一定位到一个业务过程，如果遇到同时有两个行为发生、需要多个修饰词、生成一个派生指标的情况，则选择时间靠后的行为创建原子指标，选择时间靠前的行为创建修饰词。
● 原子指标有确定的英文字段名、数据类型和算法说明：派生指标要继承原子指标的英文名、数据类型和算法要求。
(2 ）命名约定
● 命名所用术语。指标命名，尽量使用英文简写，其次是英文，指标英文名太长时，可考虑用汉语拼音首字母命名。如中国质造，zgzc 。在 OneData 工具中维护着常用的名词术语，以用来进行命名。
● 业务过程。英文名：用英文或英文的缩写或者中文拼音简写；中文名：具体的业务过程中文即可，如图 9.4 所示。
关于存量型指标（见下文定义）对应的业务过程的约定：实体对象英文名 stock 。如在线会员数、 一星会员数等 ，其对应的业务过程为mbr_stock1 在线商品数、商品 SKU 种类小于5的商品数，其对应的业务过程 itm_stock
● 原子指标。英文名 ：动作＋度量：中文名：动作＋度量。原子指标必须挂靠在某个业务过程下，如图 9.5 所示。
● 修饰词。只有时间周期才会有英文名，且长度为2位，加上“_”为3位，例如_ld 。其他修饰词无英文名。
阿里巴巴常用的时间周期修饰词如表9.2所示。
● 派生指标。英文名 原子指标英文名＋时间周期修饰词（3位，例如＿Id) ＋序号（4位，例如一001 ）；中文名：时间周期修饰词＋［其他修饰词］＋原子指标。
在OneData 工具中，英文名与中文名都会由 OneData 工具自动生成，如图 9.6 所示。
为了控制派生指标的英文名称过长，在英文名的理解和规范上做了取舍，所有修饰词的含义都纳入了序号中。序号是根据原子指标＋派生指标自增的。
(3 ）算法
原子指标、修饰词、派生指标的算法说明必须让各种使用人员看得明白，包括
● 算法概述一一算法对应的用户容易理解的阐述。
● 举例一一通过具体例子帮助理解指标算法。
● SQL 算法说明一一对于派生指标给出 SQL 的写法或者伪代码。
2.操作细则
( 1 ）派生指标的种类
派生指标可以分为 事务型指标、存量型指标和复合型指标。按照其特性不同，有些必须新建原子指标，有些可以在其他类型原子指标的基础上增加修饰词形成派生指标。
● 事务型指标 是指对业务活动进行衡量的指标。例如新发商品数、重发商品数、新增注册会员数、订单支付金额，这类指标需维护原子指标及修饰词，在此基础上创建派生指标。
● 存量型指标：是指对实体对象（如商品、会员）某些状态的统计。例如商品总数、注册会员总数，这类指标需维护原子指标及修饰词，在此基础上创建派生指标，对应的时间周期一般为“历史截至当前某个时间”。
● 复合型指标：是在事务型指标和存量型指标的基础上复合而成的。例如浏览 UV－下单买家数转化率，有些需要创建新原子指标，有些则可以在事务型或存量型原子指标的基础上增加修饰词得到派生指标。
(2 ）复合型指标的规则
● 比率型：创建原子指标，如CTR 、浏览 UV -下单买家数转化率、满意率等。例如，“最近一天店铺首页CTR”，原子指标为“ CTR”，时间周期为“最近1天”，修饰类型为“页面类型”，修饰词为“店铺首页”。
● 比例型 创建原子指标，如百分比 、占 比。例如“最近1天无线支付金额占比”，原子指标为“支付金额占比”，修饰类型为“终端类型”，修饰词为“无线”。
● 变化量型：不创建原子指标，增加修饰词，在此基础上创建派生指标。例如，“最近1天订单支付金额上 1天变化量”，原子指标为“订单支付金额”，时间周期为“最近1天”，修饰类型为“统计方法”，修饰词为“上1天变化量”。
● 变化率型：创建原子指标。例如，“最近7天海外买家支付金额7天变化率”，原子指标为“支付金额变化率”，修饰类型为“买家地域”，修饰词为“海外买家”。
● 统计型 （均值、分位数等）：不创建原子指标，增加修饰词，在此基础上创建派生指标；在修饰类型 “统计方法”下增加修饰词，如人均、日均、行业平均、商品平均 90 分位数 70 分位数等。
例如，“自然月日均 UV”，原子指标为“UV”，修饰类型为“统计方法”，修饰词为“日均”。
● 排名型 创建原子指标， 一般为 top_xxx xxx ，有时会同时选择rank top_xxx _xxx 组合使用。创建派生指标时选择对应的修饰词如下：
▷ 统计方法（如降序、升序）。
▷ 排名名次（如 TOP IO ）。
▷ 排名范围（如行业、省份、一级来源等）。
▷ 根据什么排序（如搜索次数、 PV ）。
示例如图9.7所示。
● 对象集合型：主要是指数据产品和应用需要展现数据时，将一些对象以 k-v 对的方式存储在一个字段中，方便前端展现。比如趋势图、 TOP 排名对象等。其定义方式是，创建原子指标，一般为xxx 串：创建派生指标时选择对应的修饰词如下：
▷ 统计方法（如降序、升序）。
▷ 排名名次（如 TOPIO）。
▷ 排名范围（如行业、区域）。
示例如图 9.8 示。
3.其他规则
( I ）上下层级派生指标同时存在时
如最近1天支付金额和最近 PC 端支付金额，建议使用前者，把PC 端作为维度属性存放在物理表中体现。
(2 ）父子关系原子指标存在时
当父子关系原子指标存在时，派生指标使用子原子指标创建派生指标。如 PV IPV （商品详情页 PV ），当统计商品详情页 PV 时，优先选择子原子指标。

9.3 模型设计

9.3.1 指导理论

阿里巴巴集团数据公共层设计理念遵循维度建模思想，可参考 StarSchern The Complete Reference The Dαtα Warehouse Toolkit-The lnitive Guide to Dimensional Modeling。数据模型的维度设计主要维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

9.3.2 模型层次

阿里巴巴的数据团队把表数据模型分为三层 ：操作数据层（ ODS ）、公共维度模型层（ DIM ）和应用数据层（ADS ）， 其中公共维度模型层包括明细数据层（ DWD ）和汇总数据层（ DWS ）。模型层次关系如图9.9 所示。
操作数据层（ ODS ）：把操作系统数据几乎无处理地存放在数据仓库系统中。
● 同步：结构化数据增量或全量同步到 MaxCompute
● 结构化：非结构化（日志）结构化处理并存储至 MaxCompute。
● 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。
公共维度模型层（ CDM ）：存放明细事实数据、维表数据及公共指标汇总数据 其中明细事实数据、维表数 一般根据 ODS 层数据加工生成 ：公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
CDM 层又细分为 DWD 层和 DWS 层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础 更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联 ，提高明细数据易用性 ：同时在汇总数据层， 加强指标的维度退化， 采取更多的宽表手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。其主要功能如下。

● 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。
● 公共指标统 加工：基于 OneData 体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标建立逻辑汇总宽表。
● 建立一致性维度：建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。
应用数据层（ ADS ）：存放数据产品个性化的统计指标数据，根据CDM层与 ODS 层加工生成
● 个性化指标加工：不公用性、复杂性（指数型、比值型、排名型指标）。
● 基于应用的数据组装 大宽表集市、横表转纵表、趋势指标串。
其模型架构如图 9.10 所示。阿里巴巴通过构建全域的公共层数据，极大地控制了数据规模的增长趋势，同时在整体的数据研发效率、成本节约、性能改进方面都有不错的效果。
数据调用服务优先使用公共维度模型层（ CDM ）数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要建设公用的公共层时，方可直接使用操作数据层（ ODS ）数据。应用数据层（ ADS)作为产品特有的个性化数据一般不对外提供数据服务，但是 ADS 作为被服务方也需要遵守这个约定。

9.3.3 基本原则

1 高内聚和低辑合
一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低藕合原则。主要从数据业务特性和访问特性两个角度来考虑 ：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型：将高概率同时访问的数据放一起 ，将低概率同时访问的数据分开存储。
2.核心模型与扩展模型分离
建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要 ，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
3. 公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
4. 成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
5.数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
6. 一致性
具有相同含义的字段在不同表中的命名必须相同，必须使用规范定
义中的名称。
7. 命名清晰、可理解
表命名需清晰、一致，表名需易于消费者理解和使用。

9.4 模型实施

如何从具体的需求或项目转换为可实施的解决方案，如何进行需求分析、架构设计、详细模型设计等，则是模型实施过程中讨论的内容。本节先简单介绍业界常用的模型实施过程，然后重点讲解阿里巴巴OneData 模型设计理论及实施过程。

9.4.1 业界常用的模型实施过程

1 . Kimball 模型实施过程
Kimball 维度建模主要探讨需求分析、高层模型、详细模型和模型审查整个过程。
构建维度模型一般要经历三个阶段：第一个阶段是高层设计时期，定义业务过程维度模型的范围，提供每种星形模式的技术和功能描述；第二个阶段是详细模型设计时期，对每个星形模型添加属性和度量信息；第三个阶段是进行模型的审查、再设计和验证等工作，第四个阶段是产生详细设计文档，提交 ETL 设计和开发。
( 1 ）高层模型
高层模型设计阶段的直接产出目标是创建高层维度模型图，它是对业务过程中的维表和事实表的图形描述。确定维表创建初始属性列表，为每个事实表创建提议度量。
(2 ）详细模型
详细的维度建模过程是为高层模型填补缺失的信息，解决设计问题，并不断测试模型能否满足业务需求，确保模型的完备性。确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填人模型的初步业务规则。
(3 ）模型审查、再设计和验证
本阶段主要召集相关人员进行模型的审查和验证，根据审查结果对详细维度进行再设计。
(4 ）提交 ETL 设计和开发
最后，完成模型详细设计文档，提交 TL 开发人员，进入ETL计和开发阶段，由 ETL 人员完成物理模型的设计和开发。
上述内容主要引用自 Ra lph Kimball 等的 The Data housLifecycle Toolkit ，具体细节请参考原著作。
2. Inmon 模型实施过程
Inmon 对数据模型的定位是：扮演着通往数据仓库其他部分的智能路线图的角色。由于数据仓库的建设不是一蹦而就的，为了协调不同人员的工作以及适应不同类型的用户，非常有必要建立一个路线图一一数据模型，描述数据仓库各部分是如何结合在一起的。
Inmon 将模型划分为三个层次，分别是 ERD (Entity Relationship Diagram ，实体关系图）层、 DIS (Data Item Set 数据项集）层和物理层（ Physical Model ，物理模型）。
ERD 层是数据模型的最高层，该层描述了公司业务中的实体或主题域以及它们之间的关系； ERD 层是中间层，该层描述了数据模型中的关键字、属性以及细节数据之间的关系；物理层是数据建模的最底层该层描述了数据模型的物理特性。
Inmon 对于构建数据仓库模型建议采用螺旋式开发方法，采用迭代方式完成多次需求。但需要采用统一的 ERD 模型，才能够将每次迭代的结果整合在一起。ERD 模型是高度抽象的数据模型，描述了企业完整的数据。而每次迭代则是完成 ERD 模型的子集，通过 DIS 和物理数据模型实现。
上述内容主要引用自 Inmo Building the Data rehouse 具体细节请参考原著作。
3.其他模型实施过程
在实践中经常会用到如下数据仓库模型层次的划分，和 Kimball Inmon 的模型实施理论有一定的相通性，但不涉及具体的模型表达。
● 业务建模，生成业务模型，主要解决业务层面的分解和程序化。
● 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
● 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
● 物理建模，生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题。

9.4.2 OneData 实施过程

本节重点讲解怎么使用 OneData 这套体系和相配套的工具实施数据系统的模型建设，在讲解中会以阿里巴巴的具体业务进行说明
1.指导方针
首先，在建设大数据数据仓库时，要进行充分的业务调研和需求分析。这是数据仓库建设的基石，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功。其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。再次，对报表需求进行抽象整理出相关指标体系，使用 OneData 工具完成指标规范定义和模型设计。最后，就是代码研发和运维。本文将会重点讲解物理模型设计之前（含）步骤的内容。
2. 实施工作流
实施工作流如图 9.1 所示。
(1 ）数据调研
● 业务调研
整个阿里集团涉及的业务涵盖电商、数字娱乐、导航（高德）、移动互联网服务等领域。各个领域又涵盖多个业务线，如电商领域就涵盖了C类（淘宝、天猫、天猫国际）与B类（阿里巴巴中文站、国际站速卖通）业务。数据仓库是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样面临着这个问题。所以要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点 ，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。业务调研是否充分，将会直接决定数据仓库建设是否成功

在阿里巴巴，一般各个业务领域独自建设数据仓库，业务领域内的业务线由于业务相似、业务相关性较大，进行统一集中建设。
如表 9.3 所示是粗粒度的C类电商业务调研，不难发现几个功能模块／业务线除了淘宝无供应链管理外，其他几乎一样。
● 需求调研
可以想象一下，在没有考虑分析师、业务运营人员的数据需求的情况下，根据业务调研建设的数据仓库无疑等于闭门造车。了解了业务统的业务后并不代表就可以进行实施了，此刻要做的就是收集数据使用者的需求，可以去找分析师、业务运营人员了解他们有什么数据诉求，此时更多的就是报表需求。
需求调研的途径有两种： 是根据与分析师、业务运营人员的沟通（邮件、 IM ）获知需求： 是对报表系统中现有的报表进行研究分析通过需求调研分析后，就清楚数据要做成什么样的。很多时候，都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据，这两者并没有严格的先后顺序。
举例 分析师需要了解大淘宝（淘宝、天猫、天猫国际）一级类目的成交金额。当获知这个需求后，我们要分析根据什么（维度）汇总，以及汇总什么（度量），这里类目是维度，金额是度量：明细数据和汇总数据应该怎样设计？这是一个公用的报表吗？是需要沉淀到汇总表里面，还是在报表工具中进行汇总？
(2 ）架构设计
● 数据域划分
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、退款。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。
如表 9.4 所示是功能模块／业务线的业务动作（部分示例）。
如表 9.5 所示是根据业务过程进行归纳，抽象出的数据域（部分示例）。
● 构建总线矩阵
在进行充分的业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情 ：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
如表 9.6 所示是供应链管理业务过程示例

(3 ）规范定义
规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。
(4 ）模型设计
模型设计主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。相关实践详解请参考后续章节。
(5 ）总结
OneData 的实施过程是一个高度迭代和动态的过程，一般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引人评审机制，以确保模型实施过程的正确性。