GoldenDB分布式数据库支撑国有大行零售贷款业务系统迁移实践

金篆信科GoldenDB 郭啸

数据库是金融信息系统不可或缺的重要组成部分。银行业务系统在用的主流数据库有DB2和Oracle两种，对于大规模的关键型应用，通常采用IBM主机的DB2，对于规模稍小的业务，通常采用基于小机的Oracle。随着互联网飞速发展和金融行业自身变革，金融业务种类快速增长、业务量更是爆发式增加，对数据库的要求也随之变高。传统集中式的数据库，不论在管理的数据规模、可扩展性及成本方面，都难以满足需要。另一方面，现有方案也存在价格昂贵、技术生态封闭、相关技术人才市场萎缩等问题，不利于支撑行内相关业务的长远发展。因此，国产分布式数据库成为了金融数字化转型的新选择。

分布式数据库硬件上基于x86开放技术栈，通过将数据分布到多个节点上的方式达到管理海量数据的目的。这些数据并不是简单的分散，而是有一定的组织结构，同时还要能对外提供统一的访问接口，使得数据分布方式对应用透明，应用可以像访问集中式数据库一样来访问分布式数据库，从而简化应用的开发，降低迁移成本。国产分布式数据库GoldenDB支持分布式事务、横向扩容、两地三中心高可用等各种关键特性，有大行核心业务的商用案例，是符合金融标准的国产分布式数据库。

作为某国有大行分布式能力建设项目群的重点组成部分，金篆信科GoldenDB与客户紧密合作，顺利实现零售贷款业务系统从主机技术栈迁移到x86开放技术栈。零售贷款业务原先运行在IBM主机上，业务采用ALS系统，存储采用VSAM系统（一种基于记录的文件存储系统）。迁移后，业务系统改为自研，存储采用GoldenDB分布式数据库。可知，该业务的迁移范围包括了软硬平台、应用和数据库，改变非常之大。尤其是存储方面，从主机文件存储系统改成了分布式数据库，数据的存储结构、访问方式都完全不同。本文主要介绍数据库迁移的相关要点。

集群设计

在集中式数据库中，由于架构限制，所有的数据在物理上都是集中在一起存储和使用的。但是在分布式数据库中，情况有所变化。首先其所管理的海量数据可能在逻辑上并不都是紧密相关需要统一管理的，而是需要有一定的区分和隔离；其次，分布式数据库的设计原理就是对数据分而治之，充分利用分布式架构的特点，才能达到更好的效果。因此，我们首先需要了解数据库提供了哪些数据存储及隔离的机制，再结合业务访问要求，做好数据的总体组织和管理。

GoldenDB由计算节点、存储节点、GTM节点、MGR节点等多种类型的节点组成。计算节点负责对应用提供服务，存储节点负责保存数据，GTM负责分布式事务的管理，MGR节点负责整个系统的管理和维护。在GoldenDB中，一组相关的计算节点和存储节点组成一个集群，一套数据库可以包含多个集群。集群之间的计算节点和存储节点是独立的，是相互隔离的，事务不能跨越集群。集群内部的多个计算节点和存储节点是一个有机的整体，事务可以跨越集群内的节点。集群相当于数据库内部一个个独立的单元，可用于数据的组织和隔离。

从业务经营的角度上来看，零售贷款业务总体上划分为大陆、海外两大地区。不同地区的监管政策、营业时间、运维计划等都不一样，这就要求在设计时，要为这两个地区预留足够的隔离级别。很自然的，我们可以用集群来隔离不同的地区。

图 1集群设计

如图 1集群设计所示，我们为每个地区规划了一个集群，每个集群有独立的计算和存储节点，这两个是数据库最主要的资源。这意味着不同地区的计算和存储是完全隔离的，一个地区的业务繁忙、存储不足，不会影响另一个地区。

另外，这两套集群共享一套管理节点，这代表我们可以在一套GoldenDB系统中统一监控管理这两个集群，简化运维工作。

数据分片设计

分布式数据库的一大特点就是将数据分散到多个节点上，这样的分布显然不是随意为之的，需要有相应的规则，一方面能灵活控制数据的存储位置，另一方面能便于应用访问。在GoldenDB中，这样的数据分布称为数据分片。分片类似于集中式数据库的分区，对指定列的值进行某种计算，得出该行数据所属的分区。差别在于，分区式将数据划分到不同的存储文件中，而分片式将数据划分到不同的节点中。GoldenDB支持DUPLICATE、HASH、RANGE、LIST、多级分片等多种分片方式。

前面说过，个贷两个集群的业务模型是完全相同的，因此，在讨论数据分布设计时，我们以国内集群为例。数据分片的设计需要符合业务访问要求，因此先梳理业务特点。零售贷款业务内部包含6个子系统，这些子系统之间相互独立，所操作的数据也相互独立，跨子系统的交互通过内呼进行，不允许直接访问其它子系统的数据。其中，账务核心子系统，涵盖全行联机和批量交易，是最主要的子系统，占据90%以上的数据量和访问量，是数据库设计的重点。其余5个子系统主要负责参数管理、作业管理等内容，数据量较小，访问模型也比较简单。

图 2分片设计

零售贷款业务以单账号交易为主，账号间关联少，并且，有多张表按账号关联访问的需求。因此对于账户类的表，适合将数据按账号HASH到所有分片，充分发挥分布式系统的特点，将系统负载均匀分布到所有节点上。

客户类的表与账户表类似，通常从客户号维度去访问，以客户号-账号查询为主，也适合将数据按客户号HASH到所有分片。

剩余的表，主要是各类参数，通常数据量不大，以单表访问为主，少部分可能涉及多表联合访问。为简单计，都设计为单分片表，并且以表为粒度，按数据量排序，均匀分布到多个分片上。对于经常联合访问的表，需要放到同一个分片上，降低访问时的网络IO开销。

数据迁移

完成了数据库的设计之后，下一步就是要进行数据迁移。需要解决两个主要的问题：定长记录如何导入数据库表中，以及如何按分行逐步迁移。

第一个问题，原主机存储使用的是VSAM文件系统，以记录的形式存储数据，且记录是定长的。从主机中导出的数据都是定长记录，而非结构化的行列数据。另外，记录中的字段与表字段也不是一一对应。GoldenDB数据库提供导入工具，支持定长数据的导入。在导入时，可以按长度对记录进行切分，同时还支持对切分出的字段进行合并、丢弃、计算等处理。经过工具的处理之后，数据变成了与表结构相同的结构化形式，可以直接导入。

第二个问题，投产迁移是按分行分批进行，每次投产允许投产行停机。再考虑到分行的数据量在停机窗口内是可以完成迁移的，所以优先考虑停机全量迁移。主机上存储有两份，一主一副。主本是对外服务的，而副本平时是静态的，主副本之间每天日终批后同步一次数据。基于此，每次分行投产时，选择在日终批结束后，等主副本同步完数据，将副本中的投产行的数据导出，然后导入GoldenDB数据库。整个过程涉及导出、转码、导入、校验多个步骤 ，通过数转作业管理系统进行调度，进度可视、过程可控，避免人工操作。

效果

通过调研、设计、开发、测试、仿真、投产等一系列工作，个贷数据库的迁移已全面完成。整个迁移实施分步进行，从2021年5月一家分行投产，到2021年11月全行投产，系统分片数19，总数据量50T，日志量3T/天。

从新系统首次对外服务，至今已有一年多的时间。这一年来系统运行良好。平均响应时间100ms以内，系统成功率100%。可见基于GoldenDB的开放式系统能很好地支撑国有大行业务，具备代替主机DB2的能力。