读书笔记——阿里数据中台(第二篇：OneData体系1)
今天来介绍数据中台的第二篇，第二篇共分为三个大部分分别对应的是阿里的数据中台三大体系(阿里的数据中台体系架构见上一篇)，OneData体系，OneEntity体系，OneService体系，三大体系相辅相成、相互依赖，OneData体系为基础。这次我们把OneData体系分为两部分介绍，因为OneData体系包括数据模型设计和数据资产管理两部分，今天我们介绍OneData的数据模型篇章。
1. 烟囱式开发带来的困扰和资源浪费
阿里的数据中台治理主要是在2014年开始的，在2014年以前，阿里的大数据建设处于烟囱式开发状态，这样的开发带来了许多业务的困扰和资源的浪费，2014数据依赖如下图
2014年阿里数据团队的任务依赖关系图.png
由图可见
- 数据流向会乱，无方向性的
- 数据管理式无序的，处于失控状态
- 除了浪费研发人力和计算存储资源、也必然满足不了业务的需求
当然，这个问题被放大式在本身业务以极快的速度发展的前提下，这样的开发导致的问题我们从两个方面来看
业务困扰
在混乱的开发中，会造成诸多的数据问题，如因为指标的定义问题，导致同一指标有多个数据，最常见的指标为UV,总结最业务的困扰主要一下三点
- 数据统一：数据标准规范难（命名不规范、口径不统一、算法不一致），数据任务响应慢，从而导致业务部门产生困扰而导致不满
- 数据未打通：各个数据团队各自为政，存在严重的数据孤岛现状；缺乏数据融通，数据价值发掘不够，从而导致业务部门看不清数据
- 成为成本中心且服务化不足：数据无方向性，依赖混乱，，数据管理无序，失控，成本化严重，面向应用的服务化投入不足甚至缺失。
技术困扰
浪费主要分两方面看，一方面是开发人力技术的浪费，开发人员日常在数据异常排查和数据调研上疲于奔命。另外一个是计算存储资源的浪费，在没有公共层的情况下，数据重复存储和计算非常常见。简单的总结为一下的三点
- 研发苦恼：烟囱式开发周期长、效率低
- 维护困难:源系统乎或业务变成不能及时反应到数据上，加之数据不标准，不规范，上线难，下线更难。
- 时效性差：重复建设导致任务链路冗长、任务繁多，计算资源紧张；数据批量计算慢，时效性不强且覆盖 业务范围窄，即时查询返回结果慢
2. 数据公公层建设
从上面的问题来看，数据的公共层建设是一件迫在眉睫的事情，那么数据公共层建设到底该如何进行，建设之前又要如何准备。
这里就是OneData体系建设数据建设篇，OneData体系的主要四个组成部分为
- 规范化数据建模：规范化数据建模，特别关注数据规范定义、数据模型设计和ETL开发等全流程
- 规范化研发工具：用来落地和承载规范化建模的工具
- 数据模型数据小库：规范化数据建模产生的所有分层数据模型的数据被统一存放在数据小库中
- 面向应用的数据监控：所有的数据在面向应用是都会被监控和调用，且对上线、下线调优监控则会反馈到规范化数据建模中。
四个部分的运行图如下
OneData体系开发的执行过程.png
从四部分看，首先应该是执行数据建模规范，其中包括数据规范定义、数据模型设计、ETL开发规范。各个规范都有对应的规范文件输出。
数据规范设计精华.png
在OneDataIII体系体系中，升级了原有的体系，讲数据规范定义，数据模型设计，ETL开发连在一起，时间设计即开发，所建即所得。即将数据规范定义从工具层面的数据命名+结构化抽象定义合二而一，与数据模型设计连接，进而直接影响ETL.
也就数说数据规范定义完成之后，每一个指标都可以根据结构化明明规则和计算逻辑快速相应到对应的物理上存在的数据表中。
因此在理论上，只要某个指标能够被规范定义（除非复杂到无法被规范定义的指标），而一系列经过规范定义的指标则会根据相同的计算粒度，汇集到若干物理上存在的表中或者逻辑上存在的表中，这样生成的物理表或者逻辑表，其代码都可以自动化生成。而中间生成过程则不必关心，因为这是系统内部的只能黑盒要以智能化的方式来解决的。并且从长远来看，只能黑盒不仅要实现代码自动化生成，还要关注自动化生成代码机器任务调度所对应的计算逻辑，特别是从全局来看，这些计算逻辑能不能胜于人工做法，甚至胜于人工做法
具体的OneData体系的方法论，包含三个关键点分别是数据仓库规划、数据规范定义、数据模型设计，这里我们不介绍技术细节，后面技术细节在《大数据之路：阿里大数据实践》一书中会重点讲述。
1. 数据仓库规划和数据规范定义
数据规范定义是与需求分析和产品设计同时进行的工作，数据规范定义是在开发之前，以业务的视角进行数据统一和标准定义，确保计算的口径一致，算法一致，甚至命名是规范且统一的，后续的数据模型设计和ETL开发都是在此基础上进行的
那么数据规范定义到底是如何实现的呢
指标规范实例.jpg
- 抽象出业务板块 我们基于对业务和数据的理解，对数据进行基于业务的抽象，这种抽象要求不会随着业务团队的组织架构变动而变动。例如阿里的除了公共板块外还会划分出如电商，金融，云业务等板块。
- 抽象出数据域 在业务板块下面由抽象出数据域，以电商业务板块为例，可以抽象出交易、会员、商店、浏览、搜搜、广告、公共、等不以团队转移的数据区域。
- 抽象出数业务过程 在数据域下又抽象出业务过程，例如对于交易的数据域，可以抽象出加入购物车、下单、支付、确认收货、申请退款等。
-
抽象出维度 也可以在数据与下抽象出维度，订单维度、买家维度、卖家维度、在会员数据域下抽象出会员维度等
那么下面我们可以基于业务过程和维度，可以进一步定义一下 - 原子指标 例如 支付的业务过程中可以定义 '支付订单金额'、'支付买家数'等原子指标，原子子表自带算法，可解读的中英文命名，数据类型等，并会被后续的派生指标继承；
- 定义业务限定：在支付业务过程中可以定义业务限定，即最终计算派生指标的一些限制条件，入支付方式是支付宝、银联等
- 定义计算周期：计算周期是一个非常特殊的业务限定条件，例如最近1天、最近7天、最近30天，几乎所有的最终面向业务的数据都有计算周期这个限制条件，因此其不属于任何一个数据域下的任何一个业务过程，需要独立定义
- 定义计算粒度：关于维度，如BU维度，下会定义出很多维度属性，同时也会产生一些计算粒度
指标名词释义.jpg
最后基于原子指标，计算周期、业务限定、计算粒度可以结构化定义出派生指标，并以继承原子指标的数据类型、算法、以及可以解读的中英文命名为主，结合计算周期，业务限定和计算粒度的算法，中英文命名形成派生指标的算法，中英文命名。假派生指标是 最近30天天猫支付支付宝支付订单金额，则原子指标是 订单支付金额，计算周期是最近30天，业务限定是支付宝支付，计算粒度是天猫。如果钉钉最近7天天猫支付宝支付订单金额，则只需要用同样的方法将最近30天调整为最近7天即可快速定义。如果此时存在指标命名一样但结构不同，或者命名不同但结构相同，则系统会校验并给出错误提示。
2. 数据模型设计
经典的数据模型有很多理论和实战指导，但是阿里在结合自身的业务做了改进和突破
首先，数据设计模型是建立在数据规范定义的基础上，这就从业务应用或者需求来源空值了数据模型设计的重要输入源头，其次，对数据迷行严格分层，在统一数据公共层的同事允许数据应用层百花齐放，第三 从业务和技术双视角出发，严格遵循数据模型设计的高内聚低耦合的六项技术要求
模型架构图.jpg
19数据建模原则.png
1. 高内聚低耦合
主要是指从数据业务特性和访问特性两个角度来考虑，将业务相近或者相关的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放在一起，将低概率同时访问的数据分开存储。
2. 核心模型和拓展模型分离
建立核心模型和拓展模型体系，核心模型包括子弹支持常用的核心业务，拓展模型包括字段支持个性化和少量应用的需要，不能让拓展模型的字段过度入侵到核心模型，以免破坏核心迷行的架构简洁性和可维护性
3. 公共逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调用依赖的底层进行封装与实现，不要让公共逻辑暴露在应用层实现，不要让公共逻辑多出同时存在。
4. 成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不以过度冗余与数据复制
5.数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变
6.一致性
具有相同含义的字段在不同的表中命名必须相同，必须使用规范定义的名称
7.表名清晰可理解
表名需要清晰，一直，表名易与消费者理解和使用
实施过程工作流.jpg
最后增加模型架构的流程图，不做过多解释，欢迎点赞订阅，多多支持！
附上上篇的数据中台整体架构链接，了解整体架构可以查看上篇文章
