“数据中台”的再思考

带着这个观点，我们重新解读两个故事。在“游戏公司”的故事中，业务中台是指企业能力层面的中台，“中”是指所属部门在组织架构的位置。“变速齿轮”的故事，符合我们在系统设计方面的经验，更适合指导企业架构层面的中台系统建设。

两个结论都是正确的，但不在同一个平面，我们不必将基础设施拉进来凑数。

本文的后续讨论将从这个两个层面展开。

从企业能力层面，“数据中台”与前台构成了二元架构，各自归属于具体经营业务部门和共享能力主管部门，本文将其称为“数据中台”。从企业架构的层面， 如果把“数据中台”建设成一个巨大的系统，显然违背了“变速齿轮”的思想，要适应前台的灵活变化，必须进一步分拆，就出现了“数据中台系统”和若干“数据后台”系统。我们把这个层面的“数据中台系统”简称为“小中台”

企业能力层面（二元架构）

从架构的视角看，前台与“大中台”组成的二元架构实质就是前后台架构。

前台系统是直接实现业务需求的各类数据分析系统，或者联机系统的查询分析模块，前台系统紧随业务而变化。中台归属于科技部门，从而降低与业务部门的关联性，可以从企业全局视角进行优化。中台的核心思想就是复用，将不同业务场景的通用能力抽离出来，下沉到一个共享平台，更好的支持前台系统的灵活变化。

这种架构思想的经典案例就是数据仓库。

传统数据仓库（数据中台 1.0）

理论上，数据仓库实现复用的核心是企业数据模型，以咨询公司的先验模型为基础，在业务发展过程中逐渐提炼出共性、稳定的需求丰富数据仓库，消除加工逻辑和存储上的冗余；而数据集市实现个性化、易变的需求。从这个意义上来讲，数据仓库就是数据中台的 1.0 版本。

不幸的是，工程实践中存在很多问题。首先，判别业务稳定与否是个不小的挑战，充斥着各种主观标准，难以在大范围达成共识；其次，即使那些稳定的需求，当其成为某个数据集市的核心需求时，考虑到对该集市其他功能的支撑作用，将该功能纳入数据仓库意味着整个集市的下沉，因而不具可行性；此外即便是易变的需求，当确认了需求的权威性后，也会出现在集市之间共享的情况，数据集市之间联系也就自然发生了。

由于上述原因，集市规模越来越大，逻辑愈加复杂，横向联系逐渐增多，数据仓库则发展缓慢。

这种架构最大的问题不是集市体量大，而在于它的不稳定性。因为其直接服务于业务部门，任何组织架构上的调整都会带来集市的合并分拆，甚至在组织架构不变的情况下，部门经营策略的更改也会成为新建或分拆系统的动力。

当某类产品成为企业发展重点时，会出现为产品建立独立分析系统的诉求，例如互联网信贷产品分析系统；当某个渠道的关注度提升时，又会希望按照渠道汇总各类信息，例如对电子银行分析系统；再或者对某个客户群体的重视，将催生以客户特征为边界的集市，例如私人银行客户分析系统。

一个问题常常困扰我们，银行到底应该建设多少个数据集市? 我想，正如康威定律的核心思想，“组织形式等同系统设计”，这个答案永远都在随着组织形式而改变。作为架构师，我们不希望存在复杂而需求易变的系统，因此我们选择接受易变性，寄希望于降低系统的复杂度，阿里所提出的“大中台、小前台”成为一个不错的选择。

互联网数据中台（数据中台 1.5）

最初，互联网企业和很多中小规模的传统企业一样，是没有数据仓库的，往往以效率优先的原则建设特定系统满足数据应用需求，这类系统实质就是“数据集市”。

企业规模扩大，“数据集市”数量不断增加，这时重复加工、口径不统一、成本不经济的问题就会浮现出来，当然最更要的是对快速交付的期待。

2017 年，阿里提出的数据中台 [4] 维持了数据仓库架构的基本二元结构；垂直数据中心、公共数据中心、萃取数据中心是在数据处理逻辑上的分层，与传统数据仓库的分层有相近之处；统一数据服务中间件（OneService）是新增部分，体现了 DT 时代对数据价值的重视，需要更直接的方式使用数据。

网上已有很多对阿里数据中台的解读，这里不再赘述，只重点谈下一对 OneService 的理解。通过公开资料可知，OneService 并不是单纯的 API 服务，同时涵盖了 SQL 查询、数据批量等方式。是否保留这些方式，我有一些不同的理解。

首先是数据批量方式，从数据仓库的实施经验来看，集市通常会有自我闭环趋势，力图减少对其他系统的依赖，其积累数据后必然进一步扩充功能，批量数据集成方式事实上是能够为前台的膨胀提供了基础。约束“小前台”最操作性的方式，AIP 服务调用方式替换数据集成，由于数据不落地，前台不易积累数据以独自完成业务需求，必须依赖中台的支持。

再来看 SQL 查询接口，其主要用于支持 BI 工具。SQL 直接体现了服务端的数据表结构，与物理模型设计和具体技术产品形成紧密耦合，降低了“大中台”后续发展的弹性，甚至造成对单一数据库产品的绑定。使用 API 可以降低这种耦合，付出的代价是弱化了前台系统对数据加工能力。随着 Json 接口成为 BI 工具的标准功能，API 替代 SQL 接口也具有很高的可行性。

因此，我认为依赖统一的 API 服务打通前台与中台的联系，前台系统之间不再有直接联系，整体保持星型架构，能够保证“大中台、小前台”架构的持续性，如下图所示。

企业架构层面（三层架构）

二元数据中台架构还停留在概念层面，复杂问题只是被转移到 “数据中台”，并没有得到解决。正如“变速齿轮”论，前后台的二元架构难以平衡灵活与稳定的矛盾。我们进入架构层面的讨论，其拆分为三层架构，如下图所示。

“服务联邦层”位于三层架构的中间地带，是我们前文中提到的“数据中台系统”，即“小中台”。“小中台”整合“粗粒度服务”支持前台系统。

数据后台提供稳定的“细粒度服务”作为“小中台”的整合素材，我将一类主要的服务提供方称为“数据服务群”。“数据服务群”是数据服务的集合，业务相关性是一个重要整合维度，但同时也可以根据性能需求使用不同的底层技术平台而剥离为不同的服务群，服务群本身是有落地数据存储的，不同服务群之间可能存在一定冗余，比如客户、机构等数据。同时数据仓库（强模型数据）、数据湖（弱模型数据）、文本检索系统（非结构化数据）、历史数据查询系统（冷数据），也可提供一般性能需求的服务，与“数据服务群组”共同构成了数据后台。技术平台仅提供支撑作用，不归属于中台或后台。

技术可行性

“小中台”的主要工作是进行数据集合运算，实现原有集市沉降下来的业务逻辑。“小中台”与数据后台基于 API 进行异步非阻塞通讯，目的是为了解耦具体技术产品和数据模型。“小中台”要基于后台服务返回结果集完成各类 SQL 等效操作，有些同学可能会怀疑技术可行性。其实，今天 NewSQL 数据库广为所采用的数据库引擎与 KV 存储引擎分离的设计模式，同样使用了服务接口进行通讯。“小中台”不涉及数据的写入、更改，几乎没有事务处理，技术难度会大幅降低。

压缩 SQL 使用范围

相比阿里的数据中台，本文提出的整体架构最大程度降低了 SQL 的使用。一个敏捷的架构必然是可治理的，而数据仓库难以治理的顽疾正在于以 SQL 为核心的 ETL 工作。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

俗话说，好学者临池学书，不过网络时代，对于大多数的我们来说，我倒是觉得学习意识的觉醒很重要，这是开始学习的转折点，比如看到对自己方向发展有用的信息，先收藏一波是一波，比如如果你觉得我这篇文章ok，先点赞收藏一波。这样，等真的沉下心来学习，不至于被找资料分散了心神。慢慢来，先从点赞收藏做起，加油吧！

另外，给大家安排了一波学习面试资料：

以上就是本文的全部内容，希望对大家的面试有所帮助，祝大家早日升职加薪迎娶白富美走上人生巅峰！
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
上就是本文的全部内容，希望对大家的面试有所帮助，祝大家早日升职加薪迎娶白富美走上人生巅峰！
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！