数据中台的演进可以分为四个阶段，分别是：数据库阶段；数据仓库阶段；数据平台阶段；数据中台阶段。笔者将具体介绍这四个阶段的数据化特点以及发展历程。

2009年，阿里云开启了中国的云时代。

十年市场教育，中国的公有云市场也已经从无到有，迈过了300亿元大关，预计到2021年更是能达到900亿元的规模。

「数据中台」已经从一个技术词汇，慢慢转变成为企业界的共识：如果想要在信息商业中拥有一席之地，就必须要借助云计算和数据的力量，完成企业的数字化转型。

只是，数据到底在转型中扮演什么样的角色，要如何利用好数据，数据上云后如何支持业务，企业需要哪些核心能力？这些问题，对于大多数的非技术业者而言，仍然是知其然不知其所以然。

一般而言，「数据上云」更多强调的是数据的存储和计算，而要让数据能够赋能业务，则更需要「数据中台」来进行数据处理，进而支持业务决策和优化运营。

这是「数据中台」和「数据上云」最大的不同。

一、数据中台最终要帮助企业降本增效

作为数据业务领域的先行者，阿里云总裁张建锋，在最新的演讲中，把数据智能作为数据处理的核心能力：

「今天处理数据绝大部分都不是单纯靠算力，算力是基础，而主要是靠上面的智能化的算法，算法跟各行各业的业务有密切相关，所以阿里巴巴通过与各行各业合作，沉淀了一个完整的智能化平台。我们认为在基础设施的云化、核心技术的互联网化以及在之上叠加大数据+智能化的平台和能力，完整地组成了阿里云智能的整体能力框架。这是我们核心的能力。」

这里面传达出了几个核心信息：

1. 云计算为数据智能提供了基础算力；
2. 行业（经验转化而来的）算法是智能处理数据的主要工具；
3. 数据+智能的平台和能力，前提是基础设施的云化和核心技术的互联网化。

这是阿里云所认为的数据处理的能力框架，而在目前的市场上，我们通常把这种能力框架称为「数据中台」。

舆论往往会更强调技术的作用，强调技术对业务的推动作用，但事实上，在商业领域，更多的时候，技术发展都是跟着业务走，技术的发展常常来自于业务需求和业务场景的倒逼。

例如，随着越来越多的企业把业务流程上云，日益增长的数据存储和仍然稀缺的数据应用就成为了企业的主要矛盾之一，而且这种矛盾不是一天就能够解决，需要从业务、技术、组织几个不同的领域一起来探寻数据的解决方案。

简单来说，「数据中台」就是这一系列解决方案的基础设施。

数据中台不是一套软件系统，也不是一个标准化产品，站在企业的角度上，数据中台更多地指向企业的业务目标，也即帮助企业沉淀业务能力，提升业务效率，最终完成数字化转型。

直白点说，中台只讲技术，不讲业务，都是大忽悠。

这么多年来，互联网的发展都建立在更低成本、更高效率的连接之上，线下也一定会复制线上的发展逻辑，用更多连接带来更多的数据。

比如，通过摄像头，我们就可以低成本建立顾客的Face ID档案，从而丰富人和店铺的关系数据，店铺进而可以根据数据分析结果，给顾客提供更有针对性的服务项目。

更多连接，更低成本，更高效率——所有跟流通相关的线下生意，数据中台的意义就在于降本增效，别无其他。

二、数据中台发展经历了四个阶段

在数据史上，2015年是一个重要的关口：2015年全年产生的数据量等于历史上所有人类产生数据的总和，这是数据从乘数型增长全面转向了指数型增长的方向标，海量数据处理成为全人类的挑战；

同一时间，阿里巴巴向外发布了DT时代的提法，用Data Technology（DT，数据技术）替代了Information Technology（IT，信息科技），强调数据技术将成为未来商业的驱动力。

一个标志性的事件是：阿里巴巴用几百人的运营团队支撑了几万亿的GMV，其中60%-70%来源于数据支持的机器决策，机器智能赋能业务，用更低的成本、更高的效率去服务顾客，提供千人干面的个性化体验。

未来学家认为，机器智能最终会超越人的智慧，而这两者的临界点就被称为「奇点」。从这点来说，我们可以认为，阿里巴巴已经跨越了奇点，真正成为一家数据公司。

下面我们从数据的角度来梳理下这个过程。

阿里巴巴的数据处理经历了四个阶段，分别是：

1. 数据库阶段，主要是OLTP（联机事务处理）的需求；
2. 数据仓库阶段，OLAP（联机分析处理）成为主要需求；
3. 数据平台阶段，主要解决BI和报表需求的技术问题；
4. 数据中台阶段，通过系统来对接OLTP（事务处理）和OLAP（报表分析）的需求，强调数据业务化的能力。

（数据中台演进的四个阶段）

第一个阶段-数据库阶段

淘宝还只是一个简单的网站，淘宝的整个结构就是前端的一些页面，加上后端的DB（DataBase，数据库），只是个简单的OLTP系统，主要就是交易的事务处理。

这个阶段，互联网黄页才刚刚出现，数据来源大部分还是传统商业的ERP/CRM的结构化数据，数据量并不大，也就是GB的级别。简单的DB就能满足需求。

这里要说明的是，OLTP的交易场景和OLAP的分析场景区别在于：前者强调高并发、单条数据简单提取和展示（增删改查）；后者对并发的要求不高，但是需要打通不同的数据库，比如ERP、CRM、行为数据等等，并且能够进行批量的数据处理，也就是通常说的低并发，大批量（批处理）、面向分析（query+计算，用于制作报表）。

随着淘宝用户超过100万，分析需求的比重就越来越大。淘宝需要知道它的交易来自于哪些地区，来自于哪些人，谁在买淘宝的东西等等，于是，就进入了数据处理的第二个阶段。

第二个阶段-数据仓库阶段

正如前文所述，OLTP和OLAP对数据存储和计算的需求非常不一样，前者处理的是结构化的交易数据，而OLAP对应的是互联网数据，而互联网里面数据量最大的是网页日志，90%以上的数据都是点击（log）什么的非结构化的数据，而且数据量已经达到了TB的级别。

针对分析需求，就诞生了数据仓库（DW，DataWarehouse），我2004年加入阿里，用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能够把数据平台和前台的业务层对接；数据中台里面就没有人的事情，直接系统去做对接，通过智能算法，能把前台的分析需求和交易需求去做对接，最终赋能业务。

综合上述两个方面，我认为未来要做好数据中台，只做云或者只做端都不靠谱，需要把两者合起来做。智能端负责数据的收集，云负责数据的存储、计算、赋能。端能够丰富云，云能够赋能端。

未来的数据中台，一定是「AI驱动的数据中台」，这个中台包括「计算平台+算法模型+智能硬件」，不仅要在端上具备视觉数据的收集和分析能力，而且还要能通过Face ID，帮助企业去打通业务数据，最终建立线上线下触达和服务消费者的能力。

真正做到「一切业务数据化，一切数据业务化」。

三、数据中台需要具备三大能力

那么，数据中台是怎么来赋能业务使用数据的呢？这里举一个TCIF的例子。

现在大家可能都认识到了统一消费者数据的必要性，但是在几年前，哪怕是在阿里巴巴，消费者的信息也分散在各个业务中，碎片化、散点化，而业务当时需要把这些分散的人的数据集中起来，进行人群画像。道理很明白，人群画像越清晰，服务就会越精准。

怎么统一消费者数据？

首先，定义埋点规范，同一个人就用同一个标识，ID打通，也就是所谓的One ID；

其次，还会碰上一家人使用一个登录帐号的问题，那么就需要建立同人的数据模型，通过一些方式，比如，IP网段是不是一样，来分辨出具体的那个人，建立AID（Alibaba ID）；

再次，每个人还有各种网络行为，要如何把这些行为结构化，装到各种框架里面？这个特别难，我们当时主要是跟人类学家合作，一起把行为的分类树做出来。这个分类树非常细，甚至能够把一个人的发质都结构化了。

最后，就需要通过算法模型，把所有的标签都贴回到人上面，当时TCIF用上述方式生产出了3000多个消费者标签。

这些标签被阿里巴巴的其他产品所使用，比如阿里妈妈的达摩盘就把这些标签提供给广告主，让广告主能够通过标签去建立人群画像，进行人群细分，以及建立投放用的人群包。

从TCIF的例子来看，数据中台未来一定需要具备三种能力。

1. 数据模型能力

在业务层面，业务抽象能够解决80%的共性问题，开放的系统架构来解决20%的个性问题，但同时又要把平台上的业务逻辑分开，因为不同的业务逻辑之间可能有冲突。

这在数据中台就表现为数据的中心化，也就是数据的高内聚、低耦合，需要对共性问题抽象出业务的规则，建立数据模型。一个好的内聚模块能够解决一个事情，同时又要降低模块和模块之间的耦合度，让模块具有良好的可读性和可维护性。

这里的前提是要有真正懂业务能沉淀经验的人，以及要在企业层面开展数据治理，让数据能够准确、适度共享、安全地被使用。

2. AI算法模型能力

要实现数据业务化，前提是做到数据的资产化。要能够从数据原油里面，去提炼出可以使用的汽油。

比如说数据的标签化，背后就有投入产出比的考量：通过标签，广告主可以非常方便快捷地去建立自己的人群包，实现精准营销；同时投放的ROI也是可见的、透明的，广告主可以自己去评估数据资产的使用情况。

3. 行业的应用能力

行业的应用能力，也就是我们通常说的数据业务化能力。

和数据中心化类似，数据业务化也需要很强的行业经验来指导，建立合适的业务场景，在场景里面去使用数据，从而体现数据的价值，来大大扩展数据在行业中的应用能力。

最后总结一下，未来的数据中台最重要的不单是数据的存储和计算能力，而是要能从「存、通、用」的角度和业务结合，帮助企业从数据中获取价值，沉淀数据资产，最终用数据赚钱。

本文由 @奇点云 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议