超越平台，数据中台的业务化、服务化及开放化！

现在关于数据中台的解释很多了，当然各有道理，但如果我问你数据中台与数据仓库、数据平台、数据湖等有什么本质区别，你不一定说得清楚。

比如我们引入的某大厂的ETL工具BDI，你认为其是数据中台一部分吗？

我可以明确的告诉你，它刚出来的时候根本不能算是中台的东西，它只是一个偏系统级的应用。

为什么？

今天就再来深入的谈一谈数据中台的本质，本篇文章有5000个字，一定要看完。

在之前，笔者先给大家看一封很久很久以前一位同事的离职信，上面是这么说的：

“非常感谢周五下午您的那次促膝长谈和写给我的两封信（一定花了您不少时间！）。这两天认真考虑了您给我的建议，并与身边好友以及XX的同学交流了看法，特别是征求了家人的建议，最终我还是决定离开。主要基于如下考虑：

工作对于我来说，最大的成就感就在于能发挥自己的专长并因此创造价值，影响决策者，在这点上，XX企业的目前的职位更为明晰一点。在传统行业，还是以业务部门为绝对主导，他们有大量和决策层接触的机会，例如……分析报告，无论是主动还是被动，他们都得到了大量的锻炼机会，并可以自由在报告中表达自己的观点、想法，影响决策者……”

这封信反映了一名数据技术从业者的困惑。

“一直以来，企业的BI数据管理跟IT是紧捆绑的，但跟公司的战略、业务脱节非常厉害，很多企业几乎没有想过企业获取利润跟数据管理有多少直接的关系，反正是大概有关系吧。企业有投资，有费用，反正属于IT要干的事就去干吧，大家都在做，我们当然也要做，在我刚开始做元数据管理的时候，就是这个感觉，从没想到这个东西跟企业的利润有半毛钱关系。”

“做了怎么样？不做了又怎么样？我们甚至连自己都骗不过。直到开始做大数据，当商务、开发必须紧密衔接的时候，当发现某个数据问题已经导致变现困难的时候，才感觉到数据管理的真正价值，才知道自己的数据管理工作该干什么。”

这是我以前的困惑。

自己不止一次的提到过：IT是业务的后端，而数据是后端的后端，数据要往前走面临着巨大挑战。DT时代给了我们一次机会，但有了势，没有方法和举措，你也抓不住，还好，我们有数据中台为自己正名。

但十多年前数据仓库如火如荼兴起的时候，为什么它就不能称为数据中台？为什么数据仓库就不能更好的创造价值？

笔者认为数据中台起码有三个特征，是传统的数据平台很难兼顾的：业务化、服务化及开放化。业务是根本，服务是手段，开放是价值，而数据中台把三个都占全了。

一、业务化

数据仓库是数据中台吗？

不是，因为数据仓库只是实现了数据的平台化，那么，平台化又是什么意思呢？

举个例子，我们拿一个饮料厂的产品线来讲，他可以生产果汁，还可以生产其他的产品，从原材料加工成饮料，它有很多环节，虽然品种不一样，但是它很多环节是类似的，比如装瓶、搅拌。

那么这几个不同的生产流程、生产线，我们可以把那些公共的部分合并起来，更加专业化，然后并且让他们独立去维护，之后把那些不同的产品面向客户，使客户体验不同的产品，使它独立出来，这就是平台化的思路。

所以，平台化的思路很重要的就是把那些有共性的资源，有共性的能力合并在一起，然后把那些面向客户的价值独立出来，这样的话，专业的人做专业的事情，并且对于企业的绩效也非常的有利，不揉在一块了，更加的清晰，这就是平台化的思路。

数据仓库也有一样，各方的数据资源通过E汇聚在一起，然后通过T统一做转化，再通过L统一入库再通过DW分层处理建模，最终实现数据的共享，整个过程就是柔性数据处理”流水线”，从而满足不断丰富、变化的数据分析、挖掘类需求，有时我们也把数据仓库叫做数据仓库平台。

但数据仓库也好，传统的数据平台也好，其出发点应该说更是一个支撑性的技术系统，即一定要去考虑我有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理，而数据中台的第一出发点可不是数据，而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务？

至于说这些数据服务所依赖的数据有没有，那是我们的实现方式，只要这个服务有价值，那我们就要去想办法去拿到数据，如果没有能力我们去建这个技术能力，去完成数据服务的提供。（注：以上黑体字观点参考史凯 BangTalk︱第1期《火热的数据中台对企业的价值是什么？相关论述》）

笔者以下的实践完美的诠释了以上观点。

一般来讲数据采集在一个企业是由统一的采集运维团队负责的，但你会发现一些数据的采集和解析方式直接决定了业务的价值，而这对于一般的采集运维团队来说是非常困难的。

比如对于位置数据，笔者就要求打破层级式的数据管理方式，让位置洞察团队直接端到端的完成从业务到数据采集的全过程，位置洞察团队实际承担着位置产品研发、行业模型研发、位置精度算法、位置数据解析和采集等多种职能，因为只有他们才能理解清楚如何根据业务要求来采集全自己所需的数据，从而让上层应用达到业务的要求。

你看，这就叫业务化，用业务驱动数据的建设，这是数据中台希望达到的目标。

我们也可以反思，为什么以前大而全的数据治理项目会经常失败？因为它源于数据，终于数据，它竟然是自我循环的。

为什么公司会限制大数据的投资？因为看不到明显的业务产出，因为没有人为你的数据平台建设背书。

数据中台区别于传统数据平台的在于数据中台的思维是业务化的思维，它从业务问题出发。这也能解释为什么业务部门对数据中台是比较欢迎的，哪怕我的数据只有50%的准确性，只要能产生价值，何必纠结于50%？

最近笔者团队上线了实时数据中台，快速的构建起了校园营销实时应用，虽然业务部门不知道实时数据中台是什么，但一定会为校园实时营销背书，这是有说服力的。

很多数据平台饶了十八个弯才跟业务挂上点关系，就是建设伊始就跟业务离得太远了，谁又能理解你建的这个东西对于业务能产生什么直接的价值。

不管黑猫还是白猫，抓到老鼠的就是好猫，看来是颠扑不磨的真理。

二、服务化

大家在提数据中台的时候，服务化应是提得最多的，因为服务化自带共享，可编排等中台核心的特征。

很多时候我们会发现不同的应用开发项目组，他们都会调用同样的数据模型，同样的数据服务，但是由于不了解数据，并且他们也不知道底层的数据结构，所以不同的项目组可能对同样的数据会用不同的处理方法，自己做自己的，然后出来的结果不一样。有的是错误的，所以开发速度慢，并且数据结果不准确，质量低，这就是过去应用开发和数据开发所面临的矛盾。

但是现在数据中台就要解决这个问题，数据中台要把那些能复用的数据模型，变成一个数据的能力平台，让那些做数据的人专注在做数据，把数据变成一个乐高积木，数据服务提供给应用开发，然后不同的应用开发项目组可以共同的去调用唯一的数据服务，从而保证数据质量和一致性，加速从数据到价值的转换过程。

笔者的企业建设了一个客户经营中心，也就是标签库，沉淀了百万级的标签，对内对外提供统一的洞察服务，对内服务于营业厅、社会渠道、手厅等渠道的个性化推荐，对外服务于智慧精选、验真、洞察、客流等变现产品，每天的调用量超过千万。

你看，通过数据服务我们把对内、对外、各类产品的画像服务全部标准化和统一化了，从而可以最大化数据的价值，但如果没有标签库前期沉淀的这些数据服务，让每个项目或产品团队自建基本是不可能的。

关于服务化的形式，有些人认为只有封装成API才算是，我觉得不是，因为数据跟功能不同，其分析的灵活性和数据维度的无限性决定了你不可能封装出所有的数据服务，因此这里的服务应该是广义的服务，只要我提供的数据能够被共享使用，在前端被业务人员或者其他机器快速方便的使用或调用，这就是数据的服务化。

正如我在《数据中台到底是什么》一问中所阐述的一样，广义的数据服务有三种服务的方式：

1、数据模型

数据模型是广义数据服务的基础，按照数据仓库的模型分层概念，第一种是基础模型，主要实现数据的标准化，我们叫作“书同文、车同轨”，第二种是融合模型，主要实现跨越数据的整合，整合的形式可以是汇总、关联，也包括解析，第三种是挖掘模型，虽然是偏应用的，但模型具有共性的话就需要把它归属到中台模型，以便开放给其它人使用，中台模型的中是相对的，没有绝对的标准。

2、数据服务

将数据模型按照应用要求做了服务封装，比如API，所谓的狭义的数据服务，其更多强调的是机器与机器的接口，就是我的数据分析或挖掘出来的结果，不仅仅以报表可视化的形式让人看，而更多的是把这些API数据服务直接地嵌入到生产系统里面产生影响，变成你的价格策略，推荐引擎或者风险管控。

为什么我前面说初期版本的BDI采集工具不是一个数据中台的东西，因为它只提供僵死的界面，不提供API等任何接口，它是一个纯粹的应用。

数据封装比一般的功能封装要难一点，毕竟OLTP功能的变化有限，而数据分析受市场因素的影响很大，变化更快，导致服务封装的难度很大。随着企业大数据运营的深入，各类大数据应用层出不穷，对于数据服务的需求非常迫切，大数据如果不服务化，就很难规模化。

3、数据开发

但有数据模型和数据服务还是远远不够的，因为再好的现成数据和服务也往往无法满足前端个性化的要求，这时候就得授人以鱼不如授人以渔了，广义的数据服务的最后一种服务形式就是数据开发和探索，其按照开发难度也分为三个层次：

最简单的是提供标签库（DMP），用户可以基于标签的组装快速形成客户群，一般面向业务人员。

其次是提供数据开发平台，用户可以基于该平台访问到所有的数据并进行可视化开发，一般面向SQL开发人员。

最后就是提供应用环境和组件，让技术人员可以自主打造个性化数据产品，以上层层递进，满足不同层次人员的要求。

但你也需要知道，光有服务化不能成就数据中台，它只是数据中台的必要条件而已，而业务化是前提。

有人会说那么你的数据仓库基础模型就不能算是数据中台的东西，它可不是业务化的产物？

还真不一定，谁说数据服务就一定要从模型的上层走？比如验真的简单查询服务其数据来源就是基础模型提供的东西，数据仓库的数据所处层次跟其能给业务带来的价值并没有绝对的相关性。