银行业“数据中台”的再思考

目录

传说与误解

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

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

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

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

技术可行性

压缩 SQL 使用范围

降低数据存储冗余

结语

---

今天，中台已经成为架构转型的里程碑，从互联网到传统企业谈架构必有中台。虽然各种中台概念层出不穷，但“数据中台”和“业务中台”作为中台概念的起始源头，被视为最纯正的中台，也是企业架构转型的重要目标。

我所在的银行正筹备“数据中台”的建设，为此在内外部组织了多次技术研讨，每个人都有不同的想法，共同点仅限于希望自己的解决方案命名为“数据中台”。

 

我想这种认识的差异是源于“数据中台”尚处在概念萌芽期，需要更多探讨与碰撞。本文借鉴了互联网公司和两家同业银行的案例，尝试对“数据中台”建设思路进行总结，所提出的架构方案仅供探讨，尚未应用于实际系统建设。

 

传说与误解

 

在争论什么是“数据中台”前，我们应该意识到“数据中台”只是解决方案，讨论的关键在于我们希望通过“数据中台”解决什么问题？

 

这里先给答案，在我看来，中台要解决的核心问题是在短时间内搭建或变更前台系统，从而快速响应用户需求、把握市场机会。

 

首先我们梳理下有关“中台”的传说。

作为这一波“中台”概念的源头，第一个传说必须来自阿里。“游戏公司”的传说，大致是这样，阿里的马老师带队参观了一家厉害的游戏公司 Supercell，它有很多成功的游戏产品，其独特优势是能够快速推出新产品，而依靠的就是中台系统。

马老师受到了启发，回到阿里开始推进中台建设，在组织架构层面成立了单独的中台部门即“共享业务事业部”，系统层面建设了用户中心、支付中心等共享服务同时支持淘宝、天猫、1688 等业务条线，最终也实现了快速的前台产品研发。这些中台服务被统称为“业务中台”。

 

通过这个故事，我们可以得出第一个结论。中台应该提供“共享服务能力”，这种共享源于对业务场景的抽象、提炼、沉淀。

 

关于中台的第二个传说是“变速齿轮”，相对技术化和抽象一些。当前的IT 架构通常是由前台和后台组成，前台系统接触用户，后台系统提供基础服务。两者一个需要灵活快速，一个需要稳定高效，两者在变更速率上不匹配，制约了对用户需求的快速响应。中台的诞生衔接了前后台系统，保证后台稳定的同时又支持了前台的灵活。

 

这样我们有了第二个结论，中台意味着了前中后的三层体系架构，三者的变更速率可以实现更平缓的过渡，从而兼顾整个体系的灵活与稳定。

 

但有一个问题始终困扰着我，基于前两个结论，可知是存在“业务后台”和“数据后台”的，那又是指什么呢？这个概念不澄清，体系就是不完整的。

带着这个疑问，我们来看看具体案例。首先是阿里的双中台架构[1]。

 

 

图中标注了组织架构层面的前台、中台和后台，但并没有给出业务后台和数据后台的边界与定义，从字面上看后台与中台的关联性也较弱。

 

民生银行的数据中台体系技术方案[2]给出了上面的架构图，明确了“数据后台”的范围，其涵盖了 Hadoop 平台、实时分析平台等，有点技术平台的味道。

 

农行“薄前台、厚中台、强后台”IT 架构体系 [3] 中对前中后三个层次描述得更为明确，将大数据平台和 PAAS、IAAS 基础设施划入了后台。

 

看过两家银行架构，我们似乎可以得到一个推论，后台是技术平台或基础设施。但这两者通常是与业务无关的，会制约前台业务的灵活性吗？基础设施和技术平台同时支持了前台和中台，在层级并不是一个递进关系呀？这个分层似乎有点奇怪，有点牵强。

 

反复思考后，我认为阿里提出的“用户中心”、“支付中心”所代表的“业务中台”是指企业组织层面的中台，更准确说法是“由业务中台部门所主导的业务能力共享平台”。

 

前台部门直接面对用户和创造利润；阿里“共享服务事业部”更多参与到了业务中，非常适合中台的定位。而后台主要是辅助作用，通常也就不会受到用户需求的影响，企业甚至行业间的差异都比较小，因此在以快速响应为核心的方案中将其忽略也就顺理成章的事了。

 

进一步研究发现，本文观点与网易对中台的看法较为接近。对于数据中台，网易杭州研究院执行院长汪源给出的定义如下，“所有的中台都是业务中台，数据中台是业务中台的特殊形式。中台是区别于平台的，具备业务属性、支撑多个前台业务的产品，其本质是公司业务能力的沉淀。”

 

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

 

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

 

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

 

从企业能力层面，“数据中台”与前台构成了二元架构，各自归属于具体经营业务部门和共享能力主管部门，本文将其称为“数据中台”。

 

从企业架构的层面， 如果把“数据中台”建设成一个巨大的系统，显然违背了“变速齿轮”的思想，要适应前台的灵活变化，必须进一步分拆，就出现了“数据中台系统”和若干“数据后台”系统。我们把这个层面的“数据中台系统”简称为“小中台”

 

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

 

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

前台系统是直接实现业务需求的各类数据分析系统，或者联机系统的查询分析模块，前台系统紧随业务而变化。

中台归属于科技部门，从而降低与业务部门的关联性，可以从企业全局视角进行优化。

 

中台的核心思想就是复用，将不同业务场景的通用能力抽离出来，下沉到一个共享平台，更好的支持前台系统的灵活变化。

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

 

传统数据仓库（数据中台 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 工作。

 

SQL是一种领域特定语言（DSL），虽然很强大但并不是很好的工程语言。由于它不能在内存中定义和操作复杂的数据结构，如果要做模块化的逻辑封装，模块的输入输出必须是数据库表，这就带来了 I/O 损耗，大量的模块化，必然带来导致 I/O 性能的显著下降。而这些模块存在的方式只是脚本，缺少治理工具，大量零散的模块如何管理也是一个难题。

 

系统实施者必须在模块化和性能间权衡，性能是显性的，直接影响用户体验且有明确的度量指标；模块化是隐形的，而且缺少度量工具。因此实际工程中，很少真正做到逻辑的模块化，数据库表的层次不规范，甚至出现数千行 SQL 语句从源表加工数据直接写入结果表。由于缺少治理工具，规范难以执行，久而久之大家也就默认了这样的事实。

 

我们付出的代价是可测试性极差，每次逻辑的变化都要通过对代码的修改来实现而并不是新增逻辑。试想一段上千行、逻辑纵横交错的 SQL 语句，要在其中修改某个单点逻辑，没有高覆盖率的单元测试用例，如何确保正确性，最终只能依靠细心和运气，代码质量必定是脆弱的，不能称为真正的工程化项目，治理和敏捷都无从谈起。

 

降低数据存储冗余

 

整体架构也在最大程度上压缩数据存储。三个层次中，只有数据后台会落地保存数据，“小中台”主体由服务组成，仅保留客户、机构等维度数据，用于提升处理效率。系统间数据冗余是业务逻辑重复开发的土壤，需要在顶层架构设计中尽量规避。

打个比方，三层架构就像一条汽车产业链，“小中台”是作为龙头的整车生产厂，后台是各种配件厂、发动机厂，前台是 4S 店负责直接接触客户和简单的改装。

整车厂为了避免占用资金和仓储，不会囤积过多的配件，而是根据整车订单量向配件厂动态调配。我们也尽量避免数据的冗余，降低传输和存储成本，缩短数据批量加工时间。

 

整车厂可能会复用成熟车型的部分配件（比如轮胎、发动机），改变部分配件快速推出新车型，就像我们通过中台完成业务需求的主要逻辑。前台的主要功能是产品交付和简单需求的满足，比如提供内饰甚至可以给汽车开天窗，但当多数用户提出该需求时，整车厂会直接推出天窗版，以更标准化的方式完成，也就是前台功能向中台的转移。

对于配件厂商，只要保证配件持续稳定供给，如果某款配件使用在多种畅销车型上，订单量会大幅提升，就要升级对应的产品线提升产能，生产线的变化并不影响到整车厂。

 

与之相似的，某些细粒度服务被多个粗粒度服务调用时，导致并发访问的提高，需要改变技术方案以处理并发和控制延时，可能会从 Oracle 切换到 HBase 或分布式数据库上，但中台和前台都不会感知到这些变化。

 

结语

总的来说，三层架构的核心设计思想是通过 API 服务衔接前中后台，减少数据搬家造成的冗余控制前台的膨胀，以无状态服务为核心使中台其具备横向扩展能力，后台避免锁定技术产品和数据模型，可以根据需求的变化灵活切换到不同的解决方案；API 服务相对 SQL 脚本具有更好的工程化特性，更便于治理，能够形成完善的敏捷体系，从而达到快速交付需求的目标。

 

“数据中台”并不是银弹，也存在不足。以服务为核心的中台模式并不能做百分之百的需求覆盖，仍然忽悠一些特殊情况存在，例如一些复杂度高查询通过“服务联邦层”实现可能过于繁琐，性能有明显损耗；一些批处理任务需要数据文件形式交付，如营销名单、催收名单等，需要特定的方式处理。

 

“数据中台”实施过程中的挑战主要体现在“需求控制”和“技术栈变更”两个方面。中台是典型的横向切分方式，必然会削弱业务需求的整体性，需要纵向增强对需求的统一管理，协调前中后台之间的联系。传统的 SQL 为核心的技能无法支撑本文的架构，开发者技术栈的大幅变更也考验企业的技术能力和决心。

 

我相信未来一段时间内“数据中台”仍然是架构领域的热议话题，希望更多的小伙伴加入，通过不断的实践和探讨，使其更加清晰准确，易于落地。本文仅代表个人对“数据中台”的初步理解，涉及一些企业架构的点评，不当之处还请谅解，水平所限难免有错漏之处，欢迎大家批评指正。

 

文献参考
[1] 钟华，企业核心业务数字化转型最佳实践，2018 云栖大会
[2] 何鹏，民生银行数据中台体系的构建与实践，民生大数据
[3] 张亮、蒋秀才，农业银行：银行业中台系统的建设思路
[4] 张磊，阿里巴巴全域数据建设，2017 云栖大会