- 阿里巴巴的数据处理经历了四个阶段，分别是：
- 数据库阶段，主要是OLTP（联机事务处理）的需求；
- 数据仓库阶段，OLAP（联机分析处理）成为主要需求；
- 数据平台阶段，主要解决BI和报表需求的技术问题；
- 数据中台阶段，通过系统来对接OLTP（事务处理）和OLAP（报表分析）的需求，强调数据业务化的能力。
第一个阶段是数据库阶段。
淘宝还只是一个简单的网站，淘宝的整个结构就是前端的一些页面，加上后端的DB（DataBase，数据库），只是个简单的OLTP系统，主要就是交易的事务处理。
这个阶段，互联网黄页才刚刚出现，数据来源大部分还是传统商业的ERP/CRM的结构化数据，数据量并不大，也就是GB的级别。简单的DB就能满足需求。
这里要说明的是，OLTP的交易场景和OLAP的分析场景区别在于，前者强调高并发、单条数据简单提取和展示（增删改查），后者对并发的要求不高，但是需要打通不同的数据库，比如ERP、CRM、行为数据等等，并且能够进行批量的数据处理，也就是通常说的低并发，大批量（批处理）、面向分析（query+计算，用于制作报表）。
随着淘宝用户超过100万，分析需求的比重就越来越大。淘宝需要知道它的交易来自于哪些地区，来自于哪些人，谁在买淘宝的东西等等，于是，就进入了数据处理的第二个阶段。
第二个阶段是数据仓库阶段。
正如前文所述，OLTP和OLAP对数据存储和计算的需求非常不一样，前者处理的是结构化的交易数据，而OLAP对应的是互联网数据，而互联网里面数据量最大的是网页日志，90%以上的数据都是点击（log）什么的非结构化的数据，而且数据量已经达到了TB的级别。
针对分析需求，就诞生了数据仓库（DW，DataWarehouse），用Oracle RAC搭建了阿里巴巴第一个DW，解决大量数据的存储和计算需求，也就是去把非结构化的数据转化成结构化数据，存储下来。
这个阶段，DW支持的主要就是BI和报表需求。数据库（DB）这时也在从传统DB转向分布式DB。主要原因是以前交易稳定，并发可控，传统DB能满足需求，但是后来随着交易量的增长，并发越来越不可控，对分布式DB的需求也就出来了。
随着数据量越来越大，从TB进入了PB级别，原来的技术架构越来越不能支持海量数据处理，这时候就进入了第三个阶段。
第三个阶段是数据平台阶段，这个阶段解决的还是BI和报表需求，但是主要是在解决底层的技术问题，也就是数据库架构设计的问题。
这在数据库技术领域被概括为「Shared Everything、Shared Nothing、或Shared Disk」，说的就是数据库架构设计本身的不同技术思路之争。
Shared Everything一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer。
Shared Disk的代表是Oracle RAC，用户访问RAC就像访问一个数据库，但是这背后是一个集群，RAC来保证这个集群的数据一致性。
问题在于，Oracle RAC是基于IOE架构的，所有数据用同一个EMC存储。在海量数据处理上，IOE架构有天然的限制，不适合未来的发展。阿里巴巴的第一个数据仓库就是建立在Oracle RAC上，由于数据量增长太快，所以很快就到达20个节点，当时是全亚洲最大的Oracle RAC集群，但阿里巴巴早年算过一笔账，如果仍然沿用IOE架构，那么几年后，阿里的预计营收还远远赶不上服务器的支出费用，就是说，如果不去IOE，阿里会破产。
Shared Nothing的代表就是Hadoop。Hadoop的各个处理单元都有自己私有的存储单元和处理单元，
各处理单元之间通过协议通信，并行处理和扩展能力更好。中间有一个分布式调度系统，会把表从物理存储上水平分割，分配给多台服务器。
Hadoop的好处是要增加数据处理的能力和容量，只需要增加服务器就好，成本不高，在海量数据处理和大规模并行处理上有很大优势。
综上，用一个关键词来概括第三阶段就是「去IOE」，建立Shared Nothing的海量数据处理平台来解决数据存储成本增长过快的问题。在阿里巴巴，前期是Hadoop，后期转向自研的ODPS。
第四阶段是数据中台阶段。
这个阶段的特征是数据量的指数级增长，从PB迈向了EB级别，未来会到什么量级，我也说不清楚。
主要是因为，2015年之后，IOT（物联网）发展起来，带动了视图声（视频、图像、声音）数据的增长，未来90%的数据可能都来自于视图声的非结构化数据，这些数据需要视觉计算技术、图像解析的引擎+视频解析的引擎+音频解析的引擎来转换成结构化数据。5G技术的发展，可能会进一步放大视图声数据的重要性。
线下要想和线上一样，通过数据来改善业务，就要和线上一样能做到行为可监测，数据可收集，这是前提。线下最大量的就是视图声数据，而这些数据靠人来手工收集，肯定是不靠谱的，依靠IOT技术和算法的进步，最终会通过智能端来自动化获取数据。
要使用这些数据，光有视觉算法和智能端也不行，要有云来存储和处理这些数据，以及打通其他领域的数据。
另一方面，从业务来看，数据也好，数据分析也好，最终都是要为业务服务的。也就是说，要在系统层面能把OLAP和OLTP去做对接，这个对接不能靠人来完成，要靠智能算法。
目前的数据中台，最底下的数据平台还是偏技术的，是中台技术方案的其中一个组件，主要解决数据存储和计算的问题；在上面就是一层数据服务层，数据服务层通过服务化API能够把数据平台和前台的业务层对接；数据中台里面就没有人的事情，直接系统去做对接，通过智能算法，能把前台的分析需求和交易需求去做对接，最终赋能业务。
数据中台处于计算后台和业务前台之间，其内核能力是以业务视角而非技术视角智能化构建数据、管理数据资产，并提供数据调用、数据监控、数据分析和数据展示等多种服务。
承技术后台，启业务前台。基于数据，深入业务。
主要方法论：OneData、OneEntity、OneService
OneData：致力于实现数据的标准和统一，让数据成为资本而非成本
OneEntity：致力于实现实体统一，让数据融通而非以孤岛的形式存在
OneService：致力于实现数据服务统一，让数据复用而不是复制
- 数据中台未来一定需要具备三种能力。
第一是数据模型能力。
在业务层面，业务抽象能够解决80%的共性问题，开放的系统架构来解决20%的个性问题，但同时又要把平台上的业务逻辑分开，因为不同的业务逻辑之间可能有冲突。
这在数据中台就表现为数据的中心化，也就是数据的高内聚、低耦合，需要对共性问题抽象出业务的规则，建立数据模型，一个好的内聚模块能够解决一个事情，同时又要降低模块和模块之间的耦合度，让模块具有良好的可读性和可维护性。
这里的前提是要有真正懂业务能沉淀经验的人，以及要在企业层面开展数据治理，让数据能够准确、适度共享、安全地被使用。
第二是AI算法模型能力。
要实现数据业务化，前提是做到数据的资产化。要能够从数据原油里面，去提炼出可以使用的汽油。
比如说数据的标签化，背后就有投入产出比的考量：通过标签，广告主可以非常方便快捷地去建立自己的人群包，实现精准营销，同时投放的ROI也是可见的、透明的，广告主可以自己去评估数据资产的使用情况。
第三是行业的应用能力，也就是我们通常说的数据业务化能力。
- 数据中台的核心价值分析：
1、数据中台是精准服务的基础能力
今天的浙江移动已经将2000个基础模型作为所有数据服务开发的基础，这些基础模型做到了“书同文，车同轨”，无论应用的数据模型有多复杂，总是能溯源到2000张基础表，这奠定了数据核对和认知的基础，最大程度的避免了“重复数据抽取和维护带来的成本浪费。”
曾经企业的数据抽取就有多份，报表一份，数据仓库一份，地市集市一份，无论是抽取压力、维护难度及数据一致性要求都很高。
同时，统一的基础模型将相关业务领域的数据做了很好的汇聚，解决了数据互通的诉求，这点的意义巨大，谁都知道数据1+1>2的意思。
2、数据中台是业务发展的源动力
在企业内，无论是专题、报表或取数，当前基本是烟囱式数据生产模式或者是项目制建设方式，必然导致数据知识得不到沉淀和持续发展，从而造成模型不能真正成为可重用的组件，无法支撑数据分析的快速响应和创新。究其原因是模型建设往往是项目式的建设方式，一旦项目结束，在面对业务提出更多需求时，项目模型团队可能已经撤离了，或者考核指标早已经随着项目结束，模型提供者在主观上没有太大的积极性去满足新的需求，如果当初模型的扩展性设计的不好，或者时间太紧，或者系统稳定的需要，往往导致有心无力满足新的需求，结果是数据模型无法再扩展，成为事实上稳定的但无用的模型。
其实，业务最不需要的就是模型的稳定，一个数据模型如果一味追求稳定不变，一定程度就是故步自封，这样的做法必然导致其他的新的类似的数据模型产生，当越来越多的模型都采用自建的方式满足需求时，意味着老的数据模型就可能要离开历史舞台了，而留下的是割裂的成千上万的模型，也就失去了模型知识沉淀的可能，曾经做过一张几百个字段的万能宽表，由于太大后来就没人敢去动它，随着新的业务不断增加，这张宽表的价值却越来越低直至退出历史舞台。
数据模型不需要“稳定”，而需要不断的滋养，只有在滋养中才能从最初的字段单一到逐渐成长为企业最为宝贵的模型资产。其实标签也一样，做过不少异动标签或离网模型，曾经效果不错，随着公司转型流量经营，原来以语音异动判断为主的这类标签开始难以适应变化，但后续已经没人能改得动它，这个标签也就退出了历史舞台，退出的可不仅仅是一个标签，这个标签承载的所有的既有经验也就被废弃掉了，想想这些标签当初花了多大的代价做成就会感觉非常可惜。再以报表为例，企业报表成千上万的原因往往也是没有沉淀造成的，针对一个业务报表，由于不同的业务人员提出的角度不同，会幻化出成百上千的报表，如果有报表中台的概念，就可以提出一些基准报表的原则，比如一个业务一张报表，已经有的业务报表只允许修改而不允许新增，自然老报表就会由于新的需求而不断完善，从而能演化成企业的基础报表目录，否则就是一堆报表的堆砌，后续的数据一致性问题层出不穷，管理成本急剧增加，人力投入越来越多，这样的事情在每个企业都在发生。
3、数据中台是业务创新基础
企业的数据创新一定要站在巨人的肩膀上，即从数据中台开始，不能总是从基础做起，数据中台是数据创新效率的保障。
搞过机器学习的都知道，没有好的规整数据，数据准备的过程极其冗长，这也是数据仓库模型的一个核心价值所在，比如运营商中要获取3个月的ARPU数据，如果没有融合模型的支撑，得自己从账单一层层汇总及关联，速度可想而知。
很多合作伙伴的数据科学家到一个企业水土不服，除了业务上不熟悉外，往往还面临着数据准备的困境，取数的高难度导致他难以快速的去验证想法，企业想借助外力去搞数据创新有时成了一厢情愿。
标签也一样，企业打造标签可并不仅仅是做几个标签那么简单，它需要打造的是一个标签服务平台，要能最大限度的规范标签的格式，接入方式，组合方式，调用方式等等，只有这样，基于标签的二次快速创新才有可能，企业每发布一个新的标签，就意味着新增了一种能力，这才是数据知识的真正传承。
比如当常驻地模型发布成为标签平台的一个标签后，以后凡是涉及到常驻地判断的都可以直接调用，这极大降低了关于用户位置数据准备的成本。
在如今的互联网时代，企业都在全力谋求转型，转型的关键是要具备跟互联网公司一样的快速创新能力，大数据是其中一个核心驱动力，但拥有大数据还是不够的，数据中台的能力往往最终决定速度，拥有速度意味着试错成本很低，意味着可以再来一次。
4、数据中台是技术发展的源泉
记得笔者刚进企业的时候，要获得成长一是靠人带，二是找人问，三是自己登陆各种系统去看源代码，这样的学习比较支离破碎，其实很难了解全貌，无法知道什么东西对于企业是最重要的，获得的文档资料也往往也是过了时的。
现在有了数据中台，很多成长问题就能解决，有了基础模型，新人可以系统的学习企业有哪些基本数据能力，O域数据的增加更是让其有更广阔的视野，有了融合模型，新人可以知道有哪些主题域，从主题域切入去全局的理解公司的业务概念，有了标签库，新人可以获得前人的所有智慧结晶，有了数据管理平台，新人能清晰的追溯数据、标签和应用的来龙去脉，所有的知识都是在线的，最新的，意味着新人的高起点。
更为关键的是，数据中台让新人摆脱了在起步阶段对于导师的过渡依赖，能快速的融入团队，在前人的基础上进行创新。
数据中台天然的统一，集成的特性，有可能让新人打破点线的束缚，快速构筑起自己的知识体系，成为企业数据领域的专家。