基础是标准化、规范化
建立数据仓库，面向主题的、集成的、相对稳定的、反映历史变化的数据集合，以支持管理决策decision making
大数据：大量volumn、多样variety、快速velocity、价值密度低value、准确性veracity、可视化visualization、合法性validity
多源数据、多样数据、提炼并应用数据价值
平台化及场景化的数据仓库、元数据管理、主数据管理、数据质量、数据泄漏、数据科学
云上数据中台致力于构建标准统一、融会贯通、资产化、服务化和闭环自优化的智能大数据体系
大数据应该是标准、规范、有序的
oneData、oneEntity、oneService
数据的标准与统一
实体统一
数据服务统一
（1）计算后台：实时计算、离线计算
（2）云上数据中台：全局数据仓库规划、数据规范定义、数据建模与研发、数据链接萃取、数据运维监控
采集尽可能丰富的数据源，清洗、结构化后形成垂直数据中心，包括淘宝、天猫、优酷。。。数据。即统一的ods数据基础层，
然后，进行数据研发建模，处理为不因业务特别是组织架构变动而轻易转移的数据中间层，包括明细数据中间层和汇总数据中间层，与数据基础层一起形成公共数据中心。包括电商、文娱、金融。。。等数据
更进一步，以业务单元、或以业务对象（人、货、场）纬度，计算出复用性强的统计指标，并增加到公共数据中心。再将各垂直孤岛的数据连接起来，并萃取不同于统计指标的精华数据，如行为标签、关系等，形成萃取数据中心。包括消费着数据体系、企业数据体系、商品数据体系和位置数据体系等。萃取数据中心的数据，根据数据模型的设计要求，存放在明细数据中间层、汇总数据中间层货ADS数据应用层。
所有数据都会进入“数据资产管理”工具型产品。
这样的价值实现过程就是面向应用提供服务及创新的主题式数据服务。
（3）业务前台
全局化数据监控、数据化运营、数据植入业务
数据产品 数据技术 方法论 场景价值实现
过程
一、数据公共层建设
1. 起初：面向每块业务，有自己的数据基础层、中间层、应用层，重复、数据不全，不统一
（1）业务困扰：
标准不统一：定义，字段名不统一，口径不统一，算法不一致；
开发（烟囱式），浪费技术资源，数据重复且不可信；
维护，复杂的引用关系导致任务不断增加 ---- 引发数据信任问题
数据服务：规划，缺乏全局规划，数据获取途径繁杂，服务化不足；开发，烟囱式，周期长，效率低，服务响应速度慢；
时效，重复建设导致任务链冗长、任务繁多，计算资源紧张
（2）技术上不合理消耗
认为：有一定抽象的数据仓库中间层模型能缓解业务变化对数据模型的冲击；数据规范能有效避免数据的重复存储、计算，降低业务人员困惑；合理的生命周期管理能避免数据计算、存储的浪费。只有建设统一、集中的数据仓库，才能避免重复建设bu级的数据体系。因此，构想并推出阿里巴巴数据公共层建设项目。
数据体系：数据公共层（数据基础层、数据中间层），数据应用层
数据体系之上，建设统一数据服务层
统一团队负责从业务中抽取源于业务但又不同于业务数据的数据域，主导加入数据中间层。允许部分业务按照onedata的标准和方法论建设数据体系。
该阶段初步完成数据公共层建设
OneData体系：即建立企业统一的数据公共层，从设计、开发、部署和使用上保障了数据口径的规范和统一，实现数据资产全链路管理，提供标准数据输出。该体系包含：数据规范定义体系、数据模型规范设计、ETL规范研发以及支撑整个体系从方法到实施的工具体系。以数据规范体系为例，不同于以往分部门的指标混乱定义做法，OneData体系中，我们将此前个性化的数据指标进行规范定义，抽象成：原子指标、时间周期、其他修饰词等三个要素，如下所示：例如，以往业务方提出的需求是：最近7天的成交。而实际上，这个指标在规范定义中，应该结构化分解成为：原子指标（支付订单金额） 修饰词-时间周期（最近7天） 修饰词-卖家类型（自营）。这样做的好处是指标口径复用性强，可以极大的精简复杂的指标体系，便于理解和使用。企业可借助工具来帮助规范数据开发过程，如阿里云或袋鼠云的数栈——大数据开发套件，来替代传统的人工经验 人工约定模式，从根本上解决数据指标口径一致，各种场景下看到的数据一致性得到保障。
OneData是阿里巴巴内部进行数据整合及管理的方法体系和工具。 阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享的全域数据提醒，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。
概述 阿里巴巴集团大数据建设方法论的核心是：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。
定位及价值 建设统一的、规范化的数据接入层(ODS)和数据中间层(DWD和DWS)，通过数据服务和数据产品，完成服务于阿里巴巴的大数据系统建设，即数据公共层建设。提供标准化的(Standard)、共享的(Shared)、数据服务(Service)能力，降低数据互通成本，释放计算、存储、人力等资源，以消愁业务和技术之痛。
体系架构图
2. 项目计划
3. 实施
前瞻性、可持续性、可扩展性
技术上：降低成本，提高效率。人力资源浪费
二、零散的数据到统一的数据
数据不统一：数据标准规范难（命名不规范、口径不统一、算法不一致），数据任务相应慢，导致业务部门困扰、不满
数据未打通：各数据团队各自为政，存在严重数据孤岛现象；数据缺乏融通，数据价值发掘不够，导致业务部门看不清数据
成本高且服务化不足：数据无方向性、依赖混乱，管理无序、失控，
人力资源浪费：大量临时取数据需求
造成以上业务痛点的原因，概括起来就是烟囱式开发造成的数据不标准、不规范。
oneData一方面致力于数据标准统一，另一方面追求让数据成为资产而非成本。Onedata2不仅有方法论，还有规范、工具型数据产品。具体包括：
规范化数据建模，特别关注数据规范定义，数据模型设计，和etl开发等全流程；
规范化数据建模的规范化研发工具落地；
规范化数据建模产生的所有分层数据模型及其数据被统一在数据小库中；
所有数据在面向应用时，都被监控和调优，且对上线、下线调优监控则会反馈到规范化数据建模中
Onedata体系关键的指导意义和执行点是，规范化数据建模，即数据规范定义、数据模型设计和etl开发
Ondata3
Ondata3继承：
在数据规范定义中，3体系继承了保障数据一致性的数据域、业务过程，以及在数据域、业务过程等之下的指标、实体属性等的结构化组装、命名和定义（包括计算规则、逻辑及算法）
数据模型设计中，继承了保障数据模型复用和稳定的数据基础层、数据中间层和数据应用层分层架构设计，以及各层模型设计的核心原则。
技术突破&方法论升级：
数据仓库规划从数据规范定义中提取出来，作为一个全局概念，强调“按需做规划，未来可扩展”
将原先割裂的数据规范定义、数据模型设计和etl开发连接在一起，以期实现“设计即开发，所建即所得”
系统层面统一规划与设计onedata、oneentity、oneservice三大体系，
OneData体系方法论
数据仓库规划及数据规范定义
数据字典可以缓解业务痛点，但是对技术痛点无用。
基于对业务和数据的理解，对数据进行基于业务本身但超越和脱离业务需求限制的抽象。不会随业务团队的组织架构变动而变动。对业务丰富度足够大的业务，抽象出业务板块，如电商、金融。进而抽象出数据域，如交易、会员、商品、浏览。对于交易数据域，可以抽象出加入购物车、支付等业务过程，抽出订单、买家等维度。
基于业务过程和维度，进一步定义原子指标如支付买家数；定义业务限定，如支付业务过程中，支付方式为支付宝、银联等。定义周期，如1天、7天。定义计算粒度。
最后，基于原子指标、业务限定、周期、计算粒度，可以结构化定义出派生指标。数据类型、算法、命名
数据模型设计
在数据模型设计中，最能体现数据模型设计之美和数据复用性的数据中间层[T1] 。
数据模型设计建立在数据规范定义的基础上。
Step 1，统一数据基础层，从团队组成、到权限控制，全部实现统一，确保数据从业务端生成后进入数据仓库时落地唯一性。
Step 2，基于数据来源或来源端抽象数据域治理，数据中间层沉淀常用指标和复用性高的指标，再结合数据技术本身的热度分析和数据应用预估，丰富和完善数据中间层建设。
Step 3，需求首先从数据中间层向上整合，不满足需求的，迅速完善数据中间层。特别个性化的需求，不适合放在中间层，才会在数据应用层加工。对数据中间层的每一次完善，都是一次积累。数据中间层像滚雪球一样，越滚越大。
三、成本中心到资产中心
梳理数据的“血缘”关系
存储治理 到 资源治理 再到 数据资产管理[T2]
资产应用全链路体系，全链路数据追踪，全链路“血缘”关系
提供应用分析产品：血缘关系、全链路保障、应用分析，roi报告
从孤岛到融通的数据
Oneentity 统一实体
GProfile 全域标签
GRelation 全域关系
GBehavior 全域行为
五 OneS ervice 授人以渔
简单整合Api治标不治本，必须从统一数据，统一服务两方面着手
Onedata致力于统一数据标准，让数据成为资产而非成本
Oneentity致力于统一实体，让数据融通，而非孤岛
Onservice致力于统一数据服务，让数据复用而非复制
云上数据中台产品化
云上数据中台定位于计算后台和业务前台之间，其内核能力是以业务视角出发，智能化构建数据，管理数据资产，并提供数据调用、监控、分析和展现等服务。
Dataphin：智能数据构建和管理产品
规范数据定义；设计即开发，分钟级生成代码；数据资产化管理，全链路数据追踪；主题式服务，简化查询分析
Quick bi：高效数据分析与展现
