阿里数据中台建模

    阿里中台的概念，可以说是近些年来的颇为火爆的概念。从十余年前的阿里在内部完成这一过程，并提出了“中台”概念；到后面中台概念逐步被外部接受并在2019年爆火兴起。数据中台爆火背后，既有传统企业转型焦虑的市场东风，又有阿里中台战略示范效应的推波助澜。下图为阿里中台架构（图片来自网络），其内置“大中台、小前台”的战略，其中包含了业务中台和数据中台的双中台配置。

    从本质上来说，中台概念更多是一种方法论。它来告诉用户如何构建数据化服务体系，包括从数据集成、数据建模、数据开发、数据共享到数据质量、数据治理等。用户可以阿里云或其他中台产品去快速构建，也完全可以自主完成这一过程。本文就尝试从数据建模为切入点，描述如何完成这一过程。文中部分内容来自《阿里中台》一书和阿里云官网文档。

1. 数据建模概述

1).建模意义

• 性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐。

• 成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。

• 效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。

• 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

2).模型方法论 - OLTP vs OLAP

• OLTP系统面向的主要数据操作是随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题

• OLAP系统面向的主要数据操作是批量读写，事务处理中的一致性不是OLAP所关注的，其主要关注数据的整合，以及在一次性的复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法。

3).数仓建模方法论

• ER模型

  其建模本质是是从全企业的高度设计一个3NF模型，用实体关系（ER）模型描述企业业务，在范式理论上符合3NF。

3NF - OLAP vs OLTP

OLAP中的3NF与OLTP系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。

建模步骤

1. 高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。

2. 中层模型：在高层模型的基础上，细化主题的数据项。

3. 物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

• 维度模型

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

建模步骤

1. 选择业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。

2. 选择粒度。在事件分析中，要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。

3. 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。

4. 选择事实。确定分析需要衡量的指标。

 

2. 维度建模规范

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

1).概念层次

 

 

 

2).概念解读

• 业务板块

  业务板块是逻辑空间的定义，是基于业务特征划分的命名空间

• 数据域

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

• 业务过程

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

• 时间周期

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

• 修饰类型

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

• 修饰词

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

• 度量/原子指标

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

• 维度

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

• 维度属性

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

• 派生指标

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

3).指标体系（指标组成体系之间关系）

• 原子指标

  原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。

• 派生指标

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

2. 派生指标唯一归属一个原子指标 ，继承原子指标的数据域， 与修饰词的数据域无关。

3. 派生指标可以选择多个修饰词，修饰词之间的关系为"或"或者"且"，由具体的派生指标语义决定。

4. 派生指标要继承原子指标的英文名、数据类型和算法要求。

 

3. 维度模型设计

 

1).模型架构图

 

• 操作数据层（ODS）

  把操作系统数据几乎无处理地存放在数据仓库系统中。

1. 同步：结构化数据增量或全量同步到底层存储。

2. 结构化：非结构化（日志）结构化处理并存储至底层存储。

3. 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。

• 公共维度模型层（CDM）

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

1. 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。

2. 公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表。

3. 建立一致性维度：建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。

• 应用数据层（ADS）

  存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。

 

 

 

4. 模型实施过程

1).数据调研

• 业务调研

  要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。业务调研是否充分，将会直接决定数据仓库建设是否成功 。

• 需求调研

  需求调研的途径有两种：一是根据与分析师、业务运营人员的沟通（邮件、IM）获知需求；二是对报表系统中现有的报表进行研究分析。通过需求调研分析后，就清楚数据要做成什么样的。很多时候，都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据，这两者并没有严格的先后顺序。

2).架构设计

• 数据域划分

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

• 构建总线矩阵

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

3).规范定义

规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。上面也做了详细说明，此处不做展开。

4).模型定义

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

• 维度设计

  维度是维度建模的基础和灵魂。在维度建模中，将度量称为"事实"，将环境描述为"维度"，维度是用于分析事实所需要的多样环境。维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。维度的作用一般是查询约束、分类汇总以及排序等。

  维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。正如Kimball所说的，数据仓库的能力直接与维度属性的质量和深度成正比。设计步骤：

1. 第一步：选择维度或新建维度

   作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有一个维度定义。

2. 第二步：确定主维表

   此处的主维表一般是ODS表，直接与业务系统同步。

3. 第三步：确定相关维表

   数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性

4. 第四步：确定维度属性

   主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。

• 事实表设计

  事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。

1. 粒度

   事实表中一条记录所表达的业务细节程度被称为粒度。

2. 事实类型

   作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。

   * 可加性事实，是指可以按照与事实表关联的任意维度进行汇总。

   * 半可加性事实，只能按照特定维度汇总，不能对所有维度汇总，比如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加起来则毫无意义。

   * 不可加性事实，还有一种度量完全不具备可加性，比如比率型事实。对于不可加性事实可分解为可加的组件来实现聚集。

3. 事实表类型

* 事务事实表

    用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为"原子事实表"。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不能更改，其更新方式为增量更新。

* 周期快照事实表

    以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。周期快照事实表的日期维度通常记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值或状态度量。事实表的数据一旦插入就不能更改，其更新方式为增量更新。

* 累积快照事实表

    用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，而且这类事实表在数据加载完成后，可以对其数据进行更新，来补充业务状态变更时的日期信息和事实。

 

5. 数据展示层设计

    数据展示层，是需要根据用户个性化需求来设计。在稳固的底层模型的支持下，上层展示层更为强调灵活组合，快速响应用户前端交互。经常采用的是“大宽表”的设计，避免关联，加速显示。

1).示例：宽表

2).示例：数据可视化

• 图中的类别、子类别是层次维度的体现。

• 图中的销售额合计，是派生指标的体现。