1.2 什么是数据中台
阿里巴巴提出的数据中台源于Supercell的实践。从上面介绍的两个典型硅谷大数据平台的实践来看,它们的思路及效果与Supercell的“数据中台”类似:中台提供数据能力的共享和复用,前端业务部门可以快速获得全局的数据洞见及现成的数据工具,快速推出由数据支持的产品。
那么,数据中台到底与我们常说的大数据平台有何区别和联系?要回答这个问题,首先必须明确地定义数据中台这个概念。
1.2.1 数据中台建设的目标
要定义数据中台,首先要明确数据中台建设的目标。虽然数据中台有新瓶装旧酒的嫌疑,但是阿里巴巴提出的数据中台要解决的问题还是清晰且真实存在的:
·各个部门重复开发数据,浪费存储与计算资源;
·数据标准不统一,数据使用成本高;
·业务数据孤岛问题严重,数据利用率低。
思考试验 以上问题都是真实存在的,但如果我们的大数据平台没有这些问题,还需要数据中台吗?
根据数据中台要解决的问题,我们可以确定数据中台建设的终极目标。数据中台首先是一种IT系统,而IT系统建设的最终目标是服务企业,因此数据中台的建设遵循我们常说的以业务为导向的路径。
虽然企业的发展目标多种多样,例如阿里巴巴的目标是“让天下没有难做的生意”,腾讯的目标是“以技术丰富互联网用户的生活”,但是这些大目标都有一个共同的子目标,即最高效地实现资源的合理配置和利用,创造最大的企业利润,简单来讲就是精细化运营,开源节流。从最早的会计系统,到计算机普及时代的信息化建设,到现在的大数据、数字化转型、智能化,都是服务于这个目标的。特别是在网络时代,很多产业形成赢家通吃的局面,企业更需要比竞争对手先行一步,在激烈的市场竞争中占据先机,获取更高的利润。
因此,建设数据中台的最终目标是通过高效的数字化运营,实现“快速市场响应,精细化运营,开源节流”。数字化运营是让企业在市场竞争中取得相对优势的必要手段,其目标是让企业做到以下几点:
·比对手更早洞察市场的动向;
·比对手更了解用户的反应;
·比对手成本(包括生产和管理成本)更低;
·推出比对手的产品更符合用户需求的产品;
·比对手更快地将产品推向市场;
·比对手更快地迭代产品。
值得注意的是,这里的重点是相对优势,也就是与市场常态相比的优势。例如,如果市场中的参与者都采用粗放式管理,那么率先实现信息化的企业就比其他企业更有优势。实际上,信息化已有近30年历史,不同行业的信息化水平有些差异。例如,银行、保险这些主要与数字打交道的行业的信息化水平相对领先,而制造业、农业的信息化水平则相对滞后。一般来讲,相对优势都是针对本行业而言的,因此信息化和数字化的落地程度主要与行业相关。
在完成初步的信息化之后,如果想比其他企业更有优势,企业就需要有更强大的信息化系统,也就是大数据系统,其建设初衷是获得更多的数据以及更快、更全面的市场反馈。然而现在的情况是,很多企业虽自称拥有大数据系统,但其效果并不是很好,于是就产生了数据中台建设的需求。
不管叫不叫数据中台,所有数据工具的建设目的都是从数据中提取价值来支持更有效的数字化运营。这里所说的数据价值又被称为“可指导行动的洞见”(Actionable Insight),其重点之一是可指导实际的商业行为,重点之二是洞见,即在建设这个数据工具之前无法得到或发现的知识。二者缺一不可:如果不能指导实际行动,创造实际价值,那么这个数据工具以及从中产生的知识就是无用的;如果不是新发现的知识,那么就没有必要花大价钱来建设这个数据工具。说到底,数据工具的建设要用ROI(Return On Investment,投入产出比)来衡量。数据中台的出现,很大程度上就是因为原有大数据系统建设的ROI不尽如人意。
根据所指导的行动的领域,“可指导行动的洞见”可分为两类(参见前面数字化运营的目标)。
·商业智能(Business Intelligence):也叫数据驱动的决策,也就是要有对业务更深层次、更全面、更多维度、实时性更强的洞见,从而指导机构的运营。这是给实际数据使用人员使用的,一般表现形式为各种报表、看板、BI查询工具、大屏等。
·数据驱动的应用(Data Driven Application):可以实现由数据驱动的业务应用(参见3.2节对数据驱动的介绍)。与传统固定行为的应用不同,数据驱动的应用通过分析各种数据(用户行为、市场数据、第三方数据)来决定应用的行为。其中一般都会涉及对数据的复杂分析,需要使用机器学习、人工智能(AI)算法来从数据里发现模型,然后用模型来指导应用行为。
我们一般说数据的用途就是BI和AI,这也是传统大数据平台和数据仓库建设的目的。从这个角度来讲,数据中台与传统大数据平台和数据仓库的建设目的是一致的。
但是数据中台有一个比传统大数据平台和数据仓库层次更高的要求:实现数据能力的全局抽象、共享和复用,从而提高数据价值实现的效率和ROI。可以说,数据中台强调的是大数据平台和数据仓库的建设方式。虽然大数据平台和数据仓库也强调数据能力的抽象和复用,但是它们并没有从方法论、工具和流程上强调如何支持和要求数据能力的抽象、共享和复用。传统大数据平台提供的主要是各种大数据组件的安装和运行,数据仓库建设主要集中在业务的建模和数据的清晰度上,二者的功能都是数据中台需要的。数据中台需要在它们之上提供整套工具、流程和方法论来实现数据的抽象、共享和复用。基于上面的分析,我们可以确定数据中台建设的目标:
通过提供工具、流程和方法论,实现数据能力的全局抽象、共享和复用,赋能业务部门,提高实现数据价值的效率。
1.2.2 如何实现数据中台建设的目标
在明确了数据中台建设的目标之后,下面我们以EA的实践为例,看看数据中台如何实现这些目标。
第一,实现这些目标必须有相应的数据能力,也就是从数据中产生价值的能力。
如前所述,数据的价值一般从两方面体现:数据驱动的决策(BI)和数据驱动的应用(AI)。从原始数据到数据产生价值,中间有一个很长的链条,需要的工具都是提供数据能力所必需的。数据中台(包括底层的大数据平台和数据仓库)应该提供高效的工具来支持这个链条中的所有功能。例如,在EA,各个游戏工作室都会用统一的大数据平台来完成用户行为分析、反欺诈、动态定价等一系列关键的数据驱动的功能。这些功能无法用预先设计好的算法或程序来完成,必须根据实际数据采取相应行动才能实现。这些都是数据能力的典型代表。
第二,要实现这些目标,必须完成全局的数据汇聚和治理。
这就需要有统一的数据规范,使数据生产者、数据消费者通过这个规范达成共识。例如,EA大数据团队花了一年时间整理出像字典一样厚的数据规范,形成连接生产数据的游戏工作室与消费业务数据的分析部门的桥梁。比如,游戏里有一些简单的代码,表示的是战车、手榴弹、手雷、机关枪或冲锋枪等武器,而业务分析部门通常是看不懂的。另外,各游戏工作室传上来的游戏数据格式都有统一的规范,有一些是通用的基础指标,还有一些是不同游戏自带的特殊数据。有了这种统一而详细的数据规范标准,各业务分析部门就可以轻松整合所有的游戏数据,形成公司层面的数据资产,然后对其进行挖掘和分析,得到各自需要的有价值数据。
第三,企业必须高效完成从汇总好的数据到价值的转换,需要进行数据能力的抽象,然后实现能力的共享和复用。
这个过程有两种实现方式。一种是由大数据部门做顶层设计来实现。举例来讲,不少游戏都存在作弊玩家,他们通过创建僵尸账号来收集游戏币,然后在黑市上转卖这些游戏币,这会给游戏公司带来巨大损失,每个月可能会损失超百万美元。而大数据部门就要通过顶层设计来解决这类欺诈问题。EA大数据团队设计了一个反向索引的分析系统,各游戏工作室从黑市上买了游戏币以后,只要把这些游戏币的ID输入系统里,就可以通过反向索引查到并清除掉收集这些游戏币的僵尸账号。这个数据能力是各个工作室都需要的,虽然它们的需求会有细微差异,但是大数据平台将其中的共同点提取出来,形成一个通用工具,各个工作室可以配合自己的特定参数来使用。这就是一个从顶层设计来抽象数据能力,帮助业务部门解决问题的例子。
另一种方式是一个业务部门开发供自己使用的服务,但发现其他业务部门也需要,于是就对这种服务进行抽象,以供全公司复用。举例来讲,FIFA游戏推广团队有一个需求是,每天通过电子邮件向特定用户群体推送打折券。以往,需要进行很复杂的查询才能得到目标用户的ID,要从几百万个用户中筛选出几百个,而且一天可能只能做一次。FIFA游戏推广团队与大数据团队合作开发了一套标签系统,利用它可以快速定位这几百个用户。比如这个群体是美国加州的用户,年龄在35~45岁,年收入为5万~8万美元,过去7天平均玩游戏的时间超过1小时,游戏内消费金额为2000~3000美元。确定这些标签后,几秒就可以完成层层过滤,锁定目标用户群体,然后可以很简单地通过模板将打折券推送给他们,而且这样的操作一天可以做十几次。后来,别的业务部门也需要这个功能,FIFA游戏推广团队就将这个功能进行了扩展,供其他游戏推广部门使用。这就是业务部门自行开发,然后进行抽象的例子。
第四,在实现数据能力的共享和复用的过程中,需要协调复用和效率的矛盾。
如果一个业务部门为了满足其他部门复用某个服务的需求而做了大量工作,结果影响到自己的工作效率,这就得不偿失了。这里首先需要有一套平衡的工具和机制,其次是要有能够精确衡量数据能力的ROI,让业务部门有动力共享它们的数据能力。
1.2.3 数据中台的定义和4个特点
综上所述,我们认为数据中台可以如下定义:
数据中台是企业数字化运营的统一数据能力平台,能够按照规范汇聚和治理全局数据,为各个业务部门提供标准的数据能力和数据工具,同时在公司层面管理数据能力的抽象、共享和复用。
数据中台与传统数据仓库和大数据平台的最根本差异,就是强调从工具和机制上支持对数据能力的全局抽象、共享和复用。应该说,数据中台是建立在数据仓库和大数据平台之上的,让业务部门可以更好、更有效率地使用数据的运营管理层。
因此,根据我们的定义,数据中台需要具备以下特点。
1)能够借助汇聚全局的数据为用户赋能。
数据本身就是能力,从某种程度上讲数据比上层的应用更重要,而且打通的全局数据所提供的价值将超过隔离的局部数据的总和。为了打通数据,在工具层,需要提供全局数据存储、治理分析服务以及数据/应用治理和管理的功能;在业务层,必须让每个业务部门能够方便地依据标准提供相关业务数据,自动与其他部门的数据打通并汇总。从这方面讲,这不是一个纯技术问题,更多的是一个业务问题。例如互联网公司要打造全局的用户画像,需要制定公司的业务相关数据/应用的标准,并要求各个部门的业务应用按照标准采集和存储本部门负责的用户信息,这样中台才能够按照标准处理这些局部信息来形成全局的用户画像。从某种意义上来说,数据标准实际上也是数据能力的组成部分。
2)实现数据能力的抽象。
数据能力的抽象是数据中台建设中的难点,如何尽可能抽象出通用的功能,又不使抽象的功能过于细碎,这是需要仔细考虑的问题。这个问题有点类似于微服务的拆分,也与编程里抽象出对外API有着异曲同工之妙,拆大了不好,拆小了也有问题。前面我们提到过可以采用两种方式来进行数据能力的抽象:一种是顶层设计,从公司层面考虑数据能力的抽象;另一种是由业务团队自主开发,当发现有复用需要时再来抽象。这两种方式各有利弊,在很多时候可以混合使用,需要根据公司和业务的实际情况选择。
3)可以通过工具体系让企业各部门方便地共享抽象出的数据能力。
首先,数据能力的共享必须简单,如果共享很麻烦,那么企业各部门数据的提供者和使用者就不会愿意使用这些功能,共享也就失去了意义。其次,共享的责权利必须要分清。这里涉及的角色有提供者、平台团队、使用者三方,而这三方的责权利划分,例如,谁负责开发、谁负责维护、谁负责升级等,则决定了共享最终能否成功,因此这一点需要重点关注。
另外需要注意的一点是,应该提供相应的工具来支持这种区分,例如,提供衡量一个共享API所产生价值的量化工具,提供共享的绩效对比和考察工具等,这些都是促使共享能够被企业的所有用户接纳的重要因素。
4)可以高效地管理数据能力并加以复用。
第一,必须能快速发现可复用的数据能力,这样才能在快速迭代时保证没有重复的开发,因为只有知道自己有什么轮子,才能避免重复造轮子。为了系统地避免重复开发的情况,一般需要有一定流程的支持,例如Twitter通过自身的架构委员会来衡量哪些数据能力可以复用。除此之外,也可以由一些管理程序自动发现类似的数据和应用的复用。
第二,能够协调复用和效率的矛盾。经常会出现这样的情况,团队A开发了一个功能,团队B觉得可以用,但是需要做些修改,而团队A暂时没有资源做这件事,团队B没有时间等,只能自己再开发一个。所以,关于共享功能的后续开发一定要有明确的规则和责权划分。
第三,能够提高复用的效率。比如,如果团队A共享了一个功能后,其他部门的人天天来找团队A的人问这个功能怎么用,那么团队A的效率就会受到很大的影响。因此我们需要考虑共享功能的规范要求,例如共享的数据和应用的文档必须有一定要求。此外,共享的工具也必须提供迭代提升的功能,例如功能文档的协同编辑功能。