阿里巴巴大数据之路-数据整合&管理体系

数据整合&管理体系

OneData

OneData 即是阿里巴巴内部进行数据整合及管理的方法体系和工 具。阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享 的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致 性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助这 一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共 层，并可以帮助相似的大数据项目快速落地实现。下面重点介绍 OneData 体系和实施方法论。

概述

阿里巴巴集团大数据建设方法论的核心是 ：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复 建设。

定位及价值

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

体系架构

• 架构体系图

• 业务板块

  • 根据业务的属性 划分出几个相对独立的业务板块，业务板块之间的指标或业务重叠性较小。如电商业务板块涵盖淘系、 B2B 系和 AliExpress 系等。

• 规范定义

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

• 模型设计

  • 以维度建模理论为基础，基于维度建模总线架构，构建 一致性的维度和事实（进行规范定义）。

规范定义

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

规范定义实例图

名词术语

• 数据域

  • 指面向业务分析，将业务过程或者维度进行抽象的集合。 其中 ， 业务过程可以概括为一个个不可拆分的行为事件， 在业务过程之下， 可以定义指标； 维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的， 但不轻易变动。 在划分数据域时， 既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展 新的数据域

• 业务过程

  • 指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程 是一个不可拆分的行为事件， 通俗地讲，业务过程就是企业活动中的事件

• 时间周期

  • 用来明确数据统计的时间范用或者时间点，如最近 30 天、自然周、截至当日等

• 修饰类型

  • 是对修饰词的一种抽象划分。 修饰类型从属于某个业务域，如日志域的访问终端 类型涵盖无线端、PC 端等修饰词

• 修饰词

  • 指除了统计维度以外指标的业务场景限定抽象。 修饰词隶属于一种修饰类型，如 在日志域的访问终端类型下， 有修饰词 PC 端、无线端等

• 度量/原子指标

  • 原子指标和度自含义相同，基于某一业务TjJ件行为下的度盟，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额

• 维度

  • 维度是度盟的环境，用来反映业务的一类属性， 这类属性的集合构成一个维度，也可以称为实体对象。 维度属于一个数据域，如地理维度（其中包挤罔家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）

• 维度属性

  • 维度属性隶属于一个维度， 如地理维度里面的国家名称、同家 ID、省份名称等，都属于维度属性

• 派生指标

  • 派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期。 可以理解为对原子指标业务统计范罔的圈定。 如原子指标： 支付金额，最近 l 天海外买家支付金额则为派生指标（最近 l 天为时间周期， 海外为修饰词， 买家作为维度，而不作为修饰词）

指标体系

• 本文在讲述指标时，会涵盖其组成体系（原子指标、派生指标、修 饰类型、修饰词、时间周期），将它们作为一个整体来解读。

• 基本原则

  • 组成体系之间的关系

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

  

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

  • 命名约定

    • 命名所用术语

      • 指标命名，尽量使用英文简写，其次是英文， 当 指标英文名太长时，可考虑用汉语拼音首字母命名。如中国质造， 用 zgzc。在 OneData 工具中维护着常用的名词术语，以用来进行命名。

    • 业务过程

      • 英文名：用英文或英文的缩写或者中文拼音简写；中文名：具体的业务过程中文即可

        关于存量型指标对应的业务过程的约定：实体对象 英文名 ＋＿stock。如在线会员数、 一星会员数等 ，其对应的业务过程为 mbr_stock； 在线商品数、商品 SKU 种类小于 5 的商品数，其对应的业 务过程为 itm_stock。

        

    • 原子指标

      • 英文名 ：动作＋度量：中文名：动作＋度量。原子指标 必须挂靠在某个业务过程下

    • 修饰词

      • 只有时间周期才会有英文名，且长度为 2 位，加上“一” 为 3 位，例如一ld。其他修饰词无英文名。

        • 最近 1天、1d
        • 最近 3 天、3d
        • 最近 7 天、1w
        • 最近 14 天、2w
        • 最近 30 天、1m
        • 最近 180 天、6m
        • 180 天以前、bh
        • 自然周、cw
        • 自然月、cm
        • 自然季度、cq
        • 截至当日、td
        • 年初截至当日、sd
        • 零点截至当前、tt
        • 财年、fy
        • 最近 1 小时、1h
        • 准实时、ts
        • 未来 7 天、flw
        • 未来 4 周、f4w

    • 派生指标

      • 英文名 ： 原子指标英文名＋时间周期修饰词（ 3 位， 例如＿Id) ＋序号（4 位，例如_001 ）；中文名：时间周期修饰词 ＋［其他修饰词］＋原子指标。

        为了控制派生指标的英文名称过长，在英文名的理解和规范上做了 取舍，所有修饰词的含义都纳入了序号中。序号是根据原子指标＋派生 指标自增的。

  • 算法

    • 原子指标、修饰词、派生指标的算法说明必须让各种使用人员看得明白

    • 算法概述

      • 算法对应的用户容易理解的阐述。

    • 举例

      • 通过具体例子帮助理解指标算法。

    • SQL 算法说明

      • 对于派生指标给出 SQL 的写法或者伪代码。

• 操作细则

  • 派生指标的种类

    派生指标可以分为三类 ： 事务型指标、存量型指标和复合型指标。 按照其特性不同，有些必须新建原子指标，有些可以在其他类型原子指 标的基础上增加修饰词形成派生指标。

    • 事务型指标 ： 是指对业务活动进行衡量的指标。

      • 例如新发商品数、 重发商品数、新增注册会员数、订单支付金额，这类指标需维护 原子指标及修饰词，在此基础上创建派生指标。

    • 存量型指标：是指对实体对象（如商品、会员）某些状态的统计。

      • 例如商品总数、注册会员总数，这类指标需维护原子指标及修饰 词，在此基础上创建派生指标，对应的时间周期一般为“历史截至当前某个时间”。

    • 复合型指标：是在事务型指标和存量型指标的基础上复合而成的。

      • 例如浏览 UV－下单买家数转化率， 有些需要创建新原子指标， 有些则可以在事务型或存量型原子指标的基础上增加修饰词得到派生指标。

  • 复合型指标的规则

    • 比率型

      • 创建原子指标，如 CTR、浏览 UV－下单买家数转化率、 满意率等。例如，“最近1天店铺首页 CTR”，原子指标为“CTR”，时间周期为“最近1 天”，修饰类型为“页面类型”，修饰词为“店 铺首页”。

    • 比例型

      • 创建原子指标，如百分比、占 比。例如“最近 1 天无线 支付金额占比”，原子指标为“支付金额占比”，修饰类型为“终 端类型”，修饰词为“无线”。

    • 变化量型

      • 不创建原子指标，增加修饰词，在此基础上创建派生指标。例如，“最近 1 天订单支付金额上1 天变化量”，原子指标 为“订单支付金额”，时间周期为“最近 1 天”，修饰类型为“统 计方法”，修饰词为“上 1天变化量”。

    • 变化率型

      • 创建原子指标。例如，“最近 7 天海外买家支付金额 上 7 天变化率”，原子指标为“支付金额变化率”，修饰类型为“买 家地域”，修饰词为“海外买家”。

    • 统计型 （均值、分位数等）

      • 不创建原子指标，增加修饰词，在此基础上创建派生指标；在修饰类型 “统计方法”下增加修饰词， 如人均、日均、行业平均、商品平均、90 分位数、70 分位数等。例如，“自然月日均 UV”，原子指标为“UV”，修饰类型为“统 计方法”，修饰词为“日均”。

    • 排名型

      • 创建原子指标， 一般为 top_xxx_xxx，有时会同时选择 rank 和 top_xxx _xxx组合使用。创建派生指标时选择对应的修饰

      • 创建派生指标时选择对应的修饰词

        • 统计方法（如降序、升序）。
        • 排名名次（如 TOPIO）。
        • 排名范围（如行业、省份、一级来源等）。
        • 根据什么排序（如搜索次数、 PV）。

    • 对象集合型

      • 主要是指数据产品和应用需要展现数据时，将一些 对象以 k-v 对的方式存储在一个字段中，方便前端展现。比如趋势图、TOP 排名对象等。其定义方式是，创建原子指标， 一般为 xxx 串；

      • 创建派生指标时选择对应的修饰词

        • 统计方法（如降序、升序）。
        • 排名名次（如 TOPIO）。
        • 排名范围（如行业、区域）。

  • 其他规则

    • 上下层级派生指标同时存在时

      • 如最近1天支付金额和最近1天 PC 端支付金额，建议使用前者，把 PC 端作为维度属性存放在物理表中体现。

    • 父子关系原子指标存在时

      • 当父子关系原子指标存在时，派生指标使用子原子指标创建派生指 标。如 PV、IPV （商品详情页PV ），当统计商品详情页 PV 时，优先选择子原子指标。

模型设计

指导理论

• 可参考 Star Schema-The Complete Reference 和 The Data Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。
• 数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

模型层次

• 操作数据层（ODS）：把操作系统数据几乎无处理地存放在数据仓 库系统中。

  • 同步：结构化数据增量或全量同步到 MaxCompute。
  • 结构化：非结构化（日志）结构化处理并存储至MaxCompute。
  • 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。

• 公共维度模型层（CDM）：存放明细事实数据、维表数据及公共指标汇总数据

  CDM 层又细分为 DWD 层和 DWS 层，分别是明细数据层和汇总数 据层，采用维度模型方法作为理论基础 ，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联 ，提高明细数据表的 易用性 ：同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

  • 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据 扫描。
  • 公共指标统一加工：基于 OneData 体系构建命名规范、口径一致 和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标;建立逻辑汇总宽表。
  • 建立一致性维度：建立一致的数据分析维表，降低数据计算口径、 算法不统一的风险。

• 应用数据层（ ADS）：存放数据产品个性化的统计指标数据，根据 CDM 层与 ODS 层加工生成。

  • 个性化指标加工：不公用性、复杂性（指数型、比值型、排名型 指标）。
  • 基于应用的数据组装 ： 大宽表集市、横表转纵表、趋势指标串。
    

基本原则

• 高内聚和低耦合

  • 业务特性

    • 将业务相近或者相关、粒度相同的数据设计为一个 逻辑或者物理模型；

  • 访问特性

    • 将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

• 核心模型与扩展模型分离

  • 核心模型

    • 包括的宇段支持常用的核心业务

  • 扩展模型

    • 包括的字段支持个性化或少量应用的需要

      • 不能让扩展模型的字段过度侵人核心模型
      • 以免破坏核心模型的架构简洁性与可维护性。

• 公共处理逻辑下沉及单一

  • 越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现
  • 不要让公用的处理逻辑暴露给应用层实现
  • 不要让公共逻辑多处同时存在

• 成本与性能平衡

  • 适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

• 数据可回滚

  • 处理逻辑不变，在不同时间多次运行数据结果确定不变。

• 一致性

  • 具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。

• 命名清晰、可理解

  • 表命名需清晰、一致，表名需易于消费者理解和使用。

模型实施

业界常用的模型实施过程

• Kimball 模型实施过程

  Kimball 维度建模主要探讨需求分析、高层模型、详细模型和模型 审查整个过程。 构建维度模型一般要经历三个阶段：第一个阶段是高层设计时期 ， 定义业务过程维度模型的范围，提供每种星形模式的技术和功能描述； 第二个阶段是详细模型设计时期，对每个星形模型添加属性和度量信 息；第三个阶段是进行模型的审查、再设计和验证等工作，第四个阶段 是产生详细设计文档，提交 ETL 设计和开发。

  • 高层模型

    • 高层模型设计阶段的直接产出目标是创建高层维度模型图，它是对业务过程中的维表和事实表的图形描述。确定维表创建初始属性列表，为每个事实表创建提议度量。

  • 详细模型

    • 详细的维度建模过程是为高层模型填补缺失的信息，解决设计问题，并不断测试模型能否满足业务需求，确保模型的完备性。确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填人模型的初步业务规则。

  • 模型审查、再设计和验证

    • 本阶段主要召集相关人员进行模型的审查和验证，根据审查结果对详细维度进行再设计。

  • 提交 ETL 设计和开发

    • 最后，完成模型详细设计文档，提交 ETL 开发人员，进入 ETL 设计和开发阶段，由 ETL 人员完成物理模型的设计和开发。

• Inmon 模型实施过程

  • Inmon 对数据模型的定位是：扮演着通往数据仓库其他部分的智能路线图的角色。由于数据仓库的建设不是一蹦而就的，为了协调不同人 员的工作以及适应不同类型的用户，非常有必要建立一个路线图一数据模型，描述数据仓库各部分是如何结合在一起的。

  • 模型层次划分

    • ERD (Entity Relationship Diagram，实体关系图）层

      • 最高层，该层描述了公司业务中的实体或主题域以及它们之间的关系；

    • DIS (Data Item Set， 数据项集）层

      • 中间层，该层描述了数据模型中的关键字、属性以及细节数据之间的关系；

    • 物理层（ Physical Model ，物理模型）

      • 物理层是数据建模的最底层 ，该层描述了数据模型的物理特性。

  • 螺旋式开发

    • 采用迭代方式完成多次需求
    • 采用统一的ERD模型

• 其他模型实施过程

  • 业务建模

    • 生成业务模型，主要解决业务层面的分解和程序化。

  • 领域建模

    • 生成领域模型，主要是对业务模型进行抽象处理， 生成领域概念模型。

  • 逻辑建模

    • 生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

  • 物理建模

    • 生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题。

OneData 实施过程

• 指导方针

  • 充分的业务调研和需求分析
  • 数据总体架构设计，主要是根据数据域对数据进行划分
  • 按照维度建模理论，构建总线矩阵、抽象 出业务过程和维度。
  • 对报表需求进行抽象整理出相关指标体系，使用 OneData 工具完成指标规范定义和模型设计。
  • 代码研发和运维。

• 实施工作流

  • 数据调研

    • 业务调研

      • 了解各个业务领域、业务线的业务有什么共同点和
        不同点 ，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。

    • 需求调研

      • 一是根据与分析师、业务运营人员的沟通 （邮件、 IM）获知需求
      • 二是对报表系统中现有的报表进行研究分析。

  • 架构设计

    • 数据域划分

      • 面向业务分析，将业务过程或者维度进行抽象的集合。

    • 构建总线矩阵

      • 明确每个数据域下有哪些业务过程
      • 业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

  • 规范定义

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

  • 模型设计

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

  • 总结

    • 一个高度迭代和动态的过程
    • 一般采用螺旋式实施方法
    • 总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。
    • 在架构设计、规范定义和模型设计等模型实施过程中， 都会引人评审机制，以确保模型实施过程的正确性。

• 在整个数据整合和管理体系里面，核心的宗旨就会规范化，标准化数据模型与输出。数据指标、字段词根、数据层级的统一定义与模板化输出是核心，做好数据输出的管理。

• 其次就是数据流与数据模型的处理，抽象业务实体化，数据模块化。做好这两部分，基本可以说清数据来源，业务逻辑，数仓输出。

• 更多的还是要贴合业务，实际建模与管理。