数据中台的原罪

现在关于数据中台价值的探讨已经很多了，但凡事有利必有弊，今天就反其道而行之，谈谈数据中台的原罪，知道了这些“罪”，有利于你权衡利弊，做出正确的选择，这对于数据中台的发展很重要。
 

 

1、数据中台有“名不正言不顺”之嫌

 

中国儒家讲仁，但如果让你对仁下个清晰的定义，估计没人讲得清楚，这体现了中国哲学跟西方哲学一个区别。

 

康德说：“我追求一切概念都有清晰的定义，一切推理都不允许有大胆的跳跃、而力求用合规律的原则、严格的证明，勾画出研究领域的整个范围、部门划分和全部五遗漏的内容，并对未知部分立下清晰的界标。”

 

概念的模糊性很容易造成类似中国哲学的问题，比如《论语》里孔子提出的：“君君、臣臣、父父、子子”，本来孔子的意思是每个岗位的人做好自己该做的事情，校长要像校长，教授要像教授诸如此类。

 

但汉朝的董仲舒为了政治需要，提出了三纲五常，把孔子这段话曲解成了“君为臣纲，父为子纲，夫为妻纲。” 新文化运动的时候，孔老夫子就被批得很厉害，实在是很冤枉。

 

老外没有中台的说法，中台这个词就有那么点中国哲学的味道。

 

阿里2015年去欧洲的一家公司SuperSell参观后提出了中台战略，数据中台、业务中台，技术中台等这些词也被顺势创造出来，我相信这些概念的提出，是各专业领域推进自身工作的需要，没人会在概念的严谨性上去下功夫，差不多就得了。

 

但既然这些词已经被炒起来了，就有了利益，有了利益就有了江湖，所有各方都会由于这个利益来诠释自己对于中台的理解，这就形成了概念乱象，一千个读者眼中有了一千个哈姆雷特，你可以说中台这个词给了业界无限的想象空间，但模糊性也带来了很多问题。

 

比如我们说中台的本质是共享复用，但这仅仅是一种理念，不能当饭吃，一般还需要化作具体的行动吧，但没人说得清楚落地共性复用理念的标准动作是什么，比如就数据中台来讲，数据领域哪些东西可以共享复用呢？

 

往大了讲，平台本来就有这个性质，工具也有这个性质，数据也可以有这个性质，数据仓库本身似乎也是为共享复用构建的，那么对于已经建完成数据仓库的企业，干嘛还要建数据中台呢？数据中台到底带来什么具体的增量价值？

 

很多业务和技术发展到一定阶段都会有白皮书，至少还是有中立的组织想标准化一下的，但中台没有，更别提数据中台了，偶偶有几本数据中台的书想尝试一下，但难说对全行业有什么指导意义。

 

我能想到的破解的方法只有一个，回归业务本身，看看做哪些优化能提升数据赋能的效率，如果能力沉淀的价值未来可期，那就去做，比如API，这就是数据中台；如果能力沉淀的价值还不大，就没必要强求。

 

2、数据中台违背奥卡姆剃刀原理

 

数据仓库是OLTP发展到一定阶段自然演化出来的，但数据中台不是，很多企业的数据仓库被动要求升级成数据中台，然后强制推进复用共享，或者用新概念来装点门面，显然这样的数据中台是无法创造出超越数据仓库的新价值的。

 

数据中台在原始数据和应用数据中间增加了一层数据实体，流程增加了，信息衰减了，连接变弱了，这就需要施加更多的外力来进行补偿。

 

因此，如果这些新增的实体无法创造出增量价值来弥补由于引入了新的实体后带来的成本增加，这就违背了奥卡姆剃刀原则，即“如无必要，勿增实体”，直白的解释就是“切勿浪费较多东西去做，用较少的东西，同样可以做好的事情”。

 

数据中台如果没有实际超越数据仓库，那么就无法躲开奥卡姆剃刀的魔咒，为了进行对抗，我们得干点数据中台该干的事情，比如API，这是每个数据中台运营者要想清楚的事情，你得有些使命感，做出一些不一样的有价值的东西。

 

3、数据中台需要巨大的成本投入

 

数据中台希望用共享复用的理念来沉淀能力，然后基于能力来更快的支撑应用创新，但快速支撑应用创新的前提是要有足够多的已经沉淀出来的能力。

 

可惜数据中台伊始，根本就没有什么拿得出手的能力，大家喜欢用数据中台的结局来表达其价值，但少有人能真正理解数据中台构筑能力过程的艰辛，不知道前期要付出多大的代价。

 

就好比以前说去IOE，说要自主掌控，老板以为可以降低IT投入了，但其实完全错了。

 

最近业务方需要我们开放一批原始表，我说：“你能不能告诉原始业务需求，数据中台用融合模型来支撑？” 业务方说：“这个你不用管，我等不了你修改融合模型，到时改来改去沟通成本也高，模型我们可以自己建。”

 

为了兼顾能力沉淀和响应速度，我就说：“那能不能这样，我安排多一倍的资源来支撑你们的需求？” 业务方后来妥协了，但这个多出的资源需要公司买单。

 

无论从哪个方面看，运营数据中台都要付出巨大的代价，包括建章立制、组织构建、能力打造、迭代优化等等。

 

4、数据中台的投资风险还是很高

 

数据中台概念屹立不倒，是因为我们坚信数据中台沉淀的能力在未来一定有机会创造更多的价值，这足以弥补前期的投入，但从潜力市场、回报周期、价值产出等要素看，企业投资数据中台的确是门高风险的生意。

 

第一、狭义的数据中台仅限于数据模型和服务，这些数据模型和服务打上了企业和业务的烙印，因此很难复制到其他领域，这实际限制了数据中台的投资回报率。

 

现在兜售数据中台的企业卖得并不是数据模型和服务，而是工具平台，这并不属于数据中台的核心内容范畴。

 

第二、参考大厂，数据中台三年才能小成，这还是在人才充足的前提下，因此，一般企业并不一定有足够的耐心。

 

正如凯恩斯经济学派在批驳市场学派所谓的自由市场最终会实现资源的最优配置这种观点所说的那样：“长远是对当前事务错误的指导。从长远看，我们都已经死了。”

 

第三、数据中台概念不清，对于企业的文化、组织、机制、流程、数据、平台又有很高的要求，输入和产出的关系也不是很明显，这也是投资比较忌讳的。

 

当然企业对于自己的投资不一定要那么斤斤计较，毕竟不是简单的买卖，但心里还是要有所权衡。

 

5、数据中台的能力标准化有点难

 

15年前的数据仓库时代，业界曾经提出过一个非常超前的概念：数据封装，就是把数据封装成API供业务调用，类似于编程语言中的函数。

 

比如把某种即席查询封装成一个API，而不是跟应用强捆绑，我想这是最早的数据中台的原型吧，但我后来对数据封装的可复用性提出了质疑。

 

数据跟功能不同，数据的指标和维度可以成千上万，组合之后更是不胜枚举，也许日常的函数1000个就可以满足基本的编程需要的，但数据封装呢，我不知道要多少数据封装才能满足一个数据分析应用的需要，大多还是靠定制化取数满足吧。

 

函数的贡献来自于所有编程者，这个超越了行业，因此它能够快速更新迭代，但数据封装很难超越行业，能贡献经验的也仅限于企业的某些人，我一直觉得数据封装出来的功能可能等不到规模化用的时候，就已经被新的业务淘汰了，或者企业根本没有那么多标准化能力复用的场景。

 

正是这个原因，也许只有巨型的企业才可能在数据中台的能力标准化方面获益。

 

6、数据中台导致了系统的脆弱性

 

现在云原生如火如荼，微服务，容器化，DevOps在保证业务中台敏捷的同时，也确保其连续性。

 

数据中台并没有吃到什么连续性的红利，对于大多数公司，数据中台一般是没有容灾的，也许连应急也没有，因为对数据的容灾就意味着成倍的投资增加，这在一般的公司无法实现。hadoop虽然有数据三备份的策略，但其对于人为操作失误、数据逻辑错误也是无能为力。

 

数据中台的目标是把分散的数据能力集中化、共享化，实现其能力“一点发布，全部共享”的理想，但在数据中台连续性问题无法彻底解决之前，集中化的数据中台也带来了集中化的风险，比如一旦集中化的数据被删除，那么对于企业应用的影响是全方位的。

 

数据中台做的越好，共享能力越高，风险就越高，这就是悬在数据中台连续性上的“达摩克里斯之剑”，也就是“一点故障，全面影响”。

 

自己就曾经历过这么一个hadoop事故，换做现在，估计就是灾难了。

 

我们有两个GIS应用，一个GIS应用由于历史原因自己采集了很多数据，另一个GIS应用则是基于数据中台提供的数据构建的，某天运维人员误删了数据中台的所有GIS相关数据，hadoop无法恢复，幸亏另一个应用有重复数据的存在，才避免了核心数据的丢失。

 

所谓祸兮福之所倚，福兮祸之所伏。

 

数据中台的确有很大的价值，但也隐含着不少风险，我们以前谈其优点多了，缺点谈少了，这不是实事求是的作风，更可怕的是，也许我们自己并不知道这些风险的存在。

 

来源：大鱼的数据人生

 

作者：讨厌的大鱼先生