不是任何一个数据平台都可以称为数据中台的

华云数创（北京）科技有限公司 ꄲ 其他 ꄲ 不是任何一个数据平台都可以称为数据中台的

文章原载于：ICT销售与大客户联盟

原文链接：https://mp.weixin.qq.com/s/lWEIzfzp9ZC6I6ooAbQs_g

01 困惑

前些日子，一位在某知名企业数据中心任职的资深人士，提交了一份辞职信，摘录部分内容如下：

“......我还是决定离开了......，

我希望的工作状态是，能在工作中获得成就感。这种成就感并非是您理解的仅限于收入的增长，我以为我最大的成就感就在于能发挥自己的专长并因此创造价值，同时能用自己的工作成果影响决策者，帮助决策者作出更好更及时的决策。

目前，绝大部分企业，还是以业务部门为主导的，因为他们是企业发展的一个很重要的驱动，他们有大量的时间和机会，与市场客户和企业的决策层接触，但是他们的困惑是无法获得准确的数据或者是需要的数据。而我的困惑是尽管十分努力也十分艰辛的去完善我们的数据服务能力，但仍然是与一线如隔河相望般的不知道如何满足他们的需求。另一方面，尽管您一直强调企业的数据管理与IT管理，但是这些似乎与企业的战略、业务等脱节的十分的厉害，我们企业的利润获取决策与数据管理几乎没有半毛钱的关系，或者是我理解错了，也许反正有那么一些关系吧。

从大数据平台建设，到数据管理（包括元数据管理）、数据治理等一路走来，得到的感觉就是，反正你们IT部门要干，其他的企业也在干，那么你们就干吧。我们得不到来自其他业务部门和研发部门等的支撑和背书，也从没想过这些东西与企业的利润有半毛钱的关系。

工作就在从建设数据、到数据混乱，再到维护数据、再回到建设数据的的怪圈中循环。

......”

这是数据技术从业者的困惑，其实也是企业的困惑。

随着企业的发展，必然会产生更多的各类业务数据，同时，这些数据的积累也为企业实现业务数据化和数据业务化带来了更多的可能性。

但是，现实情况却是：企业的数据烟囱却越来越多，不单单一个个的业务系统和应用系统仍然是一个个烟囱，就连新建设的大数据平台也成了一个个垂直的新的数据中心。

打通数据并将其按照一个统一的标准进行建设，以达到技术降本、应用提效、业务赋能的目标，是众多企业面临的问题。

02 数据中台应运而生

下图是华云数创公司在给某企业做数据中台时，通过现场调研看到的数据现状。

这是一个较为典型的企业数据现状，在这种数据结构下，带来的的问题也十分的明显，无论是技术还是业务都不会有好的体验，数据对业务的支撑几乎没有可能有好的结果。

从业务层面来看，业务体验十分不好：

1、数据的命名不规范不一致、口径不统一、算法不一致等等导致数据不标准，使得业务困扰。

这也是很多做报表的工具尽管提供了所谓拖拉拽的填报方式，在实际工作中很少有人用的原因。

2、业务的新需求必将产生新的烟囱式的开发，因而开发周期长，效率低，而且，这种开发使得面向应用的服务化能力不足，从而导致业务响应速度慢。

3、不断的重复建设，导致任务链越来越冗长，任务也越来越繁多，导致系统的计算资源越来越紧张，数据时效性很差。

从技术层面来看，技术人员沮丧不爽且资源大量浪费：

1、烟囱式开发导致重复建设严重，技术资源大量浪费。

2、新应用新业务上线困难，下线更为困难。

3、源系统或业务变更，结果又不能及时反映到数据上

4、众多系统的数据不标准，导致研发和维护十分的困难

数据中台就是为解决这些问题而生。数据中台是从IT时代进入到DT时代的必然产物，IT时代和DT时代的最大差异其实就是商业模式的转变，在IT时代是以流程为驱动的，而DT时代是以数据为驱动的。从流程驱动转向数据驱动的必然结果就是数据中台的应运而生。

通俗的讲，数据中台就是这样一个平台：数据平台提供数据服务能力支撑。

在IT时代，像Google，微软等知名企业发布了很多的平台框架，这些平台上的业务系统都是以流程驱动，以业务为核心的，在此基础上，我们常常提及的SOA架构，实质上就是一种服务设计的框架，实现的是服务的复用。由于这些SOA服务框架，针对的都是个性化的业务需求，只能实现以组件模块的形式做编写复制，无法形成真正意义上的数据通用。

类似的还有，不少厂商提供的ETL工具，可以说它们也不能算是数据中台的产品，它们只是一个偏系统级的应用。

DT时代发生了什么？随着大数据，人工智能新技术的发展，一个新的窗口机遇突然就这样来了---数据中台来了。

因为在DT时代，主要几个核心技术组件都发生根本性的变化：

1、虚拟化和超融合的迅速发展，导致围绕IOE体系架构下各种协议标准必须做资源调度的优化。

2、分布式计算、容器化、机器学习、人工智能等技术框架的发展，导致IOE大架构出现断崖式迁移。

这种变化倒逼原来的PaaS层开始发生变化，开始出现以数据变现、数据管理为驱动力的强劲势头，进而使得PaaS层开始出现以数据驱动为核心的框架体系。

以数据驱动为核心的框架体系使得企业可以充分利用数据价值，方便的提供服务应用。

最终，数据中台就呼之即出了。

03 数据治理：始于数据，终于数据，一个奇怪的自我循环

在数据中台出现之前，已经有很多的数据平台了，比如：数据仓库、数据平台、数据湖等等。

它们和数据中台有什么差别？

我以为最大的差别在于出发点不同，由于出发点不同，必然导致效果的不同。

数据仓库、数据平台、数据湖，这些个平台的出发点其实还是一个支撑性的技术系统。

它们的共同点是：首先考虑我有什么数据，然后才定义我能干什么。所以，在这样一个出发点的前提下，数据质量和元数据管理就是特别需要强调的事情。

然而，数据中台的第一出发点是业务本身，不是数据！

建设的出发点是：解决企业的业务问题，企业的业务需要什么样的数据服务的问题是重要的出发点，所以它不管原有的系统里有什么数据。要解决的数据服务说依赖的数据，原有数据平台中有，那最好，拿来用！

因为数据只是我们解决问题过程中需要的素材，是我们实现业务发展的一种方式。只要我们的业务有价值，那么，我们就要设法去拿到数据。

没有能力的话，就去建设这个技术能力，目的是有一个：完成数据服务的提供。

数据变现的核心是什么呢？就是业务和开发必须紧密衔接。

企业什么时候需要做数据中台呢？当发现数据问题导致变现困难的时候！

数据变现需要数据往前端跑，过去的架构是业务的后端是IT支撑，IT的后端才是数据。所以数据是业务的后端的后端。

要想实现数据变现，充分挖掘数据的能力，就需要数据跑向业务前端，这是势！是DT时代不可逆的势！

势不可违，损我者昌，逆我者亡！传统的数据仓库、数据平台、数据湖等难以实现这样的势，还好，观念的突破给我们带来了数据中台的框架，它能帮我们更好的创造数据价值。

华云数创在过去的一年内为大大小小的企业做过许多次的数据治理的项目，尽管项目的调研、验收等都十分的顺利。但是华云数创的Sherry并不满意这样的结果。

为什么呢？因为很多的项目在完成之后的一段时间内数据又重新开始紊乱，数据治理后的效果开始大打折扣，客户在一定时期后又需要持续的服务。从华云数创的角度来看，似乎是一个好的现象，有可以有新的合同和新的收入了。但是，华云数创的愿景是“Help you Do Different！”，基于这样一种理念，Sherry认为，这些不算是一个成功的项目。

Sherry在总结了这些项目的基础上告诉笔者：“我们反思，为什么以前大而全的数据治理项目会经常会出现上述现象？我们的结论是：因为这些数据治理的项目是“源于数据，终于数据”，很有意思吧，居然，它们是自我循环的。”

所以，华云数创在阿里提出了数据中台的概念后，很快的反思和发展了自己的数据中台的能力，目前在数据治理和数据中台的双轮驱动下，华云数创的数据服务能力可以根据客户的实际状况给出切合企业的数据服务和变现的解决方案。

04 凡是以产品销售为其服务形态的，

大概率是不适用的

数据中台的概念由阿里巴巴首次提出，它是一个承接技术，引领业务，构建规范定义的、全域可连接萃取的、智慧的数据处理平台，建设目标是为了高效满足前台数据分析和应用的需求。

数据中台是涵盖了数据资产、数据治理、数据模型、垂直数据中心、全域数据中心、萃取数据中心、数据服务等多个层次的体系化建设方法。

这么说好抽象，也好广泛。似乎数据中台无所不能。

每一次技术的进步，都会用这样一些大而全的概念来概括。反正不是技术大拿都听不明白。

这其实是技术跟业务的差异。要是数据中台也这么推广的话，估计也会走向老路。当年，数据仓库如火如荼的在祖国大地和全球范围兴起，也是说的天花乱坠的，BI也是这样，报表也是这样，但慢慢的人们却意识到了它们的局限性。

而这种局限性的认识，是在付出了较大，甚至是极大的代价后才认识到的。

直到今天，仍然有人问我：为什么数据仓库不能称为数据中台？为什么数据平台就不能更好的创造价值？

其实，这还是对企业的变现能力和驱动力的理解或者是思维的方式是处于IT驱动还是数据驱动的差异。应该说，不同的业务处于不同的阶段需要采用不同技术体系。

同样的问题，如：上云，还是不上云？上ERP还是不上ERP？等等。

现在没有上软件的企业已经很少，谈论成功不成功也没有多大意义。前些日子，看到过一个关于数据中台是否成功的标准，定了一些指标，看上去还蛮有点道理的。建设的厂商以多少天上线就算成功了，就算交钥匙了。而且，很多厂商标榜着自己的软件比之前的系统更有好处。

但实际情况可能是，用户有说不完的苦，处理不完的事。

既然软件都已经上了，成功失败用户都得认。问题是如何冷眼看结果，对当下的业务管理要做出正确的评价，企业是不是真的适合或者该升级了！

存在问题不可怕，最怕是不知道存在问题，不知道外面世界的变化，我们在这里就给企业用户一些建议，让用户可以用来自评就可以得出结论。

数据中台，虽说是一种业务管理思想带来的，在大数据横行的今天，他地区发挥出了越来越重要的作用。但是，数据中台还是以软件作为载体来体现的，因此，数据中台作为数据变现的管理思想是不会错的，但是，作为软件就必须有一种可衡量的标准。

数据中台的内核，简单的来说，包括两方面：

一个是应用数据的技术能力，

另一个是数据资产的管理。

还是有点抽象吧？

基本的衡量标准：

一、升级的标准：

数据中台，作为企业数据管理的平台，那么，首先，就必须有能力为企业的各种业务提供实时统一的数据支持，所有的业务变迁都可以反馈或者从平台抽取的。从这个维度可定出一个升级的标准：

看企业业务管理中用到了多少零散的、人工处理的数据报表，数一数有多少张便可，好的数据中台是没有这类需要人工处理的数据来源或者表格的。

1、有问题：超过5张，数据中台就已经出状况了，有问题存在；

2、有大问题：超过10张，业务已经就遇到比较大的问题；

3、有严重的问题：超过20张，业务问题一定是很严重了；

4、玩完了、崩溃了：超过50张的，数据中台可以说已经形同虚设，别想什么数据变现了。

二、应对变化的标准：

另一个维度的标准就是数据平台应对变化的能力，数据中台必须能够支持企业内外环境的变化，业务模式的调整，甚至是人员岗位的变动等。

1、有问题：超过1天的，响应就有问题了；

2、有大问题：超过3天的，响应就是慢的了；

3、有严重的问题：超过5天的，对业务的影响已经很大了；

4、玩完了、崩溃了：超过10天的，数据中台对对业务的促进已经没有，甚至已经成了拖累了。

用这二个维度的指标为标准，对照自己企业的现状，就可以直接发现问题。

谈标准，是在提醒用户，别忘记了自己的建设数据中台的初心。用户与厂商的初心是不一样的。用户是要解决业务的实际问题，而厂商是把软件平台卖出去，至于结果如何，关心是不够的。

记得初心，实在太重要。但是，你的数据中台，真的处理所有需要的数据服务了吗？

可以这么说：凡是以产品销售为其服务形态的，都是没有处理好的。这样的数据中台大概率来说是不能适用的。

05 不是任何一个数据平台或组件，都可以称之为数据中台

IT是业务的后台，数据是IT的后台。要想进行数据化管理，让数据变现，数据中台就越发显得重要了。

前文提到：数据中台的内核，简单的来说，包括两方面：一个是应用数据的技术能力，另一个是数据资产的管理。从这两方面出发，数据中台至少需要拥有以下三个方面的基本特征：即业务化、服务化和开放化。

这也是传统的数据仓库、数据平台和数据湖等很难兼顾的地方。三者的关系是密切相关的，不可割裂的。业务是根本，是驱动数据中台建设的根本；服务是手段，是数据中台提供共享数据服务的基本；开放是数据中台价值的体现。只有这三者都满足了才能说你的数据中台的基本条件已经满足了。

一、业务化是根本

业务化是数据中台希望达到的目标，指的是用业务数据驱动数据建设。这也是与数据仓库等建设的出发点截然不同的。

数据仓库、数据平台等只是实现了数据的平台化，它们只是完成了从数据来到数据聚合、分类等的数据终点，并没有直接的与业务有关联。

平台化现在提的很多，大多数场合提到平台化是指的公司的架构、业务的架构、产品的架构等。

这些平台化比较好理解。当谈到数据的平台化的时候，就比较抽象，不少人就难以理解了。

平台化思维中，很重要的一点就是把有共性的资源或者有共性的能力合并在一起，然后把这些能面向客户的价值独立出来。

专业的人做专业的事情，即便于发挥这些资源的价值，也有利于企业的绩效。不揉在一块了，更加的清晰，这就是平台化的思路。在企业经营中的孵化器、阿米巴等等其实都是平台化的思维。

那数据的平台化是什么呢？

为方便说明，我们来看一个例子：拿一个服装成衣厂家来说，它可能有多条生产线，生产不同的服装，从原材料采购、服装设计、染色、裁剪、到成品加工有很多的环节。看似十分的复杂，但是，认真梳理的话，其实有很多的环节是类似的，有共同特性的，比如：颜色、纽扣、领口等等。

我们可以把每天销售的服装，比如女装的销售数据采集回来，就可以知道每天销售最多的女装的款式是什么？颜色是什么？纽扣类型？纽扣颜色？领口式样？有否飘带？......等等。把那些数据分解后合并起来，更加专业化，并且将它们独立去维护。设计师可以根据根据这些分门别类的数据迅速的设计出明天（近期）将会流行的款式、颜色等等，预计的投放量，投放地区等等......

有这样一家服装企业每年推出数万种款式，而且几乎没有库存积压。它就是这样做的。这家企业叫做ZARA。

这种分门别类的数据，还可以用来给上游厂家使用，使他们更方便的设计和生产流行的纽扣，流行的布料，流行的颜色等等。

把那些不同的数据面向客户，使客户体验和使用不同的数据，使它们独立出来，这就是数据平台化的思路。

数据的平台化就是把那些有共性的数据资源放在在一起，然后把那些面向客户的数据价值独立出来。不再是混在一起，更加的清晰。

这就是数据的平台化。

数据仓库、数据平台、数据湖其实就是这样一个平台，它通过ETL将采集到的数据，通过E（采集）汇聚在一起，然后通过T（转换）统一做转化，再通过L（上载）统一入库。然后进行分层处理建模，最终实现数据的共享，满足不断丰富、变化的数据分析、挖掘类需求。

数据治理是帮助企业更好的建立这样一个数据存储和共享的工具和服务。

由此可见，数据仓库等完成的整个数据平台化的过程，就是一个从数据到数据的循环，它的出发点是数据，结束点也是数据。

这也是很多企业IT部门要上数据仓库等平台，和要上数据治理等工具和服务的时候，总是强调这是一把手工程。为什么呢？因为它们不是从业务出发的，所以没有业务部门为它们背书。这钱对老板来说就是，其他企业都在建，我们不建设好像也不行。但是，建设了对业务有何帮助呢？这个问题得绕上360圈才能扯上一些关系，而且似乎还挺勉强。

数据中台的思路是业务化，他是从业务为出发点的。

还是拿服装生产厂为例。例如，服装设计师团队如果也要像ZARA一样每年设计几万套服装，而且还要确保大概率是畅销的产品，它需要怎么做呢？

设计师需要采集到更多更为仔细的数据，比如：今天的颜色的客户选择排序；纽扣的大小、数量、排列、颜色、类型；领口的开口形状、大小；有没有蕾丝；袖子的长短，宽松等；后背的开口、大小、形状等；布料的质地，销售的地区、数量等......等等，这些数据可以帮助设计师迅速的获得一个十分接近的当天（或近期）流行的服装的款式，他可以用极少的时间，在这些预测流行的服装上添加、裁剪、附加装饰等为修订的方式推出明天的新一款的服装。这种方式，有点像我们软件行业的小步迭代的逻辑体系。

而这种数据的获取并不是原来数据仓库的方式，一般，数据采集在一个企业是由统一的采集运维团队负责的。问题是，这对一般的采集运维团队来说，是非常困难的。

而数据的采集和解析方式直接决定了业务的价值，这是业务人员（我们的例子中是设计师）的能力。

数据中台的业务化特性，是用业务驱动数据的建设，其实是要求打破层级式的数据管理方式，让业务团队直接端到端的完成从业务到数据采集的全过程，业务团队实际承担着产品研发、模型研发、业务算法、数据解析和采集等多种职能，因为只有他们才能理解清楚如何根据新的业务要求来采集全自己所需的数据，从而让上层应用达到业务的要求。

二、服务化是手段，是业务化的前提

数据中台的数据的服务化绝不仅仅是单一的API形态。

业务分析的灵活性和数据维度的无限性，决定了不可能封装出所有的数据服务API。

数据服务化是广义的服务：提供的数据能够被前端业务人员或其他应用系统快速方便的使用或调用、共享。

数据服务方式可以归纳为：数据模型、数据服务和数据开发和探索。

1、数据模型是数据服务的基础，包括：

基础模型：实现数据的标准化

融合模型：实现多源异构数据的整合，包含汇总、关联和解析

挖掘模型：具有共性的偏应用的挖掘模型，以便开放给其它人使用

2、数据服务：数据模型按照应用要求进行服务封装，通常说的API就是其中的一种方式。值得注意的是，市面上很多的采集、汇总、报表、BI、ETL等工具真心不是数据中台，不管他们怎么包装和宣传。判定方法很简单，如果它只是提供呆板僵硬的界面，没有API等服务封装，那么，它就是一个应用！

大数据不实现数据服务化，那么业务化就是空中楼阁了，大数据也就很难规模化和实现变现了。

数据服务化的封装是数据中台的一个难点，源于OLTP的变化有限。

3、数据开发和探索：前端个性化的要求倒逼数据中台必须能提供数据开发和探索的服务，包括：标签库（DMP，用户基于标签的组装，快速形成客户群，一般面向业务人员），数据开发平台（用户基于平台访问到所有的数据，进行可视化开发，一般面向SQL开发人员），应用环境和组件（技术人员自主打造个性化数据产品）。

数据中台把能复用的数据模型，变成一个数据的能力平台，保证数据质量和一致性，加速从数据到价值的转换过程。

三、开放化是价值体现

开放是数据中台价值的体现，开放应遵循以下原则，如图示：