首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

设计一个数据中台,总共分几步?

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

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. 结语

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

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

6. 作者介绍

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

  • 发表于:
  • 原文链接http://news.51cto.com/art/202003/612682.htm
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券