数据中台咋就从“小甜甜”变成了“牛夫人”？

6 月 29 日的最新消息，阿里巴巴集团融合原数据中台、业务中台、客服系统、供应链服务等多个部门，创立企业数智服务的新品牌“羚羊”——一家 DAAS（数据智能即服务）厂商。

这一消息让很多业内人士产生疑问：此番另立新王的举措，是不是暗示阿里即将把数据中台 shutdown。

回顾数据中台的命运，典型的高开低走令人唏嘘：

2015 年，阿里提出“大中台”的数据中台战略；

2019 年，史称数据中台元年，各大厂及中台服务商“大兴”数据中台；

2021 年，各大厂陆续开始拆中台。

为什么仅仅 6 年时间，数据中台咋就从“小甜甜“变成了“牛夫人”？数据中台是不是真的一无是处？数据中台又为什么会“败走麦城”？笔者在这篇文章中将从这两方面阐述一下。

一、数据中台是不是真的一无是处？

首先，笔者在这里必须为中台的概念点个赞。从技术上讲，在前台和后台之间加上一个中台，这种架构的设计是非常合理的。笔者总结几点理由如下：

理由 1：中台既可以屏蔽后台的数据存储，又可以应对前台五花八门的需求变化。如果前台的请求都交给后台来做，后台负责的事情太多太杂导致效率低下。

理由 2：前台和后台一定程度上是两个优化目标不同的需求，同一个团队在同一套硬件上同时对付这两个平台，容易导致精神分裂。

理由 3：多个前台共享同一个后台，如果后台直接向前台提供灵活的数据服务，可能导致各前台之间的耦合程度太高，维护成本可能将倍增。

理由 4：如果把数据处理置于前台也不合适，首先是不安全，其次前台团队应用体验，例如界面更好和使用更流畅，没太多工夫琢磨数据的事情。

笔者认为，中台可以让后台专注于数据存储，前台专注于应用体验，前台和后台间的差距由中台负责抹平。这样的设计，显得分工明确各司其职，效率自然能提高。

二、数据中台为什么会“败走麦城”？

既然中台的架构这么合理，为什么业界都搞不下去呢？

因为数据中台还只是一个概念和方法论，但是在具体落地层面做得并不太好。

圈内人怎么分析的都有，但笔者认为很多观点都没说到点子上。因为数据中台概念和方法论本身没问题，关键问题就在落地上。这里，笔者从 coding 角度做一个分析。

用一句话来说就是：业界根本就没有准备好让数据中台落地的技术！

首先确认一点，数据中台的核心价值是什么？灵活快捷地向前台提供数据服务，即是收到前台请求后从后台返回一些合适的数据给前台。

下一步就看具体怎么返回数据呢？理想的做法是计算，就是把以前在后台让数据库做的事搬到中台了完成。紧接着，用什么技术写这些计算代码呢？下面笔者逐一分析给您看。

选择 1：Java

开玩笑呢？写个稍复杂些的分组汇总就可能好几百行，怎么提高效率？还想迅速应对前台的变化？这些代码连写带调都要好几天。中台的任务，也是数据库之前的任务，绝大多数都是结构化数据相关的计算。而 Java 这样的高级语言基本没有好用的结构化数据计算类库。原先用 SQL 能解决的事，现在用 Java 就需要几百甚至上千行代码。代码太长，不仅难写还容易出错。而且，Java 程序员的成本挺高。这就可能导致，数据中台效率没见提高，成本还越来越高了。

选择 2：Stream

可能有人会说，Java 支持 Stream 以后这些问题就都能解决了。但是，Stream 看着挺好，实际用起来完全不是那么回事。Stream 的中间计算结果和最终结果都要事先定义，而结构的定义和赋值都很麻烦。如果不定义，阅读和使用又不直观。

而且 Stream 虽然支持 Lambda 语法，但接口规则比较复杂，代码没短多少但阅读障碍却显著增加。Stream 的结构化对象如 record\entiry\Map 都不方便，根本原因还是在于 Java 缺乏专业的结构化数据对象，缺少来自底层的有力支持。

选择 3：Kotlin

与 Stream 类似，Kotlin 计算能力不足，也是缺乏专业的结构化数据对象，无法支持动态数据结构、难以真正简化 Lambda 语法、无法直接引用字段等。同时,Kotlin 也缺乏一些重要的基本函数，比如关联计算，开发者仍然要硬编码完成计算，对于多个基本计算组合而成的业务算法，开发过程仍然困难。

但是，有些大厂的中台架构实施得不错，这又怎么解释呢？笔者认为，可能是因为大厂人才多，Java 代码积累丰富吧，实现这些计算就容易一点。但是，互联网大厂虽然规模大，但业务复杂度却远远赶不上传统企业。所以，互联网大厂能跑得通，传统企业未必能跑得通。更何况，互联网大厂已经开始拆中台了？

选择 4：SQL

Java、Stream 和 Kotlin 都行，用 SQL 行不？可以，不过得在中台放个数据库，把一堆数据从后台迁移到中台来。迁移多少数据呢？貌似所有的数据都有可能用于计算，那得把整个后台的数据都搬过来。

然而，这还能叫中台吗？不就是把后台挪了个位置而已嘛。在没有不依赖于数据库、可被集成嵌入、支持异构数据源、简单方便且丰富强大的结构化数据计算能力时，数据中台只能说个空想，架构好看但无法落地。

有人说，强行上中台可以吗？除非企业的业务足够简单，否则只会让开发成本上升而效率下降——灵活性一点没增加，麻烦事却一大堆。

综合来看，数据中台必须具有上述特征的计算引擎之后，才能让数据中台的合理架构真正发挥作用，才能让数据中台真正的落地、开花、结果。