实战 | 省联社数据下发平台架构优化探索

文 / 湖南省农村信用社联合社信息科技部  龙亚平

随着金融业务数字化和线上化进程加快，农商行对业务数据的需求越来越旺盛，省联社数据下发平台逐渐难以适应这种快节奏的变化，造成省联社和农商行相关的运维工作量增大，却收效甚微。本文拟使用数据库表分区、视图等技术对当前的数据下发平台架构进行改造优化，解决该平台下发数据时存在的时效性、便利性不足，更好地为农商行经营决策提供数据支持。

当前数据下发平台架构的局限性

在IT系统省集中模式下，各农商行接入省联社统一建设的业务系统办理业务，产生数据都集中保存在省联社。为了使农商行能自主利用各业务系统产生的数据资源，满足特色业务系统建设或个性化数据查询需求，省联社于2013年面向农商行开放了数据下发服务。省联社将当日各系统业务数据在日终后汇集，按规则加工后临时存入下发中间库，再以数据文件形式导出，按农商行拆分存放至FTP（文件传输）服务器，各行下载各自数据文件到本地入库后，根据本行需要使用数据。

截至目前，辖内所有农商行都已经申请开通了数据下发vb连接数据库实例下载，每天下发至农商行的数据文件也从最初的20多个增加到200多个。农商行依托下发数据自建了绩效考核、快贷、历史数据查询等个性化系统，为推进业务发展、提高管理效率提供了数据支持。随着下发数据时间跨度、数据内容和接入机构的增加，下发平台的架构局限性也逐渐暴露，主要表现在以下几点。

1.中间环节多，耗时偏长。从省联社生成下发数据vb连接数据库实例下载，到农商行应用数据，中间要经历数据拆分、农商行下载和入库等步骤，需要耗费大约6~8小时，如果遇到网络传输速率或入库技术问题，耗时会更长。通常情况下，农商行要到数据日期的第二天下午或更晚的时间才能有效应用下发数据，逐渐难以满足对业务数据时效性的要求。

2.对基层运维人员专业技术要求高。想快捷使用数据的有效途径是经过数据库访问，目前架构中下发数据库是分散部署在各农商行，为保障各下发数据库正常稳定运行，要求农商行配备数据库专业技术人员，除熟练应用增、删、改、查等语法操作数据外，还要掌握库表设计、空间管理、安全控制以及常见故障处置等数据库运维技能，现形势下大部分农商行缺乏此类专业人才的配备。

3.日常运维工作量大。一是数据补发工作量大。日常运行中，经常有农商行因为遗漏下载、核对失误或软硬件故障等原因造成数据丢失，需要补发时间跨度几天甚至几年的数据，而从海量的已归档数据中筛选出这些需求要耗费大量时间。二是运维人力成本高。下发数据库部署在各农商行，每个农商行每天要耗费1个人力花3~4小时做数据下载、入库和核对工作，从全省角度累计计算，人力成本非常高。三是数据变更难协同。业务是不断发展的，数据表的逻辑结构也会不断更新，一旦下发数据表的逻辑结构有更新，就必须要求每个农商行同步对本行的下发数据库做表结构变更，否则会造成该表后续数据无法更新，此类变更全省同步协调难度大。

优化思路及效果

为突破现有平台的局限性，根据下发数据的应用场景，综合考虑改造工作量和成本，对下发数据平台进行如下改造优化（优化前后架构比较见图1）。取消各农商行自建的下发数据库，将原架构中的数据文件传输平台替换为省联社集中式下发数据库（以下简称“集中下发库”）。

图1 优化前后平台架构比较

通过一系列的改造和整合，新架构较之前有以下三个方面的改进。一是新架构从数据下发到数据应用的过程中，去除了省联社拆分数据文件、农商行下载数据、入库和核对这些中间环节，节省了大量处理时间。二是通过数据库直接为农商行提供数据服务，取代之前下发数据文件的方式，适合目前大部分农商行的科技能力现状，农商行无需在软硬件和下发数据库等运维保障上增加投入，集中精力拓展数据应用场景，在数据安全方面，较文件方式更可控。三是新架构不再有补发数据的需求，数据结构变更也只需在集中下发库这1个节点上操作即可完成，相比原架构中的100多个节点同步做变更，极大节省了运维人力。

如果将原分布在各农商行的100多个数据库节点汇集到省联社的1个节点，我们必须首先解决随之带来的数据库集中访问性能、农商行之间数据隔离等一系列问题。因此，在设计省联社集中下发库时，我们需要应用一些数据库技术，解决性能和安全问题。

技术经验亮点

1.利用逻辑复制提升数据生成效率。数据逻辑复制是基于数据库的一类数据复制技术，通过解析源数据库在线日志或归档日志获得数据的增、删、改变化，再将这些变化应用到目标数据库，达到使源数据库与目标数据库数据一致的目的。在此次优化中，我们利用此项技术将下发中间库配置为源库，将集中下发库配置为目标库，中间配置带条件限制的复制策略（如屏蔽“”关键字的删除语句等）。通过改造，只要下发中间库完成当日数据生成，集中下发库中就已完成新数据的同步，各农商行在T+1日开始营业时就可连接集中下发库，使用最新数据。

2.利用表分区与子分区解决大表问题。全省下发数据集中到一个库存放，必然会遇到大表的情况，大表的存在可能导致查询、插入耗时太长、性能低下，特别当涉及联合查询时，性能会更加糟糕。在此次优化中，针对集中下发库中的大表，在物理设计时我们使用表分区和子分区技术，通过分区，逻辑上是一张表，而物理上已将大表中的数据按规则划分为多个小数据段并散列存放在多个位置，能有效提高数据访问效率。如下发数据中流水表每天的记录数增量是千万级，存量记录数达几十亿，因此做表物理设计时，可以先通过法人机构码将流水表水平划分成若干个分区，然后通过交易日期将每个分区水平划分成若干个子分区，通过分区和子分区，流水表被划分为几十万条记录一个的小数据段。划分后，农商行查询某一天的流水记录效率会有明显提升。

3.利用权限和视图隔离数据访问。在集中下发库中为各农商行分别创建专用的数据库连接用户，每个用户只赋予查询权限，防止下发数据被非法篡改。为实现同一个数据库中各农商行数据访问的隔离，我们引入数据库视图机制。视图是一种展示数据子集的虚拟表技术，通过视图可以让用户只看到指定表中的某些行和列，只提供用户权限内能访问的数据，而不是所有信息，从而起到保护数据，防止信息泄露的重要作用。下发数据中每个表都有法人机构码字段，可将此码作为筛选条件，为每个表创建各农商行的数据视图，不赋予农商行用户数据表的查询权限，只赋予查询本行数据视图权限，各行连接数据库查询时，只会看到数据表中属于本行的记录信息，从而达到各农商行数据隔离访问的目的。

4.利用集群分担单节点负载。未来，各农商行使用下发数据场景越来越多，单台服务器搭建集中下发库的计算能力将达到性能瓶颈，无法满足所有连接需求。我们可以采用数据库集群架构，横向扩展服务器台数，以分摊单台数据库服务器的压力。利用向农商行发布的数据库连接串，可以精细化控制每个农商行固定使用集群中的某台数据库服务器。集群中的各数据库实例共享同一份数据存储，保证数据一致，但独立承担各自的计算负载。集中下发库在设计时对表分区的考虑，以及数据只读访问的特性，降低了各农商行数据在存储和使用上的耦合性，这些都有助于将来集群横向扩展时达到性能线性提升的效果。

本文到此结束，希望对大家有所帮助。