下文原刊于《金融电子化》2024年12月刊（下），原文标题为“商业银行数据库转型改造实践”。
作者：
华夏银行首席信息官 吴永飞
华夏银行信息科技部 陈刚 王彦博 胡捷
龙盈智达（北京）科技有限公司 王辉
当前，随着银行数字化转型的深入推进以及技术的快速发展，银行数据库转型已成为必然的趋势。然而，从传统商业数据库向国内数据库转型面临着诸多困难，如语法不兼容、迁移难度大、生态不健全等。随着数据库转型改造的逐步深入，华夏银行探索形成了一套可推广、可复制的转型改造方法，并在多项业务上得到了应用实践，推动了国内数据库替代传统商用数据库的改造进程。本文立足商业银行实践，对数据库转型改造从需求分析到部署运行进行了全面的介绍，以期为商业银行数据库转型改造提供借鉴。
银行数据库转型改造面临的问题
商业银行在数据库转型改造过程中面临诸多问题：一是在应用适配改造方面，无论是SQL语法、数据对象，还是驱动程序方面都需要进行一定的适配改造；二是在数据库架构选型方面，是否采用分布式架构，采用的副本数量多少，采用物理机还是虚拟机，同城异地如何部署等都面临着不确定性；三是在数据迁移方面，如何实现数据平滑迁移，保证数据一致性及业务连续性也值得深入探讨；四是在生态建设方面，包括软硬件兼容、第三方支持、接口开放、周边工具、人才培养等方面都有待完善。
华夏银行积极探索数据库转型改造，持续开展了多款数据库的转型试点与推广应用，并积极探索了分布式、云原生等转型改造技术方案；随着数据库产品技术的不断成熟，使用经验的不断积累，逐步形成了较为成熟的转型改造方法。
银行数据库转型改造方法
本文面向银行数字化转型需要，提出图1所示的数据库转型改造“6D”方法论体系，包括需求分析（Demand & Requirement Analysis）、设计规划（Design & Planning）、数据迁移(Data Transfering)、开发适配（Development & Adaptation）、交付测试（Delivery Testing）、部署运行（Deployment & Operations）。
图1：商业银行数据库改造“6D”方法论体系
1. 需求分析
从业务需求分析出发，调研的原有系统的各项指标，包括业务指标：业务规模（业务类型、重要级别等）、数据属性（对象类型、数据大小等）、资源属性（服务器、CPU等）、性能属性（TPS、响应时间等）；数据库指标：兼容性（语法兼容、对象兼容等）、适用场景（OLTP、OLAP等）、基本信息（数据库类型、部署模式等）、运维备份（平台对接、监控对接等）等信息，对各项需求指标进行综合分析，以使业务系统匹配到最适合的产品和架构。
2. 设计规划
设计规划阶段包含数据库选型、高可用架构设计、基础软硬件部署设计等环节。华夏银行基于多种数据库转型改造的经验，自主研发了自动化规划设计模块，以需求分析收集的相关指标为输入，自动输出数据库产品、架构、资源、成本等相关规划建议，供开发人员参考。特别是有些开发人员对数据库不熟悉，该自动化模块减少了选型与架构设计成本，使得开发人员有更多的精力关注到业务逻辑中。
3. 数据迁移
数据迁移是数据库转型改造的重要一环，华夏银行自主研发了“iGo数据库智能迁移工具”，用于解决异构数据库之间的迁移难题，将数据迁移中的评估、改造、执行、交割等流程规范化，具备可视化操作界面，支持自动化、智能化执行数据迁移过程中的各类任务。通过运用iGo工具，不仅能够高效完成数据库系统切换，还能够确保迁移过程的安全可控，并支持必要的回退机制。
4. 开发适配
开发适配涉及异构表结构和特殊对象适配、驱动适配、SQL语法改造、分布式改造等内容，其中，异构表结构和对象适配以及SQL语法改造已经在iGo工具中实现自动化处理。
聚焦分布式改造，对于容量或性能要求高的业务系统，一般需要由原来的单体数据库改造为分布式数据库。分布式改造方法包含图2所示的五个方面。
图2：分布式改造方法
在分片数量设计方面，需结合业务数据量、TPS指标、成本等因素综合考量。分片键设计和分布方式设计方面，针对商业银行业务，在分布式改造确定分片规则时会优先选择具备业务特性且离散性高的卡号等业务要素作为分片键，并采用分布更加均匀的Hash分布方式，可保障数据分布均匀；此外部分公共表（如参数表等）则采用全局表方式，避免了跨分片表关联操作。在标准规范SQL方面，优先选择分片键作为查询条件，并采用分片键作为多表关联查询条件，保障每个节点独立计算，规避跨节点数据传输，最大限度地发挥算力优势。在分布式事务方面，基于业务场景选择最优分片键，尽量将事务限制在一个分片内，有效地规避分布式事务。
5. 交付测试
交付测试主要包括功能测试、非功能测试（负载测试、混合压力测试和稳定性测试等）、高可用测试等，并对不符合预期的测试结果进行优化。优化方面涵盖硬件优化、参数优化、对象优化、SQL优化等。
华夏银行面向交付测试自主研发了图3所示的性能对比模块，通过对比源数据库和目标数据库同样SQL语句的执行时间，直观且快速地定位到性能下降的SQL语句，并提供改写与优化建议。
图3：性能对比模块示意图
6. 部署运行
部署运行主要是将业务应用切换到软硬件新环境，同时启动回退策略，并纳管到运维平台确保部署后故障的快速回退、实时监控与问题处置。为了确保部署后的应用能够稳定与平滑地切换，针对不同类型的应用系统应采用图4所示的不同的切换策略。
图4：不同类型应用系统的切换策略
（1）对于数据量较小、停机时间窗口较长的应用系统，可一次性将数据全量迁移到目标数据库，验证完成后，将应用一次性全部切换到目标数据库，并开启反向复制。该方式操作简单，成本低。
（2）对于数据量较大、停机时间窗口较短的应用系统，切换前需将数据全量迁移到目标数据库并开启实时增量同步；切换时，仅需要同步业务停止后的增量数据，时间很短；验证完成后，将应用一次性全部切换到目标数据库，并开启反向复制。该方式需要定期比对并验证增量数据的一致性，避免因为网络、数据、程序BUG等问题造成的数据丢失。
（3）对于停机时间窗口短且重要的应用系统，主要通过应用侧实现平滑切换，首先通过旁路报文的方式实现并行验证，之后通过应用双写实现双轨并行，定期做数据比对，最后一次性全部切换投产并开启数据库反向复制功能。
在运行维护方面，数据库的种类较多，面临运维平台过多、管理复杂性高等问题。华夏银行自主研发了数据库统一智能运维管理平台，将多种数据库运维平台进行整合，实现了数据库统一管理，减轻了运维成本，提升了运维效率。
华夏银行国内数据库转型改造案例
华夏银行基于数据库转型改造“6D”方法论体系及自主研发的自动化、智能化工具平台，开展了数据库转型改造的推广应用，实现了支付密码等应用系统的国内数据库转型改造。支付密码系统改造后的架构如图5所示。
图5：支付密码系统两地三中心高可用架构图
支付密码系统属于银行支付安全管理和安全控制的重要系统，原先采用x86服务器与Oracle数据库架构，改造后采用ARM服务器与GoldenDB数据库，基于双集群部署模式，实现跨同城双中心双活部署，及异地灾备中心地域级容灾保护。
数据库采用一主多从、高低水位、快同步及DRSP复制等技术，实现同城RPO=0、RTO<60秒，异地RPO<1分钟、RTO<5分钟的目标。整个集群具备故障时自动高可用切换与一键式容灾切换能力，上线后性能提升1.5倍。
该应用系统按照“6D”转型改造流程，从需求分析到部署运行仅用了不到半年的时间，既确保实施的安全与严谨，又有效提升了转型改造的可靠与效率。
结语
本文从国内数据库转型改造面临的诸多问题出发，形成商业银行数据库转型改造“6D”方法论体系，是推动应用系统数据库转型过程中的一种创新性实践。该体系通过六个步骤来确保转型工作的科学规范实施，保证了应用系统数据库转型过程的稳健和高效。在实现数据库改造目标的同时为其他商业银行提供了可参考、可复制的实践经验。
