不知几年前，数据中台这个概念开始变得很热闹，各个机构都要上中台，中台架构意味着先进，人见人爱，也冒出许多以中台为业的软件公司。然而，大概从去年中开始，听说又有好多机构开始忙着拆中台了，中台虽然还没到人见人烦的地步，但总体来讲已经不那么受待见了。
这是怎么回事？
老实说，中台这架构是挺合理的。在前台和后台之间夹一个中台，屏蔽后台的数据存储，应对前台没完没了的变化需求。
前台跟着界面走，天生就稳定不了，总是有五花八门的数据请求，这是必然的事情。后台应该主要负责数据存储，把不同形式和规模的数据以合适的方式整理好，大数据倒腾起来动静太大，要求有一定的稳定性。
如果前台的请求都要求后台直接做，那后台管的事就太多了。应对灵活请求和规整数据存储在一定程度上是两个优化目标不同的需求，同一个团队在同一套硬件上同时对付这两件事，容易发生精神分裂。
而且，后台是被许多前台共享的，如果直接向前台提供灵活数据服务，还可能导致各个前台之间的耦合程度变高，维护成本立即陡增。
同样的，把这些数据处理放在前台也不合适，一方面不太安全，另一方面，前台团队也是忙着让界面如何更好看使用更流畅，没太多工夫琢磨数据的事情。
有了中台就好很多了，后台专心管存储，前面专心管界面，前后台之间的差距由中台负责抹平。分工明确，各司其职，效率自然提高。
既然架构合理，那为什么搞不下去？
原因呢，说啥的都有，不过大都没说到点子上。因为说这些话的大都不写代码，写代码的又大都轮不到来说话。
根本的原因在于，业界就没有准备好能让数据中台落地的技术！
中台向前台提供数据服务。啥是数据服务呢？就是收到请求后返回一些合适的数据回去，那咋弄出返回的数据呢？计算呗，就是把以前在后台让数据库做的事搬到中台来呗。
那么，你打算让我用什么技术来写这些计算代码呢？
Java？开玩笑呢？写个分组汇总就好几百行，你让我怎么提高效率？还想迅速应对前台变化？这代码我连写带调得好几天，下礼拜再见吧。
中台要干的这些任务，也是之前数据库干的事，绝大多数都是结构化数据相关的计算。而Java这些高级语言基本上没什么好用的结构化数据计算类库，原先用SQL几句话能搞定的事，现在用Java就得几百上千行代码了。代码长了，不仅难写，还容易错。而且，Java程序员的成本也挺高啊，效率没提高，钱倒花多了，那又何苦？
但是，貌似有些大厂的中台架构实施得不错，这又咋解释？
可能是大厂人才多，Java代码积累丰富吧，搞起这些计算就容易一点了。而且，悄悄地说一句，这些互联网大厂虽然大，业务复杂度却远远赶不上传统行业。大厂能搞得通的事，你可未必能搞得通。
不用Java，那咱还继续用SQL行不？
嗯，那得在中台也放个数据库，把一堆数据从后台搬出来再移到中台来。搬多少数据呢？貌似所有的数据都有可能用于计算，那得把整个后台的数据都搬过来。然则这玩意儿还能叫中台？不就是把后台挪了个位置而已，纯粹吃饱了撑的嘛。
在没有不依赖于数据库的、可被集成嵌入的、支持多样数据源、简单方便且丰富强大的结构化数据计算能力之时，数据中台就是空想，架构好看，但无法落地。强行上中台，除非你的业务足够简单，否则就是只会让开发成本上升而效率下降，灵活性一点没增加，麻烦事却一大堆。
有一点小例外，国产报表工具通常在一定程度上拥有一些上述的计算能力（更详细解释报表工具的计算能力：不依赖于数据库、可被集成嵌入、支持多样数据源、丰富强大尚有不足但应对常规分组过滤等运算都没问题），如果前台应用主要用来看统计查询结果（统计逻辑和数据源还不能太复杂，否则报表工具的计算能力就摆不平了，还得去写Java或者搬数据），那么搞一个报表工具作为中台是部分可行的，对于这些限定的应用场景确实可以起到提高效率和增强灵活性的作用，所以有些为数不多还能用起来的中台其实就是个报表平台。
数据中台受制于计算能力。必须要具有上述特征的计算引擎之后，才能让数据中台的合理架构真正发挥作用。