金融业数据库创新发展报告（2023）.pdf

I 2023 年 2 月，习近平总书记在中共中央政治局第三次集体学习会议时强调，“基础软件要从底层和源头抓起，打好科学仪器、操作系统和基础软件攻坚战”。数据库作为构建金融信息系统的关键环节，成为当前金融领域创新及数字化转型的一个难点和焦点。近年来，金融机构不断加大我国成熟数据库产品应用力度，引入不同类型数据库产品在多种业务场景实现应用，在支持金融业务创新发展的同时，逐步提升金融业数据库安全可控能力。但由于我国数据库产品还存在需要弥补的不足，随着数据库改造逐渐深入到核心系统，带来了选型难度高、实施运维难度大等挑战，亟需加大产用联合攻坚、创新应用模式、研发生态工具，推动我国数据库由“能用”向“好用、易用”迈进。同时，数据能力建设对数据仓库、非关系型数据库也提出了新需求，需要加大数据仓库技术创新，分类推动不同非关系型数据库应用发展，促进产品成熟落地。此外，金融业大量采用了开源数据库，面临开源协议、安全漏洞、知识产权、代码感染、开源停服断供等风险，亟需通过加大开源数据库治理、安全防范、建设行业开源社区等措施进行风险防范。本报告从行业应用情况入手，围绕当前业界关注的金融核心系统数据库应用、数据能力提升和开源数据库风险防控三个领域，总结发展成效经验，剖析问题与风险，提出发展建议，展望发展趋势，为金融业数据库创新发展提供参考借鉴。I 1.1.概述概述 .1 1 2.2.金融业数据库应用现状金融业数据库应用现状 .2 2 2.1 金融业数据库应用总体情况.2 2.2 我国数据库产品在金融业应用取得积极成效.5 3.3.金融业数据库应用重点领域分析金融业数据库应用重点领域分析 .7 7 3.1 核心系统数据库应用分析.7 3.1.1 核心系统对数据库应用提出更为严格需求.8 3.1.2 当前核心系统数据库应用面临多重挑战.9 3.1.3 围绕关键环节推动核心系统数据库转型升级.11 3.2 数据库支持数据能力建设分析.14 3.2.1 不同类型数据库助力数据能力建设取得积极成效.14 3.2.2 金融业数字化快速发展对数据库提出新需求.15 3.2.3 分类推动各类数据库应用创新促进数据能力提升.17 3.3 开源数据库应用风险分析.18 3.3.1 开源数据库快速发展并在金融业得到广泛应用.19 3.3.2 金融业开源数据库面临诸多风险.20 3.3.3 多措并举防范开源数据库应用风险.23 4.4.金融业数据库应用展望金融业数据库应用展望 .2525 4.1 我国主流数据库产品成熟度将进一步提升.25 4.2 金融核心系统数据库转型升级将稳步推进.26 4.3 新技术与业务场景将推动金融数据库创新发展.26 4.4 金融业开源数据库应用风险防范仍然不容忽视.27 附录：金融业数据库优秀应用案例集附录：金融业数据库优秀应用案例集 .2828 1 国家的战略部署及金融科技发展相关的多个专项规划，都对关键软硬件信息技术的突破应用、构建自立自强的数字技术创新体系提出了明确目标和要求。金融机构在数字化转型创新发展中，纷纷加快了信息技术的迭代升级，不断引入包括数据库在内新的技术产品，并持续扩大应用广度和深度，金融业信息技术供应链安全整体水平不断提升。作为核心基础软件的数据库，始终是金融业关注的焦点，也是难点。近年来，传统集中式、新兴分布式数据库，关系型、非关系型数据库，联机事务处理型（OLTP）、联机分析处理型（OLAP）、混合负载型（HTAP）数据库，商用数据库、开源数据库等在不同业务场景中实现创新应用，推动构建新一代金融 IT 基础设施，在确保安全稳定的同时，有力支持金融业务创新发展。特别是我国成熟的数据库技术产品在金融业实现了广泛应用，并逐步推动在核心系统应用落地，取得显著成效。但金融业数据库应用还面临一些挑战。一是随着我国数据库产品应用向核心系统深入，其性能、功能及稳定性与国际商用主流数据库产品还存在一定差距，尚不能完全满足金融业核心系统应用需求；二是数据仓库、非关系型数据库对金融业数据能力建设有着重要作用，随着金融业数字化转型深入推进，对非关系型数据库的需求越来越多，对数据仓库功能、性能、扩展性和安全 2 性提出更高要求，亟需提升产品能力满足金融业应用需求；三是开源数据库在金融业应用广泛，但存在开源协议、安全漏洞、知识产权、代码感染、开源停服断供、政策不确定性、掌控及服务能力不足等诸多风险。为推动金融数据库创新发展，以应对面临的挑战和问题，金融信息化研究所组织各方力量，在深入调研、交流研讨基础上，编制金融业数据库创新发展报告（2023），对金融业数据库技术应用进行现状梳理、问题分析、建言献策及成果展示，为管理决策提供参考，为金融机构创新发展提供支持，为我国数据库产业发展提供助力，促进金融科技稳步发展和金融数字化转型深入推进。金融业始终走在 IT 技术应用和发展变革的前列，根据创新发展和安全可控的需要，金融机构普遍采取“先外围、后核心”的策略推进我国数据库产品的应用落地。随着多种类型的数据库产品在金融领域加快应用，促进了金融业务创新，同时也有力支持了我国数据库产业的发展。2.12.1 金融业数据库应用总体情况金融业数据库应用总体情况 一是集中式数据库应用占比较高，分布式数据库应用呈现增一是集中式数据库应用占比较高，分布式数据库应用呈现增长趋势。长趋势。从产品架构看，金融业数据库呈现集中式和分布式并存发展态势。其中，集中式数据库以其较强的功能黏性、优秀的系 3 统稳定性、良好的软硬适配能力，目前在金融业的应用仍占据绝大多数份额。但随着金融业数字化转型的不断深入，分布式数据库因具备依托通用硬件、弹性扩展、内臵高可用等特征，可更有效支持海量、高并发、高吞吐量的新型金融业务应用系统，在金融业的应用占比相较 2022 年调研结果实现了 5.76%的增长。二是二是 OLTPOLTP 数据数据库应用占比较高，库应用占比较高，OLAPOLAP 和和 HTAPHTAP 应用需求不应用需求不断增加。断增加。金融业务系统的数据处理分为联机事务处理（OLTP）和联机分析处理（OLAP）两类。面向客户交易类、业务办理等系统通常选择 OLTP 类数据库，而报表类、分析类系统通常选择 OLAP类数据库。随着金融业数字化进程加快，海量数据让 OLTP 和 OLAP数据库的边界越来越模糊并不断融合，在同一个系统中同时需要OLTP 和 OLAP 能力，即 HTAP 数据库的需求越来越多。通常 HTAP主要应用分为以 OLTP 为主或以 OLAP 为主的两种 HTAP 场景。目前在金融业非融合的 OLTP 数据库占比仍然较高，为 76.83%。同时，不同细分行业中，银行业和证券业应用 OLAP 和 HTAP 数据库占比相对较高。详细情况如图 1 所示。4 数据来源：金融信息化研究所 图 1 金融业 OLTP、OLAP、HTAP 数据库占比情况示意图 三是非关系型数据库在金融业加快探索实践。三是非关系型数据库在金融业加快探索实践。金融业具有客户量大、业务场景复杂等特点，需要存储处理多种类型数据，如庞大的用户、账户、交易、清算、产品、行情等结构化数据和海量的图像、视频、语音等非结构化数据。金融业务需要挖掘海量基础数据所蕴含的丰富信息资源，如隐藏的用户偏好、消费习惯、交易习惯、社会关系等，为非关系型数据库提供了丰富的应用场景，加快了非关系型数据库创新应用。目前，非关系型数据库在金融业应用占比已达到 14.58%。相对证券业和保险业，银行业应用非关系型数据库占比较高。另外，非关系型数据库中键值数据库和文档数据库应用最广泛，二者之和占所有非关系型数据库比例超过 60%；图数据库、向量数据库、时序数据库开始探索应用，其中时序数据库在证券业首先开始应用，占比为 4.8%。金融业非关系型数据库应用占比情况如图 2 所示。93.93%76.17%77.48%79.48%5.25%12.00%11.83%10.95%0.82%11.83%10.63%9.52%0.00%10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%90.00%100.00%保险业 证券业 银行业 金融业 OLTP、OLAP和和HTAP数据库占比情况数据库占比情况 OLTP数据库占比 OLAP数据库占比 HTAP数据库占比 5 数据来源：金融信息化研究所 图 2 金融业关系型、非关系型数据库占比情况示意图 四是开源数据库在金融业得到广泛应用。四是开源数据库在金融业得到广泛应用。与闭源商业数据库相比，开源数据库具有源码公开、使用成本低、获取途径广、对外开放、功能丰富等特点。这些优点使得开源软件得到广大开发人员的青睐，使用人员可在原有代码基础上进行业务适配修改，活跃的社区支持也为日益复杂的业务需求贡献了越来越多的解决方案，从而使得开源数据库在金融业实现了广泛应用。目前，约 90%的金融机构都应用了开源数据库支撑业务发展，其中主要集中应用在一般业务系统和管理类系统。2.22.2 我国数据库产品在金融业应用取得积极成效我国数据库产品在金融业应用取得积极成效 一是我国数据库产品在金融业应用稳妥推进、持续增长。一是我国数据库产品在金融业应用稳妥推进、持续增长。金融业始终走在 IT 技术应用和发展变革的前列，根据创新发展和安全可控的需要，金融机构都在以不同的速度和深度尝试应用我85.42%83.54%89.83%88.23%14.58%16.46%10.17%11.77%0.00%20.00%40.00%60.00%80.00%100.00%金融业 银行业 证券业 保险业 关系型、非关系型数据库占比情况关系型、非关系型数据库占比情况 关系型数据库占比 非关系型数据库占比 6 国数据库产品支持业务发展。为确保安全生产、顺利实施，金融机构普遍采取“先外围、后核心”的策略推进我国数据库产品的应用落地，不断拓展应用广度和深度。调研显示，与 2022 年相比，目前应用我国数据库产品的金融机构数量占比增长约 10%，其中，证券业增幅明显。二是我国数据库在金融业应用优势不断显现。二是我国数据库在金融业应用优势不断显现。金融业应用我国数据库产品，可针对特殊业务场景采取定制化改造，增强业务系统的服务能力，加快业务系统的响应速度，提升业务系统的吞吐量，本地化服务优势明显。同时，我国数据库产品在金融业的应用，一定程度上降低了企业成本，实现了降本增效。相比国外数据库高昂的购买费用和后续的技术服务成本，我国数据库产品后续成本投入相对稳定、成本可控。三是金融业与数据库产业互相促进、发展共赢的成效显著。三是金融业与数据库产业互相促进、发展共赢的成效显著。金融机构在应用我国数据库产品时持续进行产品能力测试，识别产品能力上的缺陷并不断反馈给数据库厂商，推动数据库产品能力提升。而且金融业拥有丰富的业务场景，我国数据库产品在大量的实践应用以及上下游产业的共同发展中，整体数据库能力、兼容性能力都有明显提高。随着我国数据库产品成熟度的不断提升，加快推动了新一代金融 IT 基础设施建设，不断夯实金融业数字化创新发展的基石。7 随着我国数据库产品在金融业的不断推广应用，数据库改造逐渐深入到核心系统，金融机构普遍认为我国数据库产品在核心系统应用还有较大提升空间。当前，数字金融快速发展，数据仓库和非关系型数据库有力支持了金融机构开展数据挖掘和分析，推动数据能力建设，助力金融业务创新。另外，根据调研统计，约 90%的金融机构使用开源数据库支撑业务发展，而开源数据库应用面临着开源停服、协议风险、安全漏洞等多方面的风险，且大部分金融机构仅具备开源数据库的日常管理运维能力，仅少量大型金融机构具备代码级维护及二次开发能力。为此，本章主要从业界关注的核心系统数据库应用、数据仓库和非关系型数据库支撑数据能力建设、开源数据库应用三个重点方向，从深入应用、加大创新、防范风险三个视角来分析金融业数据库应用需求、面临的挑战，并提出下一步发展建议。3.13.1 核心系统数据库应用分析核心系统数据库应用分析 核心系统被喻为金融机构 IT 建设皇冠上的明珠。因其高可用、高可靠，高并发、高实时、高扩展、高安全等特性鲜明，要求提供 7x24 小时不间断服务能力，在信息系统中具有十分重要的地位，事关金融业务实现、金融安全稳定。因此，进行核心系统数据库转型升级牵一发而动全身，需要全面分析转型需求、面临的挑战，总结经验，推动转型实施。8 3.1.13.1.1 核心系统对数据库应用提出更为严格需求核心系统对数据库应用提出更为严格需求 一是功能方面，一是功能方面，核心系统新引入的数据库除了支持传统数据类型、对象类型、SQL 以及 PL/SQL 等基本功能外，特别需要在驱动、语法、架构等方面实现与现有国际主流数据库的兼容。且核心系统需要与交易、结算、风控等不同系统进行无缝集成，所以，需要核心系统数据库支持常用的数据接口和标准协议。同时，对于业务量大、性能要求高的核心系统，需要数据库适配新一代分布式、共享存储集群等架构体系。二是在性能方面，二是在性能方面，核心系统对性能的极致要求，需要数据库具备极强的高并发、高速读写能力，以及满足低延迟、强实时性要求，并具备灵活的扩展性。核心系统数据库交易处理能力需稳定支持 1 至 2 万 TPS，峰值支持 2 至 4 万 TPS。核心系统的 OLTP 场景要求数据库响应时间能够达到毫秒甚至亚毫秒级别，OLAP 场景要求数据库响应时间能够达到秒甚至毫秒级别。此外，在分布式场景下，对数据库弹性扩展能力提出更高要求，实现自动在线横向扩展，扩展后性能呈线性增加，无明显损耗，且根据业务量的变化实现对数据库资源的弹性扩/缩容，以应对业务快速增长和海量数据处理需求。三是鲁棒性方面，三是鲁棒性方面，核心系统数据库需要具备稳定性、高可靠性和高可用性。在负载、数据量或者其它环境因素急剧变化时，核心系统数据库依然能提供稳定的、可预期的服务能力。核心系 9 统数据库需要满足金融核心业务对数据 100%可靠、99.999%以上的可用性极致要求。同时灾备能力要求 RTO 为秒级，RPO 为 0，且要求核心系统数据库能在线修复或者能自检测并自愈，保证金融服务的实时性和连续性。四是安全方面，四是安全方面，核心系统的数据不仅包括业务数据，还涉及到客户的敏感信息，其数据库在安全方面要具备“3A+E”（认证：Authorization、授权：Authentication、审计：Audit、加密：Encryption)的能力。通过提供数据库层的身份认证、访问授权、行为审计，保证正确的人、在正确的时间、以正确的方式访问正确的数据，并留下访问痕迹以供事后审计。随着数据资产化进程的加快，越来越强调精细颗粒度的访问授权。同时，为了防止数据泄露、失窃，多层次、多场景、基于商用密码加密算法的支持，对于多层次、灵活颗粒度的数据脱敏、数据遮蔽的支持也必不可少。3.1.23.1.2 当前核心系统数据库应用面临多重挑战当前核心系统数据库应用面临多重挑战 一是我国数据库产品在核心系统应用还存在多方面能力不一是我国数据库产品在核心系统应用还存在多方面能力不足。足。与国际主流数据产品相比，我国数据库产品在 SQL 优化器、全局事务管理、并发控制、列存和行列混存、共享集群、多读多写等多个关键核心技术上仍然需要打磨和进一步提升；在执行计划、资源利用、任务并行、算法、IO、存算分离等方面与国际商用主流数据库产品仍有一定差距。关键技术能力欠缺不利于我国 10 数据库产品在核心系统的顺利落地应用。另外，核心系统数据库需要有强大的技术支持服务体系，以及时解决运行过程中出现的问题，目前我国数据库相对国际商用主流数据库在该方面也存在不足。二是我国数据库产品灾备和数据同步水平还难以完全满足二是我国数据库产品灾备和数据同步水平还难以完全满足核心系统需求。核心系统需求。根据核心业务系统多活容灾建设需求，我国数据库产品在异地 RPO、故障切换和灾难恢复时间等灾备能力与核心系统要求还有一定距离。同时，在采用新旧系统并轨运行模式，确保核心系统转型的平稳过渡，实现核心系统异地容灾，以及在核心系统数据库作为周边系统为数仓、数据中台、客服系统等提供实时数据时，都需要进行数据同步，这些对数据库的数据同步能力提出了很高要求。三是核心系统数据库创新实施及运维管理难度大。三是核心系统数据库创新实施及运维管理难度大。首先，由于核心系统安全稳定运行是金融机构安全生产的关键，在数据库创新实践中选择新引入的数据库要慎之又慎，加之目前我国数据库产品与现有国际商用主流数据库产品还有一定差距，且数量多、技术路线各异、发展的不平衡等多种因素，给核心系统数据库选型带来很大压力。其次，核心系统已建设多年，在数据处理逻辑方面较多依赖数据库本身，通过数据库的存储过程、函数等实现业务规则中的复杂逻辑计算，而这部分程序可移植性差，一般需经过改造才可以在新的异构数据库上运行，这些改造在切流后容 11 易给系统带来功能和性能上的风险。再次，为确保业务连续性，核心系统数据库创新实践通常采取新老系统并行策略，相关的开发、测试涉及新老两套系统，为确保新老系统的功能一致性，极大增加了开发测试难度。此外，现有数据库中存量数据大，迁移工具有限，导致迁移周期长，且由于技术队伍的不稳定、掌握新技术产品的人员有限，进一步加大了核心系统数据库创新实施难度。最后，由于运维的整体自动化、智能化水平有限，不同类型技术产品还难以做到统一运维管理，核心系统引入新的数据库，特别是分布式数据库架构复杂、集群规模庞大、技术多样化、运维管理复杂，进一步增加了运维保障难度，为核心系统安全稳定运行带来隐患。3.1.33.1.3 围绕关键环节推动围绕关键环节推动核心系统数据库核心系统数据库转型升级转型升级 一是加大产用联合创新力度一是加大产用联合创新力度，基于核心系统应用场景打磨优基于核心系统应用场景打磨优 化产品，化产品，提升服务能力提升服务能力。数据库厂商在自我研发、创新同时，还应进一步加强与金融机构的联合创新力度，充分利用在核心应用中复杂、高压、苛刻的场景，对产品进行反复打磨和优化，补齐在核心技术、灾备能力、技术服务能力的短板，满足核心系统数据库创新实践需求。同时数据库厂商需要与操作系统，芯片等数据库依赖的关键软硬件生态厂商展加大容性适配，并进一步依托我国在存储、计算、网络方面已经取得的产业优势和成熟经验，联合创新，实现数据库产品性能、可用性、集约性的突破。例如 12 在高可用高可靠方面，通过主备架构、多主架构、共享存储集群、分布式集群等架构，实现数据库的高可用性和容灾能力，设臵自动故障切换和数据同步机制，确保系统在发生故障时能够快速切换到备用节点，并提供持续的服务。此外，产业侧需要提升数据库服务能力，不仅要提升原厂服务能力，同时也要通过原厂的培训加大数据库认证学习，为用户团队培养更多的数据库人才。二是安全与应用并重，合理选型，高效推动核心系统数据库二是安全与应用并重，合理选型，高效推动核心系统数据库创新实践。创新实践。由于金融业核心系统属于国家关键信息基础设施，核心系统在选择新引入数据库时，首先要考虑金融安全问题，其次考虑业务需求、自身技术实力、成本及数据库产品特性，综合评估后进行合理选型。针对传统核心系统与数据库采取的紧耦合模式带来的改造难度风险，核心系统数据库创新实践需秉承多品牌的策略，避免形成对单一数据库技术和产品的绑定。同时，为了提高应用研发和改造效率，降低后续产品收敛升级改造的成本，需要在技术路线、研发标准方面进行统一约束规范，尽量选择对业务侵入性比较小的数据库，最大限度实现应用与数据库解耦。三是加大生态工具的研发应用，支持核心系统数据库创新实三是加大生态工具的研发应用，支持核心系统数据库创新实践。践。在数据库迁移方面，梳理核心系统常用数据库的特性，分析新引入数据库的实现差异，开发自动化迁移工具，周密设计迁移规则和数据库处理逻辑的对等转换模式，对于源数据库的复杂特性和巨量存储过程提供自动化迁移能力，以降低迁移改造人工成 13 本。在数据同步复制方面，优化异构数据库增量数据复制工具，在新老系统并行阶段，通过数据同步工具进行业务高峰期增量归档数据在异构数据库间的双向复制，实现新老系统业务数据的准实时一致，确保故障场景下能及时回切，提升对外服务的连续性。在数据库开发方面，通过研发友好的功能强大的客户端工具支持数据库设计、开发，提升数据库开发者的工作效率。在测试方面，研发覆盖单元测试、功能测试、性能测试、生产验证和测试管理过程的自动化测试工具链，降低测试人力投入和测试复杂度，提升测试效率。在数据库运维方面，通过完备的数据库运行状态检查、监控、备份、恢复接口和工具，为核心系统稳定运行、数据安全提供保障。四是加强核心系统数据库创新实践的统筹管理、经验总结，四是加强核心系统数据库创新实践的统筹管理、经验总结，逐步形成指导行业实践的方法论。逐步形成指导行业实践的方法论。金融机构应将核心系统数据库创新实践，纳入整体“一把手”重大工程规划中，统筹推进、重点关注，确保资源投入、精心设计、稳步实施。同时建立并行运行机制，明确专业分工，将基础技术和应用技术分开，安排专人进行版本管理和程序发布工作，减少核心业务应用系统开发人员转型难度。另外，在进行核心系统数据库升级优化时，金融机构要充分总结经验，编写部署方案、技术方案、数据库迁移技术指引、数据库迁移测试白皮书、各类工具使用手册等涵盖数据库升级优化全过程的指导手册，形成整套的系统性技术资产、解决方案和方法论，以指导后续核心系统数据库全面升级优化。14 3.23.2 数据库支持数据能力建设分析数据库支持数据能力建设分析 在数字化转型发展中，金融机构需要对海量、多维的数据进行存储管理、分析，挖掘有效信息支持业务发展和经营决策，离不开数据仓库、非关系型数据库的底层技术支撑，从而对数据仓库的迭代升级、非关系型数据库应用探索创新提出了更高要求。因此，需要总结不同类型数据库支持数据能力建设的现状，分析创新发展需求，并提出下一步发展建议。3.2.13.2.1 不同类型数据库不同类型数据库助力助力数据能力建设数据能力建设取得积极成效取得积极成效 一是数据仓库高效支持金融机构数字化经营。一是数据仓库高效支持金融机构数字化经营。由于数据仓库可对异构源数据进行有效集成，面向数据分析场景，支持全局信息共享和决策分析处理，从而受到金融机构的青睐。金融机构通过建设数据仓库进一步加强对不同业务部门数据的集中存储管理，为数据存储、处理、质量管控和安全管控等提供支持，满足快速增长的海量数据处理、高可用、弹性扩展、动态负载管理、融合分析等应用需求，并基于相关算法、模型、工具，支持数据价值挖掘、分析应用，在精细化客户管理、风险管理、精准营销、智能化决策等不同业务场景中发挥高效作用。二是非关系型数据库为金融机构数据能力建设提供新助力。二是非关系型数据库为金融机构数据能力建设提供新助力。近年来，非关系型数据库在海量、复杂关系、多维的数据管理和分析处理中因为查询速度快、高可用、高可扩展性等优势，在金 15 融业实现了较快的创新应用。其中键值数据库因数据类型丰富、高吞吐量、低时延而被大家熟悉，在海量并发场景可为业务提供极致的访问体验。图数据库由于能更好表达数据之间的复杂关联关系,构建包含实体、事件、概念之间关系的图模型，进行复杂的路径分析、社区发现、链接预测等，相比关系数据库能够更好地展现和处理这类数据，在反欺诈、合规风控、投资信贷决策等场景进行了较多应用探索。向量数据库针对机器学习和深度学习中数据的向量表示形式，能实现快速查找和检索，在量化交易，智能风控，个性化投资组合管理以及智能客服、数字人、情感分析、新闻事件挖掘等自然语言处理的不同金融场景中开展应用探索。总体来看，非关系数据库在海量文件存储、灵活快速查询、大数据统计分析、分析决策报表、实时分析、高速缓存、影像图片数据管理、指标标签管理等领域发挥越来越重要的作用。3.2.23.2.2 金融业数字化快速发展对数据库提出新需求金融业数字化快速发展对数据库提出新需求 一是金融业数字化转型深入推进对数据仓库的功能、性能、一是金融业数字化转型深入推进对数据仓库的功能、性能、扩展性和安全性提出更高要求。扩展性和安全性提出更高要求。在功能方面，要求承载数据仓库的数据库系统要支持更大规模的数据存储管理、服务时效性、混合负载能力等。其中存储范围上要容纳海量的内外部结构化数据，还要支持对数据湖等系统中存储的非结构化数据和半结构化数据进行有效管理和高效访问。数据服务要支持批量服务和实时服务，特别是对分布式架构下 OLTP 与 OLAP 业务融合越来越多的场 16 景，对混合负载（HTAP）能力提出更高要求。在性能方面，金融企业级数据仓库处理的数据量巨大、查询条件复杂、服务的业务类型和业务人员众多，对查询、响应效率，高并发、批量加工作业时间窗口等提出了更高的要求。在扩展性方面，随着金融数据量不断爆发式增长，数据的存储、计算需求会随之快速增长，是否具备便捷的扩展、伸缩能力成为金融机构对数据仓库的刚性需求。在安全性方面，要具备数据丢失或损坏时的恢复能力、对敏感数据的保护能力、以及对人为有意或无意的误操作的隔离能力，确保数据和系统的安全。二是数字金融快速发展对非关系型数据库提出更多需求。二是数字金融快速发展对非关系型数据库提出更多需求。随着数字金融快速发展，数据规模迅速增长，金融机构对海量数据的深度分析、事务间的复杂关联分析、数据随时间的变化分析越发重要；人工智能和深度学习技术和应用的迅速发展，使科学计算中的高维向量数据、影音/图片/文档等多媒体的非结构化数据大幅度增加，存储管理这些多模态信息需求也快速增加，都对非关系型数据库提出更多的应用需求。其中，键值数据库需要解决海量并发中热 key 带来的性能挑战，权衡性能和数据一致性的影响，进而提供满足不同业务场景的高性能方案。图数据库需要适应目前金融业应用中标准化程度不高、复制性不强的实际，进行灵活创新应用；同时，不同应用场景对不同架构的图数据库需求差异较大，要求图数据库具备集中式处理和分布式加工两类处理模式的优势，以适应复杂的业务需求。而向量数据库要降低处理 17 金融数据高维特征对性能带来的影响、平衡成本与性能要求，满足数据处理和查询的高实时性要求，对敏感数据进行安全防护，确保数据安全和隐私保护。3.2.33.2.3 分类推动各类数据库应用创新促进数据能力提升分类推动各类数据库应用创新促进数据能力提升 一是加大数据仓库技术创新，不断提升金融机构数据能力。一是加大数据仓库技术创新，不断提升金融机构数据能力。通过利用 MPP 架构、列存储、智能索引、向量化计算等多种技术，提升在大数据量、多表关联复杂计算的能力，提升数据吞吐量和查询计算效率，减少业务决策的停顿等待时间，优化查询能力。利用湖仓一体架构、存算分离架构，满足结构化、非结构化数据存储和计算的多源融合需求，打通多种数据库之间的壁垒，支持构建统一的数据分析平台，满足大数据量、高并发的数据查询请求，为不同的业务弹性分配所需算力，提升数据吞吐量、并发能力。二是利用二是利用 HTAPHTAP 技术助力混合负载类业务系统建设。技术助力混合负载类业务系统建设。OLTP 与OLAP 并存是金融业应用系统常见的场景。在传统 OLTP 类型数据库中，虽能保证高并发读写下的数据强一致，但是在多表关联、大数据量下的数据分析场景中表现稍显薄弱，尤其是在分布式数据库场景下。通过在OLTP分布式数据库上发展的HTAP关键技术，实现一套引擎同时支撑业务系统运行和分析决策场景，避免在传统架构中，在线与离线数据库之间大量的数据交互，为混合负载 18 场景的应用系统开发提供了便利，大幅提升面向复杂查询场景的处理能力。三是分类推动不同非关系型数据库应用发展三是分类推动不同非关系型数据库应用发展。目前键值数据库在金融业的应用较多，在应用时可针对不同的数据规模和业务场景，合理选择分布式集群和读写分离架构，以满足海量并发场景的处理能力和业务访问体验需求，同时加大键值数据库的高可用架构建设，为业务稳定、连续运行提供强有力的保障。对正在快速应用图数据库，注重高效的图数据处理能力、大规模图数据分析能力、可视化和全生命周期的管理能力的提升；使用标准的、符合未来发展方向的图查询语言，采用支持 ISO GQL 标准语言的图数据库产品，提升图数据库的标准化水平；针对不同阶段和业务场景，合理选择单机架构或分布式架构图数据库，进行合理的资源投入和架构设计。对于向量数据库，针对高维数据，选择合适的向量索引方法，以优化数据的查询性能；对于高维向量数据，进行必要的降维或特征选择，以减少数据存储和处理的复杂性，并提高数据处理效率；考虑使用并行计算、分布式集群部署、压缩技术，以满足金融数据大规模处理和实时查询的需求，减少高维向量数据的存储成本。3.33.3 开源数据库应用风险分析开源数据库应用风险分析 经过多年发展、应用，开源数据库在金融业广泛应用于各类业务、管理系统，已成为金融业信息系统的重要组成部分。随着 19 关键信息基础设施领域数据安全问题被提升到国家安全战略高度，在金融业应用国外开源软件存在安全隐患的问题已经逐步得到重视。目前，开源数据库应用除了通用的开源协议风险、安全漏洞风险、知识产权及代码感染风险外，还面临新的开源停服、断供风险，政策的不确定性风险及掌控和服务能力不足风险等，需要全面分析，加强防范。3.3.13.3.1 开源数据库快速发展并在金融业得到广泛应用开源数据库快速发展并在金融业得到广泛应用 上世纪90年代，随着MySQL 1.0版本和PostgreSQL的Stable版本的发布，开启了快速发展和广泛应用的潮流和趋势。随即国内开源数据库也迅速跟进，阿里、腾讯和华为等分别推出了国内开源数据库，并逐渐成为国内互联网行业的主流数据库。而TiDB、OceanBase、IvorySQL、PolarDB 等项目相继推出，越来越多的企业和机构开始应用开源数据库。我国金融业积极拥抱开源技术，纷纷加入主要开源组织，积极参与开源社区互动，并主动组织实施了多个有影响力的开源项目，取得良好效果。其中 MySQL 应用最为广泛和深入，应用生态也较为完善。以邮储银行为代表 PostgreSQL 应用也取得较好效果。近年来，华为、阿里、蚂蚁、腾讯、平凯星辰等我国主要数据库厂商推出的开源数据库在金融行业的应用力度逐步加大，为金融机构有效防控单一供应商风险和日益复杂的供应链安全风险提供了选择。20 3.3.23.3.2 金融业金融业开源数据库面临诸多风险开源数据库面临诸多风险 一是开源协议风险。一是开源协议风险。开源产品通常需要根据特定的开源协议进行发布和分发。不同开源协议的要求和限制差别较大，包括但不限于使用、修改、复制和分发等，给金融机构的选择、使用和分发带来困扰。而且开源产品可能嵌套其它开源产品的部分或全部代码，而这些开源产品可能遵循不同的开源协议，对于用户而言，这是一个极复杂而且隐蔽的风险。同时，不同开源许可协议之间可能存在混合或者不兼容情况，开源协议可以由开源项目背后的开源基金会或者商业机构根据其商业意图进行转换，例如知名数据库厂商mongodb将 AGPL 协议变更为更为严格的 SSPL 协议，在其他一些开源项目中还可以观察到由开源直接转为闭源的事件发生，开源许可证的变更也为金融机构判断评估适用性增加了难度。违反许可证的条款造成违约行为，易导致金融机构面临知识产权侵权等风险，可能会被权利所有人提起专利诉讼并收取费用，影响较大的案例可能导致金融机构商誉受损。二是安全漏洞风险。二是安全漏洞风险。安全漏洞的发现、披露和解决速度是衡量软件安全的一个重要指标。开源数据库是由世界范围内的个人自愿贡献代码，由于错误的代码实现或设计缺陷、开源社区维护度不足、使用者未能及时更新软件版本等原因，可能存在漏洞和安全问题，导致金融机构在使用开源数据库过程中面临数据泄露、身份验证问题、拒绝服务攻击等多种安全威胁。开源数据库往往 21 不会经历太多实际的业务性测试，遇到问题时可能无法得到及时的修复，解决风险需花费大量的时间。对于金融业来说，特别是对于很多中小金融机构，内部开源技术治理还不够成熟，缺乏配套的专业人员和工具，而开源数据库已经将源代码尤其是内核代码开放，对黑客而言开源数据库毫无秘密可守，容易遇到恶意攻击事件，引发数据泄漏问题，无法从根本上保障金融数据安全。三是知识产权侵权、代码感染风险。三是知识产权侵权、代码感染风险。开源数据库细分为两种：一种是源代码由国内数据库厂商完全自研后选择开源模式进行市场推广；一种是国内数据库厂商封装了国外开源数据库内核代码，在此基础上二次开发的代码必须遵守国外开源协议限制，将二次开发的源代码公开，事实上出现了代码感染。虽然这两种数据库都称之为开源数据库，但实际上存在一定差异。前者具备完整的数据库知识产权，是掌握数据库核心技术和知识产权后，选择了开源的商业模式。后者则会被国外开源软件体系限制，存在知识产权、代码感染风险，应用到金融机构关键业务系统可能会埋下安全隐患，引发数据安全问题。四是开源停服、断供风险突出。四是开源停服、断供风险突出。当前，开源软件供应链形势愈加复杂和多样化。一旦开源数据库项目停止开发和维护，金融机构将无法升级数据库系统和获取新功能，亦无法得到此开源数据库相关的技术支持，甚至可能因为缺乏维护导致安全漏洞无法及时修复，会严重影响存量信息系统的运行维护，并带来大量的 22 系统更新需求和额外的成本及风险。目前，接近 90%的金融机构在一般业务和管理类系统应用使用了开源 MySQL，普遍面临MySQL 5.7 版本的停服问题，导致金融机构被迫转型升级至更高版本，面临较大的升级改造压力。此外，开源数据库供应链风险不断增大，一旦国家之间的贸易管制政策蔓延到开源项目，金融机构托管在海外的开源代码资产将面临冻结风险，也会面临复杂的司法纠纷等问题。五是政策不确定性风险。五是政策不确定性风险。相对闭源的专利技术，开源数据库难以通过传统的专利和知识产权保护手段来证明自己的创新性和价值，使得开源数据库在获得资金、政策支持和竞争优势方面受到限制，也导致开源数据库在认定中面临难以评估和认定的困境。目前，金融机构大量使用开源数据库，开源数据库能否认定为符合政策要求对金融机构在数据库产品技术选型、升级迭代策略等方面具有较大影响，导致金融机构在数据库领域的规划布局存在较大的不确定性，也面临较大的技术路线选择纠错风险。六是掌控和服务能力不足风险。六是掌控和服务能力不足风险。不同于商业闭源数据库可提供友好且易于使用的界面和工具，开源数据库需要金融机构具备较强的掌控能力，开发运维团队需要理解和掌握数据库系统的原理、架构、配臵和管理等方面的知识，具备一定的自主解决问题能力，才能确保开源数据库的顺利应用，而大量中小金融机构显然难以满足掌控能力要求。同时，对开源社区的贡献往往属于开 23 发者的个人行为，并非持续性的机构行为，绝大部分机构依然侧重于关注软件的技术研发维护能力，缺乏主动参与开源工作和贡献开源生态的意识和动力，导致金融机构面对开源数据库缺陷与问题时大多处于被动的局面，未能形成良好的产用双方技术共建能力。另外，相比商业数据库提供的全面技术支持和售后服务，开源数据库服务通常依赖于社区支持和开发者社区的帮助，而社区响应的及时性和质量并不一定能够满足金融机构的需求。3.3.33.3.3 多措并举防范开源数据库应用风险多措并举防范开源数据库应用风险 一是加大开源数据库治理，降低开源数据库使用风险。一是加大开源数据库治理，降低开源数据库使用风险。金融机构需要设臵专人进行开源数据库治理，对开源数据库进行合理合法管控，确保合规使用开源数据库。在选择开源数据库时，金融机构首先要考虑其是否安全可控，然后全面考虑其版本稳定性、社区活跃度和更新频度，对相关工具和插件等开展研究，判断开源数据库项目的可持续性和发展前景，积极发展和应用自主开源项目，避免停服、断供带来的风险。同时，在引入开源数据库前，金融机构应进行充分测试和评估，通过搭建测试环境，模拟实际应用场景，进行全场景、全量、重压的测评，评估数据库的性能、稳定性和可靠性，减少由于技术局限性和不确定性带来的风险。另外，配备专业的法律团队或与外部专业法律机构合