金融扶贫统计名录系统设计优化

金融扶贫统计名录系统设计优化

摘要:

金融精准扶贫工作是我国扶贫工作的重要一环,但由于金融机构无法较好匹配扶贫信息,致使无法高效执行金融定向扶贫要求,最终的工作成效也无法统计。为此,人民银行总行根据需求下发了建档立卡贫困户数据的要求,但因数据量巨大、金融机构应用能力有限等因素,仍未能达到快速提升工作金融扶贫实效。在此背景下建设的金融精准扶贫统计名录查询系统能够有针对性地提供数据检索服务,提高工作效率。本文以该项目为例,重点讨论系统开发的背景以及数据应用难题,从信息安全性设计、批量查询队列设计两方面对系统构架进行分析,并阐述了“双亿查询”优化工程。系统在南京辖区得到广泛应用,效果良好。

关键词:

精准扶贫;系统构架;查询优化

一、研究背景

金融精准扶贫主要是通过政府的政策引导,充分发挥金融市场中介作用,利用信贷、保险等多样化金融手段提高贫困地区的发展以及自力更生能力。为落实国家精准扶贫的工作要求,人民银行总行制定下发了《中国人民银行关于建立金融精准扶贫贷款专项统计制度的通知》。该通知要求银行业各金融机构按时进行金融扶贫相关数据报送,要较好完成相关工作,能够利用统一的扶贫户数据进行精准的贫困户认定。贫困户数据精准匹配存在三大难点。一是人口流动大。由于城市与农村之间、不同地区之间发展不平衡造成贫困人口的地区性流动,如东部沿海、京津翼、长三角、珠三角等地区,民营经济发达、中小企业较多,这些企业雇佣大量外来务工人员,与企业有业务关系的商业银行不能有效识别其中的贫困人口,导致金融精准扶贫贷款的统计数据不准确。二是银行识别能力有限。大中型商业银行在贫困户认定方面具有一定优势,但大部分小型商业银行由于所处地区和自身条件的原因,在贫困户认定方面存在严重不足。如小型银行仅能与当地扶贫办联系,获取贫困户信息有限。三是贫困数据具有动态性。国务院扶贫办为了确保扶持对象精准,对于建档立卡贫困户、贫困地区等基础信息实行有进有出的动态管理,基础信息逐年变化,数据的内容和格式变化较为频繁。为了解决上述难题,人民银行总行每年统一下发由国务院扶贫办提供的全国建档立卡贫困户数据。

二、数据应用难题

人民银行总行将建档立卡贫困户数据下发后,按照计划由各金融机构进行数据应用。但该数据是以省为单位,按地区进行分类,不利于跨省跨地区查询使用。除此之外还有很多数据应用难题。

(一)信息泄露的风险

国务院扶贫办公室提供的建档立卡贫困户的全国数据合计近9000万条,数据包括贫困户的住址、姓名、身份证号码、家庭成员等个人隐私信息。根据国家相关法律及扶贫办的要求,贫困户个人信息须严格保密和妥善保管,不得以任何形式向社会公开。全国共有银行业法人金融机构4000多家,直接把全国数据下发至各个法人金融机构,会造成该项信息安全工作不可控。一旦贫困户信息泄露,可能给相关个人带来严重的负面影响。

(二)数据不一致的风险

金融扶贫贷款享受利率优惠、财政贴息等优惠条件,可能存在金融机构为利率优惠和财政贴息,而虚假增加或修改建档立卡贫困户数据的违规行为,导致贫困户数据不一致。另外,使用过程中产生的误操作也可能导致数据出错、异常等,最终导致各类数据匹配错误、贫困户认定困难、统计分析异常等问题。

(三)数据应用能力不足

全国建档立卡贫困户数据文本文件近14G,小型商业银行技术力量薄弱,如依靠手工打开数据文件进行操作极易造成死机、文件损坏等问题。在进行身份证号码、贫困户号查询时,也无法快速定位多条相关贫困信息,准确性较差且耗费时间长,很难到达银行业日常工作的基本效率要求。

三、系统构架设计

为避免数据应用难题,更好地实现数据“落地”,人民银行南京分行进行应用系统的开发尝试。系统技术选型主要为采用Java语言、DB2数据库进行开发。需要注意的是,系统未使用新型计算机技术,如大数据等技术。应用Hadoop等技术确实能够实现更多数据、更快速的准实时数据查询,但作为单个应用新建平台成本太高。使用新技术所需时间较长、能力要求较高、风险较大,因此系统仍使用传统的关系型数据库(RelationalDatabaseManagementSystem,RDBMS)技术进行开发。另外由于该系统数据应用的特殊性,在进行系统构架设计时也须考虑一些细节,主要内容如下:

(一)信息安全性设计

系统计划使用对象为人民银行南京分行辖区大部分中小银行机构,由于所涉用户较多、贫困户数据管理要求较高,所以系统安全性尤为重要。系统因此在安全性上做了大量的设计,综合应用了一些安全技术,如对用户输入内容进行记录;对输入内容进行特殊字符效验、空字符处理、超长字符串处理等;对用户输入内容查询结果所对应的输入值进行记录等。

(二)批量查询队列设计

系统按查询依据分类有身份证号与户编号模糊查询,按查询方式分类有实时查询与批量查询两种方式。批量查询通过上传指定格式的查询文本文件方式进行,能够实现实时处理百万条记录,该功能使用多线程及线程池技术,并设计简易的队列实现查询的并行与管理。Java线程池有4种方式处理线程:可缓存线程池(newCachedThreadPool)、定长线程池(newFixedThreadPool)、周期性线程池(newScheduledThreadPool)、单线程线程池(newSingleThreadExecutor)。考虑到系统所部署虚拟机与数据库性能因素,系统使用定长线程池方式调度线程,每个线程独立进行业务查询。查询队列主要依据数据库相关表,该表主要包括记录生成时间、状态位、查询文本文件地址、查询开始时间、排序等。表中重要字段有:查询地址记录了服务器上传查询文本文件的相对地址;自定义状态位字段,用作区分该记录所对应查询内容查询状态,主要区分录入、查询中、查询完毕、异常4种状态。相关模块主要有两个:查询模块,包括查询业务功能和相关系统功能;异常处理模块,主要对线程池异常进行监控和处理。业务处理主要由查询模块负责,主要业务流程为:首先通过查询文本地址字段获取查询文本文件,再通过专用的效验功能对文本文件内容进行效验,确保输入的安全性,最后对数据进行检索及数据组装并完成结果输出。查询模块除完成业务处理外,也包括部分系统功能,主要有线程池管理及状态位维护,状态位维护主要由线程池中线程进行维护,如遇到线程池异常则由异常处理模块重置状态位。为确保整个线程池不会因阻塞等异常造成程序长时间无响应,系统使用定时器方式每小时执行一次对数据库队列表的检查,如发现单条数据查询超过一小时则强制重启线程池、线程并清理异常结果、重置状态位等。通过线程池及异常处理模块两层管理确保系统运行稳定。详细队列管理相关构架如图2所示。

四、“双亿查询”优化

人民银行总行相关领导在关注该项目开发工作后,对业务提出一些新的要求。业务部门根据要求提出查询“双亿”概念,即系统能够在原始数据上亿条、批量查询上亿条的情况下稳定运行。根据测试发现原有系统构架无法较好满足系统要求,易出现超长等待、队列频繁假死等情况,需要对系统进行深度优化和重新设计。“双亿查询”优化工作主要分为业务优化与构架优化两个层次:业务优化将批量查询设计为T+1模式,查询文本文件上传后系统夜间进行解析、查询并形成结果,用户可以第二天查看查询结果;构架优化则将部分后台查询彻底与网站分离。使用Windows定时任务夜间调用批处理程序,首先使用独立运行的程序对指定网站上传目录进行检测,如存在查询文本文件则逐个读取并进行数据效验,其次通过批处理直接调用DB2的命令,将查询文本文件直接导入数据库临时表中,再次对临时表中数据与建档立卡贫困户数据进行交叉对比,最后将查询结果导出网站指定目录形成最终结果。数据导入、关键数据查询完全通过调用DB2命令进行处理,极大提高数据查询效率。在此过程中通过批处理、后台专用程序完成文本文件附加信息,如零结果反馈、查询完成时间反馈、异常结果反馈、日志记录等工作。

五、结论

金融精准扶贫统计名录查询系统符合人民银行总行统一下发的建档立卡贫困户数据要求,通过较为合理的系统构架设计,在保证数据安全的前提下,较好地实现对身份证号码、贫困户号的实时查询。有效结合业务构架、系统构架、数据库等多层次的优化,挖掘传统数据库性能,最终实现难度较高的“双亿查询”需求。系统通过细化日志功能、用户管理等辅助模块,最终完成业务需求。系统在人民银行南京分行辖区得到了广泛的应用,有效提高了建档立卡贫困户数据应用的有效性,提高了辖区金融精准扶贫工作。.

作者:骆慧勇 单位:中国人民银行泰州市中心支行

参考文献:

[1]徐云松.金融精准扶贫问题的调查与思考[J].金融理论与教学,2016(3):1-9.

[2]黄承伟,叶韬,赖力.扶贫模式创新——精准扶贫:理论研究与贵州实践[J].贵州社会科学,2016(10):4-11.

[3]陈丽,王锐.基于Hadoop的信令详单实时查询平台构建方法[J].电信科学,2015(7):145-151.

[4]张华强.关系型数据库与NoSQL数据库[J].电脑知识与技术,2011(20):4802-4804.

[5]刘文,王标,王丁.基于Java线程池技术的数据爬虫设计与实现[J].电脑编程技巧与维护,2016(7):8-9.