【读书笔记】《大数据大创新：阿里巴巴云上数据中台之道》

今天开始阅读《大数据大创新：阿里巴巴云上数据中台之道》，对数据中台的建设非常感兴趣，也是我日后的求职方向，冲鸭！

大数据发展价值

• 数据量飞速增长

从TB到PB用了20年，从PB跃升至ZB仅用了不到10年，IDC等权威机构的预算，全球数据量以每年40%左右的速度持续增长，2020年全球数据量将达到40ZB。
用“4V”来总结大数据的核心特征——volumn（大量），Variety（多样），velocity（快速），value（价值密度低）
数据量在增长，数据结构的复杂性也在增长，伴随着大数据概念的发展，数据领域的研究在广度和深度上得到了拓展：从早期与硬件制造相关的数据中心备份及网络管理等单一的领域分类，拓展到如今平台化及场景化的数据仓库、元数据管理、主数据管理、数据质量、数据泄露、数据科学等多元的领域分类。

云上中台建设

1.云上数据中台的业务模式

数据中台处于计算后台和业务前台之间，其内核能力是以业务视角而非技术视角智能化构建数据、管理数据资产，并提供数据调用、数据监控、数据分析和数据展示等多种服务。
承技术后台，启业务前台。基于数据，深入业务。
主要方法论：OneData、OneEntity、OneService
OneData：致力于实现数据的标准和统一，让数据成为资本而非成本
OneEntity：致力于实现实体统一，让数据融通而非以孤岛的形式存在
OneService：致力于实现数据服务统一，让数据复用而不是复制

2.阿里数据中台建设过程

问题所在：

（1）业务上的困扰
从数据标准方面引发的数据信任问题
从数据服务方面引发的数据及时性和有效性问题
例如，UV（Unique Visitor）这个常用指标因为业务规划、商业要求等不同会产生多种不同的统计规则。如淘系业务，在PC端UV的统计规则有三套，即三个同名但是不同计算逻辑的UV，无线端的UC又不同于PC，会衍生出多个UV。除了UV，还有GMV、转换率等指标，这些指标的不统一会给业务带来困扰，不合理的消耗其背后的数据资源。
数据部门光是提供业务支持已经够呛了，导致缺乏全局的规划，服务的效果不足，从而导致及时性和有效性不强。

（2）技术上的不合理消耗
阿里巴巴从电商起步，本身就是海量数据的玩家。如果缺乏统一高效的管理，将浪费大量的技术资源。
因此有一定抽象的数据仓库中间层模型能环节业务变化对数据模型的冲击；数据规范定义能有效避免数据的重复计算和存储，降低甚至消除业务人员的困惑；合理的数据生命周期管理能避免数据计算特别是数据存储的浪费。

实际落地：

（1）第一阶段，完成全局架构

（2）第二阶段，抓关键业务的数据建设

方向1：7个离线数据公共层（ODS数据基础层，DWD+DWS数据中间层）建设子项目，包括淘系数据基础层治理，日志数据公共层建设，小微金服依赖淘系数据重构，聚划算数据中间层建设，搜索数据中间层建设，航旅数据中间层建设以及1688数据公共层与数据应用建设。
方向2：3个离线数据公共层面向应用的建设（ADS数据应用层+报表+产品）子项目，第一个方向专注于建设离线数据公共层，而应用才是直接目的。
方向3：1个数据技术领域专项
（数据模型，存储治理，数据质量，安全权限，平台运维和研发工具6大数据技术领域）
方向4：1个技术探索专项（实时数据公共层建设专项）

（3）第三阶段，全面铺开
计划包括：元数据打通，天猫数据中间层建设，数据资产管理平台，基于元数据的数据建模工具，OneData体系全流程工具化，数据公共层运营

3.从零散的数据到统一的数据

一开始是烟囱式的开发，即数据中心基于单个项目建设，特点是烟囱式的垂直体系结构，每一个系统都有自己的存储和IT设备，以及独立的管理工具和数据库，不同的系统不能共享资源，不能交互访问，形成了资源孤岛和信息孤岛，导致出现了效率低和技术资源的浪费。

例如常见的GMV指标就会存在多种指标和定义，例如“最近1天的下单金额”，“最近1天的支付金额”，“最近7天的支付金额”，“最近30天支付宝确认收货额”等，业务人员看到的都是GMV，但是由于是不同的数据团队的产出，所以定义的含义也是不一样的。且不同的ETL开发团队由于信息不畅为保证数据的真实性更愿意“相信自己”，由此都基于ODS基础数据层的数据去做从零向上开始的烟囱式开发。
造成业务痛点和技术痛点的原因，概括起来就是“烟囱式”开发造成的数据不标准和不规范。所以云上数据中台的切入点就是以“阿里巴巴数据公共层建设”消除因“烟囱式”开发给业务带来的困扰和造成的技术上的浪费。

（1）数据仓库规划和数据规范定义
OneData方法论是解决上述问题的指导思想。如何实现？
首先，我们需要基于业务和数据的理解，对数据进行基于业务本身但是超越和脱离业务需求限制的抽象。即抽象出业务板块，如“电商”，“金融”，“云业务”等，在业务模块之下再抽象出数据域，比如电商下会有“交易”，“会员”，“商品”，“浏览”，“搜索”，“广告”，“公共”等不以团队为中心转移的数据域，再在数据域下抽象出业务过程，如对于“交易”数据域，可抽象出“加入购物车”，“下单”，“支付”，“确认收货”，“申请退款”等业务过程和“订单”维度，“买家”维度和“卖家”维度等。
其次，在抽象出的业务流程过程和维度进一步定义，包括定义原子指标，定义业务限定，定义计算周期，定义计算粒度。

最后，基于原子指标，业务限定，计算周期，计算粒度可以结构化定义出派生指标，如“最近30天天猫支付宝支付订单金额”，如果需要““最近7天天猫支付宝支付订单金额”只需要改下计算周期便可以快读定义。

（2）数据模型设计
第一步：统一ODS数据基础层
第二步：基于业务应用或者需求来源端抽象数据域治理，特别关注核心业务模型，通过DWD明细数据中间层处理预join处理、DWS汇总数据中间层沉淀常用统计维度和复用性高的指标，再结合数据技术本身的热度分析和数据应用预估，丰富和完善数据中间层数据建设
第三步：从数据层向上整合ADS数据应用层数据