什么是OneData？阿里数据中台实施方法论解读

一、前言

大家好，我是云祁。

好久不见，前面分享过 数据仓库常见建模方法与大数据领域建模实例，今天再和大家聊聊数据中台，聊聊中台具体的实施交付过程以及非常重要的OneData理论。

很早前，就有多位数据圈的大佬，写过这数据中台以及OneData相关的理论，见解颇深。我这里就站在巨人的肩旁上，聊聊自己的体悟，如有不妥之处，还请各位看官留言斧正。

二、什么是数据中台？

带着对 “阿里中台到底拆没拆” 的疑问 ，我们不妨先来探讨一下中台到底是啥？ 😮

早期业界对于 “数据中台” 一直没有明确的定义，但是作为理工直男，我们可以把中台理解是一种中间层。

而中间层，它便承担了一个非常重要的特性 解耦！

从上图我们不难看出，2014年前阿里的每一块业务都会有对应的ETL开发团队为其提供数据支持，而每个ETL开发团队都会按照自己的思路建设自己的数据体系。这就造成了：

• 数据流向会乱，缺乏方向性；
• 数据管理式无序的，处于失控状态；
• 浪费研发人力和计算存储资源，也不能很好业务的需求；

通过这样烟囱式的开发，造成了集团内极大的业务困扰和技术浪费。

而阿里早期提出“数据中台”的概念，目的就是为了应对多业务部门千变万化的数据需求。既要满足业务部门日常性的多个业务前台的数据需求，又要满足像双11、618这样的业务高峰。

发展到现在，数据中台俨然通过 “方法论+组织+工具” 成为阿里云上实现数据智能的最佳实践。

如下图所示：

三、什么是 OneData 体系?

官方的解释是：

阿里云OneData数据中台解决方案基于大数据存储和计算平台为载体，以OneModel统一数据构建及管理方法论为主干，OneID核心商业要素资产化为核心，实现全域链接、标签萃取、立体画像，以数据资产管理为皮，数据应用服务为枝叶的松耦性整体解决方案。其数据服务理念根植于心，强调业务模式，在推进数字化转型中实现价值。

数据中台到如今的建设成果主要体现在两方面：一个是数据的技术能力，另一个是数据的资产。

今天阿里的各个业务都在共享同一套数据技术和资产。阿里内部为这个统一化的数据体系命名为 “OneData”。OneData又主要抽象成三个部分，分别是：OneID、OneModel、OneService。

• 第一部分：OneModel 致力于实现数据的标准与统一；
• 第二部分：OneID 致力于实现实体的统一，让数据融通而非以孤岛存在，为精准的用户画像提供基础；
• 第三部分：OneService 致力于实现数据服务统一，让数据复用而非复制。

在架构图中，我们看到最下面的内容主要是数据采集和接入，按照业态接入数据（比如淘宝、天猫、盒马等），把这些数据抽取到计算平台。通过OneData体系，以 **“业务板块+分析维度”**为架构去构建“公共数据中心”。

基于公共数据中心在上层根据业务需求进行建设：消费者数据体系、企业数据体系、内容数据体系等。

经过深度加工后，数据就可以发挥其价值被产品、业务所用；最后通过统一的数据服务中间件“OneService”提供统一数据服务。

三、OneData 方法论切入点

《大数据之路：阿里巴巴大数据实践》一书中详细讲了OneData方法论，具体实施起来还是需要从数据架构方法、数据模型的设计方法以及数据标准化几方面入手。

数据架构方法（全局化规划数据体系）：

• 数据域划分 -> 数据总线矩阵构建 -> 数据分层规划
• 实现企业数据的全局观规划设计

数据模型设计方法（好用且复用）：

• 维度 -> 事实 -> 公共汇总
• 面向数据分析场景构建数据模型，让通用计算沉淀，数据复用，提升效能。

数据标准化方法（计算口径&表达统一）：

• 派生指标 = 原子指标 + 业务限定 + 统计周期 + 统计粒度
• 实现数据标准化定义，计算口径统一，保障数据质量

四、OneData 实施流程

首先，在数据中台实施过程时，要进行充分的业务调研和需求分析。这是中台建设的基石，业务调研和需求分析做得是否充分直接决定了数据中台建设是否成功。

其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。

再次，对报表、大屏需求进行抽象整理出相关指标体系，使用OneData数据智能智能构建与管理平台，完成指标规范定义和模型设计。

最后，就是代码研发和运维。

4.1 项目调研

按照业务需求调研+数据调研+业务系统调研+环境调研的思路开展。

这个阶段主要注意避免对用户需求的错误理解；对网络情况不了解，影响数据上云；对业务系统的摸排不全面，导致后期模型和效果无法达到。

4.2 架构设计

数据域的划分

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。

其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义相关指标；维度则是指度量的环境，如买家下单事件，买家就是维度。

为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。

在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。

数据域	描述
会员域	注册用户信息、用户注册事件，积分，登录
互动域	回复，顶，评论，发帖
交易域	订单，交易
仓储域	库存
门店域	门店信息
公共及自定义	公共维度信息

构建总线矩阵

在进行充分的业务调研和需求调研后，就要着手构建总线矩阵了。

在这一步我们需要做两件事情：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

4.3 规范定义

规范定义主要定义指标体系，包括原子指标、业务限定、统计周期、派生指标。

时间周期

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

业务限定

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

度量 / 原子指标

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

维度

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

派生指标

派生指标 = 一个原子指标+多个业务限定（可选）+时间周期。 可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近一天海外买家支付金额则为派生指标

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

派生指标的种类

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

4.4 模型设计

数据模型的维度设计主要还是以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

操作数据层（ODS）

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

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

公共维度模型层（CDM）

存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。

CDM层又细分为DWD层和DWS层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性。

同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。其主要功能如下：

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

应用数据层（ADS）

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

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

4.5 总结

OneData的实施过程是一个高度迭代和动态的过程，一般采用螺旋式实施方法。在总体架构设计完成后，开始根据数据域进行迭代示模型设计和评审。

在架构设计、规范定义和模型设计等模型实施过程中，都会引入评审机制，以确保模型实施过程的正确性。

五、写在最后

在今年五月底，2021阿里云峰会上，阿里云智能总裁张建锋表示 2021 年有四个词非常关键，分别是：做深基础、做厚中台、做强生态、做好服务。

“中台包括中间件、数据库、操作系统、大数据平台等，中台是未来的“云”能不能得到进一步快速发展的核心”。

“拆中台也好”，“做厚中台”也罢，经过这两年和数据中台打交道，我觉得中台本质上，就是“中心化的能力复用平台”，诚如开篇时提到的，它承担着“解耦”的使命。

如果有人说：我有个数据中台，你用了之后可以提高你企业的信息孤岛，提高企业的效率，那肯定是个骗子。

数据中台的构建不是不是一蹴而就的，不论大企业，还是小企业，都需要从小的业务场景开始不断累积，需要长时间的业务经验的沉淀，不断的进行优化创新，最终才能构建出具有自己企业业务特色的数据中台。