机器人|数据中台咋就从“小甜甜”变成了“牛夫人”？安防|商场|ai|创投圈

6月29日的最新消息，阿里巴巴集团融合原数据中台、业务中台、客服系统、供应链服务等多个部门，创立企业数智服务的新品牌“羚羊”——一家DAAS（数据智能即服务）厂商。
这一消息让很多业内人士产生疑问：此番另立新王的举措，是不是暗示阿里即将把数据中台shutdown 。
回顾数据中台的命运，典型的高开低走令人唏嘘：

2015年，阿里提出“大中台”的数据中台战略；
2019年，史称数据中台元年，各大厂及中台服务商“大兴”数据中台；
2021年，各大厂陆续开始拆中台。

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

数据中台从“小甜甜“变成了“牛夫人”
一、数据中台是不是真的一无是处？
首先，笔者在这里必须为中台的概念点个赞。从技术上讲，在前台和后台之间加上一个中台，这种架构的设计是非常合理的。笔者总结几点理由如下：
理由1：中台既可以屏蔽后台的数据存储，又可以应对前台五花八门的需求变化。如果前台的请求都交给后台来做，后台负责的事情太多太杂导致效率低下。
理由2：前台和后台一定程度上是两个优化目标不同的需求，同一个团队在同一套硬件上同时对付这两个平台，容易导致精神分裂。
理由3：多个前台共享同一个后台，如果后台直接向前台提供灵活的数据服务，可能导致各前台之间的耦合程度太高，维护成本可能将倍增。
理由4：如果把数据处理置于前台也不合适，首先是不安全，其次前台团队应用体验，例如界面更好和使用更流畅，没太多工夫琢磨数据的事情。
笔者认为，中台可以让后台专注于数据存储，前台专注于应用体验，前台和后台间的差距由中台负责抹平。这样的设计，显得分工明确各司其职，效率自然能提高。
二、数据中台为什么会“败走麦城”？
既然中台的架构这么合理，为什么业界都搞不下去呢？
因为数据中台还只是一个概念和方法论，但是在具体落地层面做得并不太好。
圈内人怎么分析的都有，但笔者认为很多观点都没说到点子上。因为数据中台概念和方法论本身没问题，关键问题就在落地上。这里，笔者从coding角度做一个分析。
用一句话来说就是：业界根本就没有准备好让数据中台落地的技术！
首先确认一点，数据中台的核心价值是什么？灵活快捷地向前台提供数据服务，即是收到前台请求后从后台返回一些合适的数据给前台。
下一步就看具体怎么返回数据呢？理想的做法是计算，就是把以前在后台让数据库做的事搬到中台完成了。紧接着，用什么技术写这些计算代码呢？下面笔者逐一分析给您看。
选择1：Java
开玩笑呢？写个稍复杂些的分组汇总就可能好几百行，怎么提高效率？还想迅速应对前台的变化？这些代码连写带调都要好几天。中台的任务，也是数据库之前的任务，绝大多数都是结构化数据相关的计算。而Java这样的高级语言基本没有好用的结构化数据计算类库。原先用SQL能解决的事，现在用Java就需要几百甚至上千行代码。代码太长，不仅难写还容易出错。而且， Java 程序员的成本挺高。这就可能导致，数据中台效率没见提高，成本还越来越高了。