搞数据的都知道，阿里发明了数据中台，然后“中台”的概念立马成为了国内大部分企业争相追逐的热点。差距还不错，很多机构忙着拆中台。中期虽然还没有到让人厌烦的地步，但总的来说，已经没有那么火爆了。发现网上也有很多分析的文章，但大多都是长篇大论，表述过于技术化。今天我就用最流行的话给大家解释一下。首先解释一下中台的概念。首先，无论是数据中台还是业务中台，都是一种中台。中台的职责是将共性抽象出来，形成通用的服务能力。数据中心就是将数据处理能力的共性抽象出来，形成通用的数据服务能力。数据中心以数据为核心，包括数据存储、数据计算、数据分析等，这些能力也很常见。比如数据中心平台提供的用户画像能力，我们可以在各个领域使用同一套解决方案。如上图所示，业务中心和数据中心之间存在连接。业务中心产生数据，数据中心对业务中心产生的数据进行处理，然后挖掘数据的价值，反馈给业务中心，形成数据闭环。基础设施层提供更底层的服务能力，如可观察性、CICD、容器、服务治理等，以支撑各类中台。中台除了数据中台和业务中台，还应该包括AI中台。公共服务前台应用程序。中泰结构是否合理？说实话，中泰的结构还是比较合理的。在前台和后台中间夹着一个中间平台，屏蔽后台的数据存储，响应前台不断变化的需求。前台跟界面走，天生不稳定。总是有各种各样的数据请求，这是不可避免的。后台主要负责数据的存储，对不同形式和规模的数据进行适当的组织。大数据过于动态，需要一定程度的稳定性。如果前台的所有请求都需要后台直接来做，那后台管理的东西就太多了。从某种程度上说，响应灵活的请求和定期存储数据是两个有着不同优化目标的需求。如果同一个团队在同一套硬件上同时处理这两件事，很容易出现精神分裂症。此外，后端由许多前台共享。如果直接向前台提供灵活的数据服务，各前台之间的耦合度可能会变高，维护成本会立即急剧增加。同样，把这些数据处理放在前台也不合适。一方面，它不安全。另一方面，前端团队忙于让界面看起来更好用更流畅，没有太多时间考虑数据。有一个中间平台会好很多。后台可以专心管理存储，前台可以专心管理接口。中台负责拉平前台和后台之间的差距。分工明确，各司其职，效率自然会提高。既然结构合理，为什么做不下去呢？原因有很多，但大部分都不在重点上。因为说这些话的人大多不写代码，而写代码的人大多轮不到说话的机会。根本原因是业界还没有准备好让数据中心落地的技术！中台为前台提供数据服务。什么是数据服务？就是接收到请求后，返回一些合适的数据，那么如何获取返回的数据呢？计算就是把数据库在后台做的事情搬到中台。那么，你想让我用什么技术来写这些计算代码呢？爪哇？你在开玩笑吧？写一个小组总结需要几百行。你让我怎么提高效率？并想快速响应前台的变化？收听几天，下周见。中台要做的工作也是之前数据库做的，而且大部分都是结构化数据相关的计算。但是Java等高级语言基本没有有用的结构化数据计算库。几句SQL就能完成的工作，现在需要成百上千行Java代码。代码长，不仅难写，而且容易出错。而且，Java程序员的成本也相当高。效率没有提高，钱却花了，何必呢？不过好像有些大厂把中台架构实现的很好。这怎么解释呢？可能是大厂人才多，Java代码积累丰富，做这些计算比较容易。而且，说得客气一点，这些互联网巨头虽然体量大，但业务复杂度远不及传统行业。大厂能做的，你不一定能做。如果我们不需要Java，我们可以继续使用SQL吗？那我们就得在中台放一个数据库，从后台搬一堆数据到中台。应该移动多少数据？好像所有的数据都可能用来计算，所以必须把整个后台数据搬走。但这东西还能叫中台？不就是把后台挪到一个位置吗，就是吃的满满当当的。当没有独立于数据库、集成嵌入式、简单方便、丰富强大的支持多数据源的结构化数据计算能力时，数据中心只是一个结构美好的幻想，却无法实现。强行上中台，除非你的业务足够简单，否则只会增加开发成本，降低效率。灵活性一点也没有增加，反而麻烦很多。数据中心受限于计算能力。数据中心的合理架构才能真正发挥作用，需要具有上述特点的计算引擎。
