中原银行实时场景企业级解决方案

摘要：本文整理自中原银行实时数据开发平台负责人杜威科老师在 Flink Forward Asia 2024 流式湖仓（二）专场中的分享。内容分为以下几个部分：

1、需求分析

2、解决方案

3、场景案例

4、现状展望

首先，介绍下中原银行业务的发展概况。中原银行成立于 2014 年12 月，是分支机构网点覆盖河南全省的省属法人银行。2017年7月，中原银行在香港联交所主板挂牌上市。中原银行下设18家分行，拥有超过 1.8 万名员工，并设立了 600 余个服务网点，资产规模达 1.3 万亿元。2022 年 5 月，经中国银保监会批准，中原银行正式吸收合并洛阳银行、平顶山银行及焦作中旅银行。

那么本次分享将围绕四个部分展开，第一部分将探讨银行业在实时场景下的具体需求。第二部分会阐述如何通过技术手段满足这些需求，并详细介绍所采用的关键技术。第三部分会分享近年来在这一领域建设的实际场景案例。最后，将对当前现状进行总结，并展望未来发展方向。

01.需求分析

1.1 银行业实时场景建设需求

银行业在实时场景建设中的需求可以总结为以下三点：全链路、全场景和企业级。

首先，全链路是银行业的核心目标之一。作为传统行业，银行业在技术需求、工作流程、规章制度等方面都较为复杂且严格。因此，在实现实时场景的过程中，首要任务是构建覆盖数据全生命周期的链路，包括数据的实时抽取、实时计算、实时存储以及实时查询服务。在实际落地的过程中，每一个环节的实现都面临不小的挑战。

其次，全场景是另一个关键需求。实施方案的目标是覆盖全行绝大多数的实时业务需求，例如经典的实时监控、协同交易、实时报表大屏等场景。举一个简单的例子：有多少银行能够回答当前时刻银行内的存款和贷款总额？这个问题看似简单，但对大多数银行而言并不容易。目前，许多银行仍然依赖 T+1 的批处理流程，只能获取截至前一日凌晨的数据。要实现时或分钟级的数据更新，不仅技术复杂度高，还面临海量数据实时更新的巨大挑战。因此，如何为业务人员开发面向实时场景的工具和平台，成为亟待解决的问题。

最后，企业级需求也不容忽视。正如前面多次提到的，银行业是一个相对传统的行业，在推进实时场景建设时面临诸多困难。因此，在选择解决方案时，必须考虑各个环节是否能够实现平台化和组件化，同时确保与行内现有资源的兼容性。这一点至关重要，因为完全从零开始打造一套全新方案并不可行。相反，所选方案需要与行内现有平台无缝对接，并具备对接行内的监控体系以及支持云原生部署的能力，以满足企业级应用的需求。

1.2 典型动帐场景数据操作特点

在了解了银行业的宏观背景后，接下来从微观角度分析银行业数据的特点及其应用场景。银行的动账交易，也就是普通的转账操作，主要有哪些内容呢？可以简化抽象为两张表：交易流水表和账户表。例如，当张三转入 100 元时，这一事件会被记录在交易流水表中，反映用户的具体行为。具体来说，流水表记录的是某人在某地、某时做了什么操作，这种表的概念非常常见且易于理解。而对于金融行业而言，账户表尤为重要，因为它记录了用户某一时刻的账户状态。比如，在动账之前，张三的余额是 500 元，转入 100 元后，余额变为 600 元；李四转出 100 元后，余额剩下 400 元。再比如王五，如果他在近一年内没有任何动账操作，虽然没有实时数据，但在统计银行账户总额时，他的账户信息仍然需要被纳入全量数据计算。这表明：账户表的实时计算需求必须支持全量数据处理。

通常所说的事实表、交易表或流水表，其实表达的是同一个概念。这些表主要用于基于增量数据的计算，因为它们记录的是事务性操作，应用场景通常是秒级的。当这些表需要与维表关联时，通常采用 Lookup Join。由于 Lookup Join 的特性，缓存的数据量较少，内存和 CPU 消耗较低，计算逻辑也相对简单。在存储方式上，这些表通常按天分区，其存储形式与离线处理几乎一致。

相比之下，账户表往往容易被忽视，但其重要性不容小觑。账户表也可以称为维度表或属性表，它在金融行业中的应用比较广泛，实时计算也比较复杂。账户表有哪些特点呢？首先，账户表的操作以 Update 为主，例如转入或转出等操作都会触发对相应记录的更新。这些操作的应用场景既有秒级、分钟级的，也涉及增量计算和全量加增量的混合计算。例如，王五的例子说明，即使他一年内没有动账，统计时仍需将其全量数据纳入计算并进行累加。在进行 Join 操作时，账户表通常采用Regular Join。由于 Regular Join 的特性，缓存的数据量较大，内存和 CPU 消耗较高，计算逻辑也更为复杂。甚至可以说，目前离线计算中的某些复杂场景，可能在未来三年内都无法通过实时计算完全实现。在存储方式上，账户表通常选择单分区多 bucket 存储。

02.解决方案

2.1 实时场景支撑平台

在将上述场景抽象化后，如何解决这些问题？要实现实时场景，银行业需要哪些平台支撑呢？

主要的，实时平台本身需要具备完善的数据抽取、数据计算和存储能力。然而仅靠实时平台并不足够。目前来看，金融行业的实时场景无法完全脱离离线数据计算生成的某些维度表。因此，还需要有一定的离线数据处理能力。金融机构通常已经拥有成熟的离线数据计算系统及相关生态。这些离线生态中的纬度表需要导入到实时系统中，才能保证实时业务场景的完整运行。此外，为了兼容行内现有的产品，避免重复开发，我们需要对接行内已有的监控系统、外呼告警系统等。例如，无论是离线表还是实时表，我们都统一对接到行内的数据资产平台，打破部门之间的壁垒，为全行提供统一的实时表和离线表视图。同时，我们的部署方式也需要适配行内的云平台，并通过统一的云管理平台进行管理。

2.2 全链路实时化

接下来将详细说明实时系统的构建过程。在左侧的业务系统中，目前主要使用的数据库仍然是 Oracle，国产化数据库 OceanBase 也在快速推广应用，这两种数据库覆盖了绝大部分业务场景。然而，要构建一个完善的实时数据采集系统，我们面临的挑战比预期更加复杂和困难。简单来说，如当前较为流行的 Flink CDC 技术难以在银行业直接应用，且数据库权限管理也较为严格等，我们需要企业级的实时数据采集产品来满足实时场景开发的需求，当前选择 DSG（迪思杰）的产品作为实时数据抽取工具。实时数据采集产品需要具备哪些核心功能呢？它必须支持全量抽取和增量抽取。全量抽取是对数据表进行整体提取，而增量抽取则主要依赖于在线日志或归档日志来捕获数据变化；在金融行业，开发的平台必须兼容国产数据库；此外，该平台还需要具备容器化、可扩展性等性能特点，以满足企业需求。

在实时计算和存储部分，采用 Flink SQL 是作为主要开发语言，Flink SQL 能够覆盖90%的场景需求，而剩余的 10%则可以通过自定义函数来解决，从而实现对所有场景的全面支持。同时，系统中还引入了 Kafka和 Paimon 两种技术，它们各自承担不同的应用场景。具体来说，在处理秒级场景时，通常选择 Flink + Kafka；而在非秒级场景中，则优先使用 Flink + Paimon。Apache Paimon 具备诸多优势，尤其在处理维度表相关问题时表现突出。它能够有效解决维度表更新和存储中的难点，从需求场景和数量上看，分钟级的需求远多于秒级需求。

经过实时计算和存储加工后，数据会被推送至 Kafka 者直接写入业务数据库，也可以写入公共的 StarRocks，作为公共服务供各方使用。

2.3 Flink ＋ Paimon 方案解决

那么，Flink + Paimon 的方案是如何解决维度表场景的问题呢？维度表场景面临的主要挑战包括以下几点：

• 强大的更新能力：需要根据主键进行大量的数据更新和删除能力，像 Hive 等无法满足更新需求。
• 低成本全量存储：需要一种既能存储全量数据，又能降低存储成本的解决方案。
• 便捷的查询能力：查询需要兼容更多生态系统。例如，Kafka 上的数据并不便于直接查询，因此需要更高效的查询方式来弥补这一不足。

在数百个业务场景的实践中，我们发现，在实时场景开发过程中，逻辑开发仅占一半的时间，而更多的时间被用于问题排查，即验证数据的正确性。每当完成开发一个场景时，首先需要回答的问题是：这个实时数据结果是否正确？因此，一个便捷的工具来查询和验证数据显得尤为重要。Flink + Paimon 的能力能够很好地解决这些问题。例如，Paimom采用的LSM 树结构支持高效的更新操作，并在更新后生成完整的变更日志（Change Log）。这一变更日志是端到端计算正确性保障的核心；此外，Paimon还支持流处理，尤其在流处理过程中能够同时处理全量和增量数据；在生态兼容性方面，也有多种选择。例如，我们选择 StarRocks 提供查询服务；此外，无需单独构建OLAP查询引擎，可以直接复用行内的 OpenLookeng 查询数据，采用离线团队的组件，轻松实现适配。

2.4 流式湖仓数据模型

与传统的离线模型相比，我行流式处理模型仅有三层，而通常的离线模型包含四层。为什么只需要三层？通过实践发现，两次 Flink 计算就足以解决绝大部分的计算逻辑。没有必要花费更多的时间、精力、资源以及硬件支持将其扩展到四层。尽管理想模型可能设计得更为复杂，但实际应用中，两次计算已经足够满足需求。

另一方面是纯流式架构。这种架构特指在整个数据入湖以及湖内不同层级计算之间，完全依赖完整的 Change Log（变更日志），并支持完整的 Insert、Update、Delete 操作。只有当数据在数据湖中流动时采用这种变更日志流的方式，才能最终确保端到端输出的数据是准确的。如果缺乏完整的变更日志，数据可能会出现错误，而这种错误往往难以察觉。例如，如何确认当前计算出的存款金额是正确的？这是一个很难回答的问题，因为存款金额是一个动态变化的数值。

目前，数据湖上的表已经统一对接到离线的 Hive MetaStore。此外，Hive MetaStore 还与行内的另一个重要平台数据资产平台对接。对接后，全行的业务人员都能在数据资产平台上查看有哪些实时表和离线表，从而获得一个统一的视图，打破数据孤岛，提升整体效率。

03.场景案例

接下来将重点分享遇到的大量真实场景案例，以供大家参考。来看一下这些遇到的问题，大家是否也曾经历过。

3.1 案例一

第一个场景：更新入湖——实时更新入湖近亿级别的账户表。

这一场景看似简单，即从核心的 Oracle 数据库中抽取数据并写入数据湖，但实际上，过程中遇到的问题非常多，绝大多数金融机构可能都无法实现这一功能。那么，为什么这项任务如此困难呢？

3.1.1 夜间跑批与归档日志的挑战

首先，需要了解一个基本概念——“夜间跑批”。这里并非指数据仓库中的批处理任务，而是特指金融行业核心数据库每天晚上都会执行的批量处理任务。尤其是每月21日，这一天会进行活期存款利息的计算，通过一条特定的 SQL 语句更新所有账户余额，加上相应的利息。这条更新语句会产生海量的归档日志。在高峰时段，每小时会产生数百G的归档日志，且持续两到三个小时。它记录了全行有多少账户（类似于银行卡号）以及这些账户上的资金余额。一旦成功将其安全、长期、稳定地抽取并入湖，其在数据湖上的应用范围是最广泛的。这项任务必须确保三点：

• 不影响核心交易系统的正常运行；
• 运行稳定不报错；
• 能够实时将数据更新写入数据湖。

3.1.2 实现过程中遇到的核心问题

• 硬件要求高：无论是 Oracle 服务器还是实时抽取工具所在的服务器，都必须配备万兆网卡。如果使用千兆网卡，即使网络打满，每小时能传输的数据量也远远无法满足需求。Oracle 服务器所在的硬盘空间必须足够大，以存储数以 TB 计的归档日志，从而为抽取工具提供充足的时间完成抽取任务。
• 全量加增量的抽取方式：抽取工具需要支持全量和增量结合的抽取方式。因为需要定期进行全量数据抽取，以确保数据的正确性，并为后续的数据校验提供保障。
• Kafka 写入优化：数据抽取完成后，日志会被写入 Kafka。为了提高写入速度，建议选择 AVRO 这种二进制格式，而非 JSON 格式。相比之下，AVRO 在写入速度上提升了一个数量级，写入速度可达数百兆每秒，而 JSON 格式仅能达到数十兆每秒。
• 确保数据有序性：为了保证数据的顺序性，同一个事件只能写入同一个 Kafka分区，以确保在该分区上的数据有序性。这是后续计算正确性的基础。为了进一步提高分布式写入的速度，可以适当增加 Kafka 的分区个数。

尽管前面讨论了一些看似与主题不直接相关的问题，但这些都是实现 7x24 小时稳定运行所不可或缺的。接下来，抽取的数据会被写入 Paimon。

3.1.3 实时更新入湖

• changelog-producer 采用 Lookup 方式，以确保生成完整且正确的日志。如前所述，完整且正确的 Change Log 是端到端计算正确性的关键保障。
• 提高资源，加价内存、CPU、增加 Bucket 数量等。如果在写入过程中遇到性能问题，最简单的解决办法有两个：增加 CPU 资源和增加内存。实际上，为了确保了任务的稳定性和高性能，该任务分配了数十个 CPU 和几十GB的内存。
• 为了保证数据的正确性，还需要有主键覆盖机制。主键覆盖能够防止重复生成 Change Log，并需要周期性地进行全量校正。
• 这张表在下游应用中既可以作为实时的维表，也支持增量读取以及全量加增量的读取方式。在实时场景发展的前两三年，每当到了晚上，由于性能和稳定性原因，不得不暂停实时任务的数据处理。换句话说，如果不采用这种新的技术方案，就无法实现连续性的数据处理。

3.2 案例二

第二个场景：交易协同——实时数据处理助力银行核心业务的高效应用

在实时数据处理的应用中，交易协同是一个极具价值的场景。它不仅实现简单、投入小，对内存和 CPU 的消耗也相对较低，但带来的收益却非常显著。对于银行而言，存款和贷款是其核心业务。如果能够通过技术手段帮助银行更快地收回贷款，这种收益不仅是高回报的，而且是可以量化的。这是一个对于业务人员和平台人员双赢的典型案例。

那么，这一目标是如何实现的呢？当业务发生实时入账时，我们能够第一时间获取这些入账信息。随后，使用 Flink SQL 对这些数据进行处理，并采用了 Paimon 作为维度表来进行关联操作。此前，我们曾使用 ES（Elasticsearch）作为维度表。在实际应用中发现，ES作为公用资源，其吞吐量存在不稳定性，尤其在高峰期，关联超时的问题频发。这不仅影响了处理效率，还给下游系统带来了困扰。虽然可以接受处理速度的减慢，但数据的不准确或无法解释的现象是不可接受的。

为了解决这一问题，采用了“空间换取时间”的策略，选择了 Paimon 作为新的维度表。此外，Paimon 还有一个显著优势：它同时支持 Lookup Join 和 Regular Join 两种方式。这意味着维度表既可以是实时的，也可以是离线的。在当前的实时场景中，仍然无法完全脱离离线计算出的维度表。这一方案已经成功应用于多个交易系统，包括对公存款、对公贷款、零售贷款、信用卡、资产保全、票据业务等。通过实时监控用户的转账信息，并及时通知下游系统，该方案能够协助下游系统对用户账户进行快速响应，如账户冻结、划扣、催收等操作。

3.3 案例三

第三个案例：实时图应用——银行业务与图数据库的深度融合

对于传统银行而言，实时处理场景本身已颇具挑战性，而当图数据库融入其中时，更是对系统能力提出了更高的要求。实时图数据库的数据主要来源于两部分：每天T+1的离线数据仓库和流式数据仓库。这些数据经过实时的图关系与图实体加工处理后，被统一写入图数据库中。

目前，已经成功实施了多个实时图应用的场景，包括实时图挖掘、实时图指标计算以及实时图可视化展示。具体来说，这些应用已成功落地于以下场景：

• 信用卡逾期客户团伙挖掘：通过分析客户间的关联关系，识别潜在的逾期团伙；
• 公安紧急止付关系图：快速构建关网络，协助公安机关进行紧急止付；
• 挖掘关系图的可视化展示：以直观的方式呈现复杂的图关系，便于业务人员理解和决策；
• 反欺诈异常客户排查：通过实时图分析，快速定位异常客户及其关联网络；
• 运维告警链的大屏展示：在运维场景中，通过大屏实时展示告警链路，提升问题定位效率。

3.4 案例四

第四个案例：海量数据的实时存储——高效存储与查询的解决方案

本方案旨在解决如何高效地实时存储海量数据，并支持 OLAP 查询。这些海量数据来源于全行的核心交换机，通过物理硬件捕获全行的网络流量，经过解析后写入 Kafka。数据进入 Kafka 后，新的挑战随之而来：如何长期稳定地存储这些大量的数据，并使其能够便捷地被查询？基于此，需求变得清晰明确：

• 高效的实时数据写入性能，以确保数据能够快速被处理和存储；
• 低廉的海量数据存储成本，以控制整体系统开销；
• 便捷的批量数据查询方式，以满足业务对数据即时分析的需求。

为了解决这些问题，我们采用了 Flink + Paimon 进行分布式的实时数据写入，并将数据存储至数据湖中。在数据湖上，结合了对象存储和 Paimon 的表格式进行查询优化。此外，如前所述，在查询环节复用了离线的 OpenLookeng 技术，进一步提升了查询效率。

• 实现了端到端分钟级的数据延迟入湖；
• 使用 Paimon 在数据湖上完成了长达半年的数据存储，总量达到约 200TB；
• 查询性能优异，能够在几分钟内返回结果，满足业务对快速响应的需求。

3.5 案例五

案例五：面向业务人员的易用性建设——简化实时场景操作，提升开发效率

之前提到的实时场景通常具有周期长、逻辑复杂的特点。这些场景将数据的生产、加工和使用等环节进行了充分解耦。然而，在实时处理中，这些环节又被紧密串联在一起，任何一个环节的错误都可能导致整体业务问题，使业务人员感受到系统的不稳定。为了解决这一易用性问题，开发了一个完全自研的平台，旨在为业务人员提供更直观、易用的解决方案。

如何解决易用性问题？

为了更好地服务于业务人员或特定业务场景，首先进行了一项关键调研工作：筛选出那些需要业务人员直接配置规则并能即时生效的场景，并对其进行了统计分析。针对这些场景，采用了拖拉拽的可视化方式，让设计与开发过程变得直观且易于操作。这一平台特别关注了那些不熟悉编码、不了解技术细节的业务人员。通过该平台，业务人员可以轻松完成以下内容：

• 拖拽开发：低代码的拖拽式开发，达到设计即开发；
• 模拟测试：在非生产环境中模拟运行，降低风险；
• 动态规则更新：业务人员调整计算逻辑即可实时生效，高效快速迭代；

关联系统对接：银行业拥有众多复杂的系统，为了提升跨系统的协作效率，自研了一种基于 JSON 的 DSL 表达式。当其他平台上的规则发生变化时，只需将变更内容通过 DSL 传入该的平台，即可快速上线新规则。

04.现状展望

下面将对实时场景建设的现状以及未来展望进行分享。

目前，我行的实时数据处理能力已在多个方面取得了显著进展。具体来看：

• 运行任务规模：现已支撑行内二十多套业务系统的实时运行，容器化运行的任务数量达到了800个，并且以每年100至200个的速度持续增长。
• 数据覆盖范围：实时抽取的原业务系统表数量已达到1000张，其中已有300张表的数据成功入湖，为后续分析和应用提供了坚实基础。
• 资源消耗情况：在资源消耗方面，当前使用的内存资源已达约3TB，对象存储上的数据量也达到了数十 TB。

通过这组数据可以看出，银行的业务场景与互联网场景存在明显不同。互联网场景通常以少数大规模任务为主，而我们的业务特点是场景众多且复杂，但每个场景的数据量相对较小。总结来说，我们面临的是大量小任务、小场景的分布式需求。虽然单个任务的数据量不大，但由于任务数量众多且场景复杂，整体建设和运营的挑战依然巨大。

在未来，我们在实时数据处理领域设定了一定的目标：希望到 2025 年，能够实现上千张表的实时入湖。例如，需要明确从哪些表提取数据入湖、入湖后如何进行逻辑加工，以及加工后的数据应写入哪个业务场景或系统。每一次实时场景的成功上线，都是多个团队共同努力的结果，共同确保系统的稳定运行和数据的准确处理。如果能够提前将数千张表的数据入湖，将会大幅减少后续的工作负担。这一点与离线场景的建设类似：当全行所有表的数据都已提前入湖后，一旦有需求产生，便可直接利用这些数据，无需再进行繁琐的数据提取和加工。

此外，目前我们的数据入湖时间间隔为1分钟，我们希望针对部分关键表能够进一步缩短时间延迟，例如压缩至20秒或更短时间，以提升数据的实时性和可用性。我们的方案已经覆盖了分钟级和秒级的实时数据处理能力，展望 2025 年，希望能够探索并应用更多新颖且创新的实时场景，同时也十分关注数据与AI技术结合的新方向，为业务创造更大的价值。

在当前线上运行的任务中，绝大部分时间内存和CPU的使用率并不高。因此，希望通过引入新的方法或技术，提高这些资源的利用率，从而优化系统的整体性能，为未来的扩展和创新奠定更坚实的基础。

---

更多内容

---

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：
新用户复制点击下方链接或者扫描二维码即可0元免费试用 Flink + Paimon
实时计算 Flink 版（3000CU*小时，3 个月内）
了解活动详情：https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc