面向大数据商业银行监管报送系统研究.docVIP

面向大数据商业银行监管报送系统研究 　　摘要：为适合新形势下外部监管工作要求，提出了银行监管报送系统整体解决方案。采用大数据处理的分布式计算架构设计及宽表数据模型设计方法，阐述了系统重点功能。通过测试验证了方案的良好应用效果。 　　关键词关键词：外部监管；大数据；分布式计算；数据模型 　　中图分类号：TP319 文献标识码：A 文章编号：1672-7800（2016）004-0157-04 　　0引言 　　随着我国银行业经营环境、业务模式、资金来源的变化，部分商业银行出现资金来源稳定性下降、资产流动性降低等问题，面临的困难和挑战不断增加，为此监管部门提出了加强风险分析、监测与防范的要求。2013年银监会发布《商业银行流动性风险管理办法》[1]，以促进银行业加强流动性风险管理，维护银行体系的安全稳健运行。2014年银监会颁布《银行并表监管指引》[2]，要求商业银行从集团口径进行会计并表、资本并表和风险并表。这些监管要求涉及的报送内容不仅仅是简单的汇总统计数据，还需要客户、产品等明细数据，此外如资本充足率、杠杆率、贷款迁徙率等指标，加工规则复杂、数据覆盖面广，几乎涵盖银行所有主流业务。因此，必须依赖计算机科技，利用现代化技术工具，以全行监管数据大集中模式进行统一化、集中化、专业化加工。 　　1监管数据面临的问题 　　随着商业银行的发展，银行业务越来越广、客户数量越来越大，交易系统越来越复杂，监管部门对监管数据在真实性、准确性、及时性等方面的要求越来越严格，商业银行积累的监管数据也呈几何级数增长。这些规模巨大、类型复杂的数据集合具备典型的大数据“4V”特征[3]，即规模性（Volume）、多样性（Variety）、高速性（Velocity）、价值性（Value）。对这些海量监管数据的搜集、清洗、挖掘、整理、报送等操作也超出了传统银行监管报送系统的能力。在大数据时代，银行监管报送系统面临着挑战。 　　（1）大数据。商业银行每月所需报送的监管报表有数百张，而每月加工这些报表的基础数据量可达TB级。此外监管报表的加工逻辑复杂，动则需要记录上亿条数据表之间的关联运算，增加了大数据处理的复杂度。 　　（2）大用户。由于数据质量不高、部分数据未纳入信息系统等原因，导致很多监管报表无法完全实现自动化加工。因此在每月初的报送期间，总行至基层支行的数千用户会在短时间内集中访问系统进行报表的手工填报，形成大用户量的并发访问。 　　（3）大压力。由于每个用户只负责本级机构的数据报送，因此在报表集中填报期间，用户会提交大量针对单报表、单机构、单币种的计算、校验、汇总等单笔交易，交易峰值最高可达1000笔/分钟。而一个单笔交易往往涉及上百条SQL语句，以单笔校验为例，一般1条校验公式对应的数据更新、删除、插入等操作就有10条SQL语句，按平均1张报表包含40条公式计算，一张报表的一个单笔校验操作所需执行的SQL语句就有400条。以此类推，在业务高峰期，系统每分钟需处理高达40万条SQL语句。同时用户对于这类单笔交易的期望处理时间在秒级，近乎实时处理，这对系统性能提出了巨大的挑战。 　　以往商业银行大多基于数据仓库来满足海量数据处理、统计分析方面的需求，如文献[4]、[5]、[6]开展了数据仓库在银行个人信贷、银行卡、中间业务等不同领域的应用研究。但是传统的数据仓库在银行监管报送领域面临着不足：数据仓库更关注数据统计分析（OLAP），而监管报送既有OLAP，还有大量的报表填报这种小数据量操作（OLTP）；数据仓库一般对当前和历史数据进行处理，而监管报送通常只处理当期数据。因此，对于银行监管报送系统这种OLAP与OLTP相结合的大型复杂混合系统，不能简单用数据仓库技术去实现。本文针对监管报送特点，不仅给出了全面的系统架构方案，还探讨了数据模型及建模方法，并测试验证了系统具备良好的可行性和可靠性，为银行落实数据标准、保证数据质量、固化管理流程提供了重要的科技支撑。 　　2银行监管报送系统架构设计 　　2.1总体架构 　　为满足监管报送时效性要求，特别是解决大数据处理的性能问题，在架构设计中采用了分布式计算架构方案。分布式计算[7-8]将分布的多个计算资源以透明、可扩展的方式连接，以协同解决单台计算机无法解决的复杂计算问题。银行监管报送系统在其核心数据处理层搭建一套分布式计算框架，一方面实现报表在多个计算资源上的并行加工，大幅缩短了数据加工时间，另一方面将造成系统压力最大的日间单笔交易放到计算节点的内存中处理，使原本需在数据库中运行的SQL语句转换为内存变量计算，最大程度地减轻了数据库压力。该架构具备高效并行处理能力、良好的线性扩展能力和动态均衡能力，可以满足系统要求。系统总体架构如图1所示。 　　数据存储层：实现统一数据存储，满足监