中国银行企业级架构办公室资深经理 宋首文
在数字中国建设过程中，数字经济的发展极为重要，商业银行数字化转型则是数字经济发展中不可或缺的一个环节。在客户体验提升和金融科技创新的双轮驱动下，
如何通过对大量有效数据的探索分析实现传统银行业务的流程重塑，如何构建与互联网经济环境相匹配的客户服务能力，将成为商业银行数字化转型的战略重点。
当前，商业银行数字化转型已进入深水区，数据处理速度对于商业银行产品快速交付能力和金融服务高效响应能力的提升至关重要。商业银行在与客户的交互中每天都会产生大量数据，如果能以实时或近乎实时的方式挖掘出可用的数据，将大幅提高商业银行的敏捷度。与此同时，随着实时计算技术在互联网金融行业的广泛应用，客户对数据处理速度的要求不断提高，多数传统商业银行使用的批处理框架已无法满足新的要求，急需重新构建以实时计算数据处理架构体系为基础的新一代数据处理框架。
一、实时计算的发展及实践
实时计算是一种由各类流式数据触发的计算模式，速度要求为秒级。在大数据兴起之初，Hadoop
并未给出实时计算处理方法。之后，Storm、SparkStreaming、Flink 等实时计算框架相继上线，随着Kafka、ES 的出现，
实时计算领域构建了完整的技术架构。随着物联网、机器学习等技术的广泛应用，实时计算在众多场景中得到更深层次的应用。实时计算主要具备无限数据、无界数据处理、低延迟等特征，但是，数据的价值随时间的推移大幅降低，时效性将成为实时计算需要持续优化的问题。
2010 年，David Anderson 等人进行了Stratosphere 项目的开发，并于2014 年将其代码捐赠给Apache
基金会，最终孵化形成Apache Flink 项目。Flink
是用于大数据实时计算的开源引擎，支持处理关系型数据库、本地日志、网页日志等多种实时数据，提供端到端、秒级的实时数据处理功能，并封装了标准的SQL
语句以降低实时计算的编程门槛。随着实时处理趋势的发展和推进，Flink 已逐步演进为实时计算的业界实施标准和最常见的应用项目。
1. 实时计算的沿革历程
随着数据量的不断增加和数据存储硬件及技术的不断发展，仅靠数据库或手写代码来进行数据计算的难度越来越大，不仅涉及资源调度，还要考虑高可用、容错等。在此背景下，分布式计算框架成为驱动大数据时代高速发展的一个重要引擎，且随着数据规模的不断扩大，相应的计算框架也在不停地升级迭代，计算框架的发展大致经历了三个阶段：
一是批量计算框架阶段。MapReduce 是离线批量计算的代表，秉持计算向数据移动的理念，支持计算任务直接在HDFS
上运行，避免了数据的移动，并且采用并行计算的方式，大大缩短了数据处理时间。
二是流式计算框架阶段。Spark 是流式计算的代表， 在MapReduce
框架下进行了优化，可以更高效地使用内存。在内存未溢出的情况下，数据占用内存直接进行处理，减少了数据写入硬盘的次数，降低了I/O 频率，
相比批量计算大幅提高了计算效率。
三是实时计算框架阶段。Flink
可以算得上是继承了历代计算引擎各种优点的高性能实时计算框架，将批处理和流处理相结合，并进行灵活控制，高效实现了数据的“实时计算”。
2. 我国在实时计算领域的实践
2019 年，民生银行信息科技部对实时存贷款规模系统进行了重大改进，搭建了一套以Spark
流式计算为基础框架的系统，能够实时计算和展示全行存款余额和贷款规模。通过采用分布式存储和计算技术，实现了快速高效的数据处理，大幅提高了数据的准确性和实时性。该系统的搭建不仅提升了民生银行的数据处理效率和准确性，也为金融行业的大数据实时处理提供了有益参考。
同年，人民银行成都分行研究了流式计算的主要要素，总结出目前流式计算的5
个典型应用场景：交易市场支持、实时风险防控、实时产品营销、实时监控系统运行和系统智能运维。
2022 年，阿里巴巴集团通过促进阿里云Flink 与Hologres
的合作，实现了实时化全流程的数据探索、敏捷化的数据计算与分析，助力阿里云各业务模块快速构建了企业级实时数据仓库，实现了业务决策的敏捷化和智能化。
二、实时计算在商业银行数字化转型中的应用框架
1. 实时计算Flink 的核心内容
Flink 是一种框架和分布式处理引擎，能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。Flink
设计的初衷是满足在各类集群环境中使用， 通过内存计算和流式传输达到快速和无限规模。在绝大多数配置环境中，Flink
主要有三层体系——接口层、核心层和部署层(如图1 所示)。
图1 Flink 基础架构示意
(1)接口层
Flink 提供了两种数据接口，一是面向流处理的数据流接口， 即流式处理接口(DataStream
API);二是面向批处理的数据集接口，即批处理接口(DataSet API)。通过这两个接口，Flink 可以同时完成流处理和批处理。同样，Flink
的附加应用程序包支持复杂事件处理(CEP)、机器学习(Flink ML)、图计算(Gelly)， 以及两种处理模式需要用到的关系映射接口(Table
API)。
(2)核心层
Flink 主要组成架构中核心层的Runtime
执行引擎具备十分强大的功能，为保障运算能力，该引擎程序有着巨大的代码量，编写非常困难。为解决这一问题， Flink 计算框架将已部署的接口封装至Runtime
执行引擎，支持使用者用此封装接口快速编写流计算程序。其中，静态数据可通过数据集接口完成批量处理，支持Scala、Java
和Python;流数据接口可以对动态的数据进行快速处理，开发人员同样可以用主流的编程语言来实现。
(3)部署层
Flink 延用了Hadoop
分布式的核心思想，使得它可以在数以千计的小型机上运行，把大量的计算任务通过任务管理器分配给多个线程，已分配的部分线程由不同机器执行操作。Flink
也可以保证在发生硬件或软件故障时不会打断计算流，或者通过备份重新模拟一次原来的计算过程，这一功能可以确保实时计算的可靠性。通过上述功能，使用Flink
框架进行计算的数据流具备了高容错特性，可支持用户针对流动的数据进行高速分析和处理(即流处理)。
2. 实时计算在商业银行的应用框架
借鉴上述Flink 基础架构，本文尝试搭建实时计算在商业银行数字化转型中的应用框架(如图2 所示)，以便于各商业银行进一步开展细化探索与实践。
图2 实时计算在商业银行数字化转型中的应用框架
(1)采集层：实时数据采集能力
实时数据的主要来源为客户端、服务端、接口端，具有多渠道、多应用、多场景、多源头的特征，其优秀的实时数据采集能力需覆盖数据源的所有端口，并充分运用与之适配且高效的数据获取方式和对应的技术实现方式完成实时数据获取。针对不同类型数据源的采集方式及使用场景见表1。
表1 针对不同类型数据源的采集方式及使用场景
(2)传输层：实时数据传输能力
与离线数据相比，实时数据具备时效性要求高、传输路径不确定、数据量巨大、变化速度快等特点。为了适应不同业务的需求，商业银行可选择不同的数据传输和存储技术。数据传输涉及吞吐量、速率、成本、安全性、稳定性等五个方面，在传输在线数据时，吞吐量、速率和稳定性等方面更加重要;在传输离线数据时，速率、成本和安全性等则更加重要。在实时计算应用能力框架中，使用Flink
架构中的流式处理接口通过消息队列、任务链等方式形成数据流，进行实时数据传输，相比于传统的批量传输方式传输效率更高。对于离线数据，也可使用Flink
架构中批处理接口进行传输。
实时数据传输能力提供了多数据源的统一在线管理能力，可以集中管理企业所有数据链接信息，并可同时链接多个环境、多个版本的数据源，支持多种类型数据源链接，进而帮助商业银行应对在点对点式链接业务系统中数据同步、采集、传输、分析、展示等方面面临的挑战。
如今，商业银行在数字化转型中经常会遇到数据分散在多个业务系统中存储和管理、数据存储标准不一、端到端业务场景需要在多个业务系统之间实现数据准确传输等问题。实时数据传输能力可以实现数据的实时准确传输，从而更好支撑商业银行业务快速创新。
(3)计算层：实时数据计算能力
实时数据的标准化处理能力：在大数据时代，从各个渠道获取的原始数据往往存在多种数据格式和形态，因此大部分原始数据需要通过数据清洗形成标准一致的数据方可使用。数据清洗的主要步骤包括数据标准化、数据清理、数据核验、编码处理、字段脱敏处理、字段统一处理、数据归并、数据持久保存。针对原始数据的类型，需要通过数据用途的不同选择与之匹配的数据清洗环节，最终将采集到的原始数据转换为可供使用的标准数据。商业银行可搭建一系列实时数据清洗处理程序，使用Flink
计算框架中的Transform 转换算子，将不同类型的数据分至不同分区进行并行计算，再将各分区计算出的最后结果输出至统一的流数据SQL
中进行存储，保障原始数据能够精准、快速地完成数据清理，最终形成标准的数据。
实时数据的加工计算能力：原始数据经过数据清洗形成标准数据之后，需要针对各类业务场景完成数据的计算和加工。数据计算和加工环节包括数据转换、数据过滤、旁路验证、数据排序、集合计算、关联计算、聚合计算、复杂事件识别。在实际使用过程中，数据计算加工可能是上述一个或多个环节的共同动作。与批量处理数据的聚合计算、关联计算等数据处理方式比较，为保证不间断和快速的数据处理要求，可使用Flink
计算框架中的Flink CDC 实时在数据库或文件流中捕获变更的数据，并对需要关注的行为或场景进行实时响应;也可使用Flink 计算框架中的Flink CEP
从数据流中准确识别预设的重点事件。实时计算需满足更加具有时效性和复杂性的数据处理要求，因此需灵活选择不同Flink
计算框架的技术确保其精确性与完成效率。
(4)存储层：多种数据存储能力
实时计算通常要求分布式存储和多种存储结构并存，即针对不同的数据类型及数据读写要求可使用相适配的数据存储结构进行存储，以便在读取与写入的情况下，使数据调用速度大幅增加。在建立实时计算能力框架时，商业银行需结合自身底层的数据存储模式对存储层的数据存储结构进行选择。
按数据组成方式划分，数据存储可分为结构化数据存储和非结构化数据存储，结构化数据库中通常会使用数据关系模型来表达不同的结构化数据及其之间的关系，而非结构化数据库会使用多种方式进行数据存储，包括图数据存储、键值对数据存储等。
按存储介质划分，数据存储可分为内存存储和磁盘存储，其中通过内存存储的数据主要存储在内存中，因此有非常高的运算效率，但受制于硬件配置，内存容量较为稀缺，商业银行可将需要经常调用的数据存放于内存。而通过磁盘存储的数据存储在磁盘上，存储格式可以是文件系统或云存储。数据长时间保存首选磁盘存储，但其I/O
效率明显低于内存存储。
按数据库操作模式划分，数据存储的调用可分为在线事务处理(OLTP)和在线分析处理(OLAP)， OLTP
面向交易场景和产生数据的场景，强调数据的强一致性和并发处理性能，这类数据库具有强大的事务处理能力，适合处理事务密集的应用场景，通常是以单机形式存在;OLAP
面向对已有数据进行分析利用的场景， 更擅长对海量数据进行分析和加总，更多是以分布式集群的形式进行部署。
按数据分布方式划分，数据存储可分为集中式数据存储和分布式数据存储。集中式数据存储是以大型机承载的方式对数据进行集中管理，目前大多数商业银行的数据依旧为集中式存储。分布式数据存储是由不同控制节点以分布式的形式对全量数据进行管理，每个控制节点仅管理全量数据中的一部分(通常称为“分片”)。
(5)管理层：实时数据管理能力
实时数据的控制能力包括技术门槛、技术易用性、技术全过程集中化、治理控制一体化、安全控制运维等。减少繁琐的底层研发操作，提升计算与服务的管控水平，建立一套一站式、高可用、可扩充的实时技术管控平台，
是实时化升级发展的关键支撑。数据管理能力主要包括开发能力、治理能力和运维能力。
在开发方面，商业银行IT
系统开发人员或外包开发人员可在工作台中进行系统整体数据结构建模、数据采集快速部署、实时计算整体逻辑框架搭建和各线程任务调度控制，进而灵活运用采集接口、分布式存储文件系统、任务调度引擎和实时计算算子等已封装在Flink
框架中的开发工具进行实时开发作业。
在治理方面，商业银行数字资产管理人员可在管理层中使用Flink 框架中的流数据SQL 进行简单的SQL
语言调用，实时查找出标准不统一的低质量数据并对其进行清洗或预警。
在运维方面，依赖于Flink
框架的强大计算能力，商业银行运营管理人员可在管理层中打开实时仪表盘或通过动态指标显示屏看到相关数据变动，如商业银行整体资金流动性的实时监测图表、全国各网点业务发生种类及业务数量等。
(6)服务层：实时数据服务能力
批处理信息平台一般是T+1
日给出处理结果，而实时信息技术平台可实现分钟级或秒级的延时，所以必须优先考虑服务的及时性问题。基于信息捕获的主、被动机制，可以把信息数据服务分为订阅模式、推送模式和阅读模式，这三种模式的说明见表2。
表2 信息数据服务模式说明
三、实时计算在商业银行数字化转型中的应用策略
基于上文对实时计算应用框架的分析，笔者针对实时计算在商业银行数字化转型的应用提出以下几点建议。
1. 快速创新应用场景，绘制敏捷反应的发展蓝图
商业银行受网络金融的影响，目前已开始意识到建立实时数据处理系统的重要性，并逐步进行一体化实时数据处理系统(实时数仓、流批一体化数据湖)的设计、建设，希望集成各种实时信息统计分析功能，以形成完善的实时信息处理系统。为此，建议商业银行从研究用户特点出发，拓展实时计算使用领域的范围和深度，制定中长期实时计算系统开发计划，完善实时计算治理体系，形成实时信息计算的基础能力。
2. 制定实时计算架构目标，加快研发实时计算架构
商业银行可根据自身实际规模和信息处理需求，在厘清批处理和实时处理的主次关系后，采取以批处理为主、以实时处理为辅的架构安排，借助批处理技术对历史信息进行处理，并运用实时处理技术对日增量信息进行处理;或者采取完全实时处理的架构安排，通过实时计算建立完备的实时处理框架。
3. 将实时数据应用于数据治理领域，提高实时数据的质量
对于离线数据质量问题，通常采用事前—事后管理方式来解决，即在数据源端改进业务系统，或在出现数据质量问题后采取专项管理方法进行改进。相比之下，
实时数据质量问题需要采用事中管理方式，在实时处理过程中检查数据格式、字节数等方面的异常信息，以及针对不同场景的异常信息进行系统管理，以便对数据异常情况进行跟踪。目前，我国商业银行已经构建了相对健全的数据治理框架，在实时计算框架上线后可及时将实时的数据统筹纳入数据治理体系中同步进行治理。
|
