设计一个数据中台，总共分几步？

文章来源：51cto海边的Ivan

本文旨在探讨通用的数据中台架构设计方法，产出物为数据中台的逻辑架构。当然，考虑到业界对于数据中台的定义千差万别，可以预见大家不一定认同本文设想的中台架构，但我觉得每个步骤中的推演过程或许会大家给带来一点启发，还是最终成文，大家权当是疫情期间做了一次脑力体操吧。

1. 明确中台边界

首先，我们面对的问题域是整个数据体系，这个体系是指传统上有数据仓库、数据集市构成的生态环境，不包含联机交易系统（如核心系统、理财销售系统）和纯粹的流程管理系统（如业务审批系统）。

随着技术的发展，这个体系增加大数据和 AI 的元素，更加智能化，但依然是以战略和战术层面的数据能力供给为核心，可以作为业务变更的权威依据和决定性因素，但不直接改变业务状态。

第一次分解，我们按照是否具有业务属性作为标准，可以先拆出技术平台和“其余部分”。这样从整体架构层面看，后续无论“其余部分”分解为多少个系统，这些系统与技术平台的关系都是一致的，即技术平台提供与业务无关的支撑能力，这种能力包括数据的存储、加工，甚至可以涵盖可视化层面，前提是这种技术能力有进行平台化的必要。

第二次分解，我们从“其余部分”拆分出前台和中台。支持这次分拆的理由自然是“小前台、大中台”，也是中台建设热潮的 Slogan。前台注重灵活性，中台注重稳定性，两者构成类似“变速齿轮”的关系。

怎么理解灵活与稳定呢？我觉得一条重要的标准就是系统的投产频率。面对需求变更，前台与中台的投产频率至少达到 2：1，才能体现出中台的稳定。反之，如果每次需求变更中台都要受到影响，那这个中台就是不成功的。

面对数据体系，我们通过明确中台边界，形成了前台、中台、技术平台三分天下的格局，如下图所示。

2. 细化中台外部接口

目前我们描述的边界仍然是概念上的，比较宽泛，也就会造成理解上的很多分歧。细化接口可以帮助我们更深刻得描述对中台的期望，从而在组织内达成一致，所以我们第二步就来做这项工作。

技术平台与中台的接口各种各样，但因为是业务无关的，不容易有歧义，所以我们重点谈谈前台和中台的接口。传统上，数据体系的系统接口主要是以批量文件形式为主，前台和中台是否要延续这种接口呢？我的观点是，应该最大程度的避免使用批量文件作为接口，更多的使用 API 服务方式。具体原因有以下几点。

批量文件的自解释性差、可治理性差

工程实践中，批量文件的数据与元数据常常是分离的，甚至干脆省略掉元数据。具体来说，批量文件通常是仅包含数据的平面文件，在源系统中（可能存在于数据库中）的“数据项标识”、“名称”、“数据类型”、“备注”这些内容，很少在接口中看到。当然，如果做得好些，我们也可以在数据治理系统中登记这个接口，但问题是治理系统中“元数据”的正确性与系统运行是完全无关的，它们从来没被真正验证过，也无法确定是否随着业务变更被即时更新，当我们需要依据这些“元数据”做出决策时往往信心不足。

久而久之，治理系统中“元数据”不再被使用，就成了死数据。

相对而言，服务的自描述要好很多，我们甚至可以在组织范围内约定更丰富的元数据，将其与服务发布融合在一起。基于架构设计上的服务注册与发现机制，这些服务会受到更强有力的约束，从而保证元数据的质量。

前台的灵活性是源自其轻、薄的设计约束，业务功能更多依托中台的复用能力来实现，而文件接口会增加前台数据累积数据的可能性，从而为前台的边界无序扩展创造土壤。

我们在系统建设中常常可以观察到一个现象，系统会自我驱动，业务会越来越复杂和发散。究其原因，大概是系统的主要利益相关方更倾向于在系统中拓展功能，可以降低与外部（科技、业务等）的协调成本。从局部，尤其是某个特定需求上看，这可能是更快、更好的选择，但从全局而言就是一种伤害。在哲学上层面，这个问题就是局部最优解不一定是全局最优解。

追求局部最优解的后果就是建设大量竖井式系统，无法沉淀可复用的能力。中台的使命恰恰是要从全局角度，破除或者削弱这种建设模式。

前台尽量不积累数据，也就杜绝或者控制了其逻辑向复杂化、发散化演进的可能。我们可以在更高阶的管理层面，以更低的成本洞察到这种演化的趋势，从而采取相应的措施。

服务方式天然满足了控制前台系统积累数据的目标。

依托于批量文件的“数据搬家”削弱了整个数据体系的鲁棒性

数据仓库方法论是秉承“以空间换时间”的思路，通过 ETL（SQL 处理）预加工来降低用户查询报表时的计算负载，从而实现低延时交互。为了统筹提升整体加工效率，并不会将单张报表依次加工，而是合并报表的加工层次，先共性后个性逐层推进，一个批次（一天可能会存在 2-3 个批量加工批次，通常不会太多）的加工结果大致会在同一个时间段完成。

这种方式的弊端是，一旦上游数据或基础层加工出错，发现错误的时点会大幅延后。原本通过单进程查询就可以发现的错误，现在必须预支大量的批量计算成本后才能看到。这个过程浪费了大量的计算资源和时间资源（ETL 必须在当日完成，因此时间资源也是受限的），甚至导致无法在剩余的时间窗口内完成纠错和任务重跑，造成业务的重大影响。

我们应该看到“以空间换时间”的策略是基于若干年前的即时计算能力而做的权衡。今天，分布式技术发展带来了即时计算能力的大幅提升，是时候在 ETL 处理和即时计算之间寻找更优的平衡点了。

我的建议是将一些计算负载迁移到服务中来，用分布式计算框架代替部分 ETL。中台与前台的接口处位于整体 ETL 的末端，所以这里也就更适合采用服务接口。

此外，还要说说第三种接口方式 JDBC，我个人也是不推荐的。一个原因是 JDBC 暴露了数据源的数据存储结构，强化了前台与中台的耦合，既然我们在架构层面希望两者松耦合，那具体接口上也应该选择匹配的技术。第二个原因是业务语义上的差异，RESTFUL 服务有一个“有趣（Interesting）”原则，服务要有业务语义。直接对一张表的访问显然不够“有趣”，那么 JDBC 也就不能称为服务了。

数据中台的外部接口主要是 API 服务。

3. 梳理中台内部结构

我们继续探讨数据中台的内部结构，按照我们在第一步设定的边界，“数据仓库”与“数据湖”必然是中台的一部分。两者是不是中台的全部呢？我认为并不是全部。

数据中台不只是数据仓库

数据仓库方法论有 Inmon 和 Kimball 两个流派，国内数据仓库的实施多数采用 Inmon 的方法。

具体来说，在数据仓库与数据集市的二元结构中，数据仓库对接上游各类业务系统，按照企业级模型重组数据以消除源系统的特异性，这个模型按照若干主题进行组织，是数据仓库理论体系的核心；数据集市在此基础上，根据具体的应用场景进一步加工数据，实现最终的功能交付。

可以看出两者的指导思想不同，数据仓库是“面向主题”的，数据集市是“面向应用”的。

有些企业以前是竖井式的数据集市，现在把集市中的共性部分下沉，节省了加工成本，认为这就是数据中台。如果笼统得用“能力复用”作为标准，似乎数据仓库与数据集市就是中台和前台了。

那么数据中台是在炒概念吗？我认为并不是。

数据中台与数据仓库的差别不是有没有能力复用，而是因为数据集市仍然太重不符合前台的灵活性要求。同样是二元结构，因为数据集市不等于前台，所以数据仓库也就不等于中台。

前台碎片化

理论上数据集市是满足一个“业务单元”的数据分析需求，实践中这个“业务单元”往往对应到“业务部门”，因为这样业务管控职责明确，能够快速需求边界，和财务管理制度也有直接的关系，项目操作较简便。

但是，今天这种方式遇到了挑战。随着数据应用的深入，需求越来越具体，同一部门的不同团队的需求也各有侧重，都希望保证各自的灵活性，又不希望自身的稳定性受到其他团队灵活性的影响，“业务单元”呈现明显的“碎片化”。

跟随着业务的“碎片化”，数据集市不断裂变，底层逻辑大量重复。显然，该做架构层面的调整了。这就说到前台，其服务的“业务单元”更小，但逻辑相比数据集市要更加轻薄，将原有针对“业务部门”的加工要沉淀到数据中台，沉淀的部分也有再次重组的机会。

数据中台既“面向主题”也“面向应用”

数据中台“面向主题”是因为包含了数据仓库，“面向应用”则是因为包含了数据集市下沉部分。这里的新问题是如何重组数据集市下沉到中台的部分，重组方式依赖设计者的经验，其实没有统一方法。我的建议是按“价值链”和“产品线”两个维度分解，两者正交构成若干单元，这些单元称为“业务域”。

同样是数据沉淀，为什么不使用数据仓库的主题，而要新建“业务域”呢？数据仓库的主题是数据层面的高度抽象，基本不体现业务流程。今天，数据应用的大趋势是强化对“一线操作”数据赋能，必然更加关注业务流程，而价值链正是业务流程的起点；产品则是衔接企业与用户的桥梁，同时也是业务操作的核心。

“业务域”是对业务流程的抽象，可以说是“面向流程的”，本质还是“面向应用”的。“业务域”数据模型不像数据仓库“主题”那样严格的去冗余，有些维度信息会重复出现，比如客户基本信息、机构信息等。

以银行为例，“价值链”上的典型环节包括营销、运营、风控等，“产品线”可以分为零售、对公、同业等，两者正交则可以得到“零售营销”、“对公营销”、“零售风控”等业务域，当然正交得出的业务域也可以适当调整。

数据中台包含一个“面向主题”的数据仓库（及数据湖）和若干个“面向应用”的业务域。

4. 针对非功能性需求的设计

目前为止，我们仅在数据结构上讨论了中台的构成，并没有考虑系统的非功能性需求。事实上，在不同应用场景下前台的非功能性需求会有较大的差异，其中最有代表性的是对并发和延时的要求。因为我们已经约定中台与前台的接口是 API 服务，这些需求会直接传导到中台。接下来，让我们谈谈中台的针对性设计。

第二步中，我给大家的建议是减少“数据搬家”和 ETL，因为这会导致削弱系统的鲁棒性，对于中台的内部设计我也坚持同样的观点。数据应该通过最短的加工路径，形成 API 服务向前台交付，所以数据仓库和业务域都应该具备 API 服务能力。

数据仓库原本以批量加工为主，以文件方式输出，兼顾 API 服务绝对是个大挑战。设计一个在行业内广泛适应的主题模型，在我看来其实是有点玄学的成分，但既然有超多企业的实践，我们还是先要认同它，但谈到改造这个模型，还真是无从下手。

在找到兼顾的方法前，我更愿意让它保留原来的样子，这样可以沿用成熟实施方法，毕竟目前在数据仓库上继续付出努力还会获得不错的收益。我们可以让数据仓库在现有的结构上提供一些兼职的 API 服务，适合那些延时要求不高的应用场景（比如一些报表查询），一旦不能满足就在更上层的区域重建这些服务。

业务域的数据结构是“面向应用”的，也就有更好的基础提供 API 服务能力。普通查询场景，可以选择兼顾批量处理性能和联机查询性能的存储产品，比如 MPP 数据库或者 HTAP 数据库。

高可靠低延时场景（比如反欺诈、反洗钱，数据查询结果是会阻断异常转账的依据，对延时有极高的要求），可能是两种存储产品的组合，分别提供批量处理和联机访问能力。联机查询可以选择是 K/V 数据库（比如 HBase）或者分布式数据库（NewSQL）或者分库分表方案（MyCat 或者更好的方案），总之是更接近 OLTP 的存储系统。存储产品的组合一定会带来数据冗余，这种冗余虽然也需要数据搬家，但不会带来业务逻辑层面的重叠，没有背离我们的设计理念。

业务域的服务和中台最终交付的服务是存在差异的，这种差异是为了保护业务域的稳定性。无论我们按什么标准划分业务域，也总会有应用场景需要多个业务域参与。所以，在业务域之上还要增加一层，我将其成为“服务联邦层”。

通过“服务联邦层”，我们可以完成服务间的拼接，避免数据复制导致业务域边界的模糊，这种拼接是数据语义上的关联。此外还会对单个服务再加工，隔离应用的特异性和存储数据结构的通用性，这意味着过滤、聚合甚至嵌套子查询。数据语义的加入使“服务联邦层”比标准的服务总线更复杂了一些，更像 Presto 这样的数据联邦产品，但接口是 API 服务而不是 SQL。

最后还会存在一些特殊情况，跨业务域但通过服务拼接无法性能要求，必须通过批量加工完成，我们要专门建立一个区域隔离这种跨域数据加工，称为“数据隔离区”。这里可以汇聚多个业务域的数据，但仅向上层的“数据联邦层”输出。业务域与“数据隔离区”保持单向数据流动，维护业务域的稳定性。

这样，我们得到一个完整的逻辑架构图。

5. 结语

整个架构设计过程中应用了一些基本原则，也是我个人对数据中台的理解，包括以下几点：
中台一定是有业务属性的，中台要比前台更稳定；
尽量减少 ETL 加工，引入分布式技术进行即时运算，提升系统的鲁棒性；
API 服务接口优于文件和 JDBC 接口。
中台内部多层次提供 API 服务，通过服务集成的方式减少跨域的数据集成。

一家之言，希望和大家多多交流切磋。

6. 作者介绍

王磊，光大银行企业架构师，Pharos 架构设计和主要开发者，曾任职于 IBM 全球咨询服务部从事技术咨询工作。目前负责全行数据领域系统的关键架构设计、评审及内部研发等工作，对分布式数据库、Hadoop 等基础架构研究有浓厚兴趣。

发表于: 2020-03-172020-03-17 14:21:00
原文链接：http://news.51cto.com/art/202003/612682.htm
如有侵权，请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长进交流群

领取专属 10元无门槛券

私享最新 技术干货

设计一个数据中台，总共分几步？

1. 明确中台边界

2. 细化中台外部接口

3. 梳理中台内部结构

4. 针对非功能性需求的设计

5. 结语

6. 作者介绍

相关快讯

扫码

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐