“数据中台”的再思考

    今天，中台已经成为架构转型的里程碑，从互联网到传统企业谈架构必有中台。虽然各类中台概念层出不穷，但“数据中台”和“业务中台”做为中台概念的起始源头，被视为最纯正的中台，也是企业架构转型的重要目标。我所在的银行正筹备“数据中台”的建设，为此在内外部组织了屡次技术研讨，每一个人都有不一样的想法，共同点仅限于但愿本身的解决方案命名为“数据中台”。我想这种认识的差别是源于“数据中台”尚处在概念萌芽期，须要更多探讨与碰撞。本文借鉴了互联网公司和两家同业银行的案例，尝试对“数据中台”建设思路进行总结，所提出的架构方案仅供探讨，还没有应用于实际系统建设。

1、传说与误解

    在争论什么是“数据中台”前，咱们应该意识到“数据中台”只是解决方案，关键在于经过“数据中台”解决什么问题？在我看来，中台要解决的核心问题是在短期内搭建或变动前台系统，从而快速响应用户需求、把握市场机会。

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

    做为这一波“中台”概念的源头，第一个传说必须来自阿里。“游戏公司”的传说，大体是这样，阿里的马老师带队参观了一家厉害的游戏公司 Supercell，它有不少成功的游戏产品，其独特优点是可以快速推出新产品，而依靠的就是中台系统。马老师受到了启发，回到阿里开始推动中台建设，在组织架构层面成立了单独的中台部门即“共享业务事业部”，系统层面建设了用户中心、支付中心等共享服务同时支持淘宝、天猫、1688 等业务条线，最终也实现了快速的前台产品研发。这些中台服务被统称为“业务中台”。经过这个故事，咱们能够得出第一个结论。中台应该提供“共享服务能力”，这种共享源于对业务场景的抽象、提炼、沉淀。

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

    这样咱们有了第二个结论，中台意味着了前中后的三层体系架构，三者的变动速率能够实现更平缓的过渡，从而兼顾整个体系的灵活与稳定。但有一个问题始终困扰着我，基于前两个结论，可知是存在“业务后台”和“数据后台”的，那又是指什么呢？这个概念不澄清，体系就是不完整的。带着这个疑问，咱们来看看具体案例。首先是阿里的双中台架构[1]。

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

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

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

    看过两家银行架构，咱们彷佛能够获得一个推论，后台是技术平台或基础设施。但这二者一般是与业务无关的，会制约前台业务的灵活性吗？基础设施和技术平台同时支持了前台和中台，在层级并非一个递进关系呀？这个分层彷佛有点奇怪，有点牵强。

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

    前台部门直接面对用户和创造利润；阿里“共享服务事业部”更多参与到了业务中，很是适合中台的定位。然后台主要是辅助做用，一般也就不会受到用户需求的影响，企业甚至行业间的差别都比较小，所以在以快速响应为核心的方案中将其忽略也就瓜熟蒂落的事了。进一步研究发现，本文观点与网易对中台的见解较为接近。对于数据中台，网易杭州研究院执行院长汪源给出的定义以下，“全部的中台都是业务中台，数据中台是业务中台的特殊形式。中台是区别于平台的，具有业务属性、支撑多个前台业务的产品，其本质是公司业务能力的沉淀。”

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

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

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

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

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

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

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

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

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

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

    这种架构最大的问题不是集市体量大，而在于它的不稳定性。由于其直接服务于业务部门，任何组织架构上的调整都会带来集市的合并分拆，甚至在组织架构不变的状况下，部门经营策略的更改也会成为新建或分拆系统的动力。当某类产品成为企业发展重点时，会出现为产品创建独立分析系统的诉求，例如互联网信贷产品分析系统；当某个渠道的关注度提高时，又会但愿按照渠道汇总各种信息，例如对电子银行分析系统；再或者对某个客户群体的重视，将催生以客户特征为边界的集市，例如私人银行客户分析系统。

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

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

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

    企业规模扩大，“数据集市”数量不断增长，这时重复加工、口径不统1、成本不经济的问题就会浮现出来，固然最更要的是对快速交付的期待。
    2017 年，阿里提出的数据中台 [4] 维持了数据仓库架构的基本二元结构；垂直数据中心、公共数据中心、萃取数据中心是在数据处理逻辑上的分层，与传统数据仓库的分层有相近之处；统一数据服务中间件（OneService）是新增部分，体现了 DT 时代对数据价值的重视，须要更直接的方式使用数据。

    网上已有不少对阿里数据中台的解读，这里再也不赘述，只重点谈下一对 OneService 的理解。经过公开资料可知，OneService 并非单纯的 API 服务，同时涵盖了 SQL 查询、数据批量等方式。是否保留这些方式，我有一些不一样的理解。
    首先是数据批量方式，从数据仓库的实施经验来看，集市一般会有自我闭环趋势，力图减小对其余系统的依赖，其积累数据后必然进一步扩充功能，批量数据集成方式事实上是可以为前台的膨胀提供了基础。约束“小前台”最操做性的方式，AIP 服务调用方式替换数据集成，因为数据不落地，前台不易积累数据以独自完成业务需求，必须依赖中台的支持。
    再来看 SQL 查询接口，其主要用于支持 BI 工具。SQL 直接体现了服务端的数据表结构，与物理模型设计和具体技术产品造成紧密耦合，下降了“大中台”后续发展的弹性，甚至形成对单一数据库产品的绑定。使用 API 能够下降这种耦合，付出的代价是弱化了前台系统对数据加工能力。随着 Json 接口成为 BI 工具的标准功能，API 替代 SQL 接口也具备很高的可行性。
    所以，我认为依赖统一的 API 服务打通前台与中台的联系，前台系统之间再也不有直接联系，总体保持星型架构，可以保证“大中台、小前台”架构的持续性，以下图所示。

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

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

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

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

技术可行性

    “小中台”的主要工做是进行数据集合运算，实现原有集市沉降下来的业务逻辑。“小中台”与数据后台基于 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 云栖大会