搞数据的都知道，阿里发明了数据中台，然后“中台”这个概念就马上成为了国内大多数企业趋之若鹜的风口，真正实施后却发现中台与数据平台、数据湖等项目大差不差，又有好多机构开始忙着拆中台了，中台虽然还没到人见人烦的地步，但总体来讲已经不那么受待见了。
我发现网上也有很多文章进行分析，但大多是长篇大论，表述也过于技术，今天我就用最通俗的话跟大家解释一下。
首先，先解释一下中台的概念
首先，不论是数据中台，还是业务中台，都属于中台的一种。而中台的职责在于抽象共性形成通用服务能力。
而数据中台就是抽象处理数据能力的共性形成通用数据的服务能力。数据中台侧重于数据，包括数据存储，数据计算，数据分析等，这些能力也是具备共性的。比如数据中台提供的用户画像能力，我们可以在各个领域使用同一套方案。
如上图所示，业务中台和数据中台又存在联系。业务中台产生数据，数据中台处理业务中台产生的数据然后挖掘数据的价值，并反馈给业务中台，形成一个数据闭环。
基础设施层，提供更加底层的服务能力，比如可观察性，CICD，容器，服务治理等，支撑各种中台。而中台除了数据中台和业务中台，还应该包括AI中台。共同服务前台应用。
中台的架构合理吗
老实说中台这架构是挺合理的。在前台和后台之间夹一个中台，屏蔽后台的数据存储，应对前台没完没了的变化需求。
前台跟着界面走，天生就稳定不了，总是有五花八门的数据请求，这是必然的事情。后台应该主要负责数据存储，把不同形式和规模的数据以合适的方式整理好，大数据倒腾起来动静太大，要求有一定的稳定性。如果前台的请求都要求后台直接做，那后台管的事就太多了。
应对灵活请求和规整数据存储在一定程度上是两个优化目标不同的需求，同一个团队在同一套硬件上同时对付这两件事，容易发生精神分裂。
而且，后台是被许多前台共享的，如果直接向前台提供灵活数据服务，还可能导致各个前台之间的耦合程度变高，维护成本立即陡增。
同样的，把这些数据处理放在前台也不合适，一方面不太安全，另一方面，前台团队也是忙着让界面如何更好看使用更流畅，没太多工夫琢磨数据的事情。
有了中台就好很多了，后台专心管存储，前面专心管界面，前后台之间的差距由中台负责抹平。分工明确，各司其职，效率自然提高。
既然架构合理，那为什么搞不下去?
原因呢，说啥的都有，不过大都没说到点子上。因为说这些话的大都不写代码，写代码的又大都轮不到来说话。
根本的原因在于，业界就没有准备好能让数据中台落地的技术!
中台向前台提供数据服务。啥是数据服务呢?就是收到请求后返回一些合适的数据回去，那咋弄出返回的数据呢?计算呗，就是把以前在后台让数据库做的事搬到中台来呗。
那么，你打算让我用什么技术来写这些计算代码呢?
Java?开玩笑呢?写个分组汇总就好几百行，你让我怎么提高效率?还想迅速应对前台变化?这代码我连写带调得好几天，下礼拜再见吧。
中台要干的这些任务，也是之前数据库干的事，绝大多数都是结构化数据相关的计算。而Java这些高级语言基本上没什么好用的结构化数据计算类库，原先用SQL几句话能搞定的事，现在用Java就得几百上千行代码了。代码长了，不仅难写，还容易出错。而且，Java程序员的成本也挺高啊，效率没提高，钱倒是花多了，那又何苦?
但是，貌似有些大厂的中台架构实施得不错，这又咋解释?
可能是大厂人才多，Java代码积累丰富吧，搞起这些计算就容易一点了。而且，悄悄地说一句，这些互联网大厂虽然大，业务复杂度却远远赶不上传统行业。大厂能搞得通的事，你可未必能搞得通。
不用Java，那咱还继续用SQL行不?
那得在中台也放个数据库，把一堆数据从后台搬出来再移到中台来。搬多少数据呢?貌似所有的数据都有可能用于计算，那得把整个后台的数据都搬过来。然则这玩意儿还能叫中台?不就是把后台挪了个位置而已，纯粹吃饱了撑的嘛。
在没有不依赖于数据库的、可被集成嵌入的、支持多样数据源、简单方便且丰富强大的结构化数据计算能力之时，数据中台就是空想，架构好看，但无法落地。强行上中台，除非你的业务足够简单，否则就是只会让开发成本上升而效率下降，灵活性一点没增加，麻烦事却一大堆。
数据中台受制于计算能力。必须要具有上述特征的计算引擎之后，才能让数据中台的合理架构真正发挥作用。
