下面是小编为大家整理的银行金融数据库风险识别与管理实践（全文完整）,供大家参考。
银行金融数据库风险识别与管理实践
当前，随着业务规模的不断拓展以及数据规模的不断增长，分布式平台数据库系统在现代商业银行系统内得到了越来越广泛的应用，而如何进一步提升对分布式平台数据库的风险识别与管理能力，成为商业银行面临的主要技术挑战之一。对此，基于金融数据库的特点和要求，工商银行从数据库设计和运行的角度开展了风险识别与管理研究，同时建立了完整的风险技术监督审计体系。本文重点介绍工商银行分布式平台数据库风险管理的实践路径，并尝试总结了工商银行风险识别检查系统的设计经验。
“十四五”时期，商业银行数字化转型迈入以“可持续金融”“数字金融”“科创金融”为核心的全新阶段，坚持创新与风险防范“两手抓”成为推动金融业健康有序发展的重点工作。在此背景下，工商银行聚焦风险防控难点和痛点，将全面提升金融科技水平与风险管控能力、持续完善自身风险治理体系作为发展金融科技的关键内容，大力推进自主可控技术研究，加速推动信息系统向分布式架构转型。其间，面对各类新技术与分布式平台数据库的广泛应用，如何提升对分布式平台数据库风险识别与管理能力，成为工商银行面临的主要
技术挑战之一。
针对上述难点，工商银行深入挖掘分布式平台数据库的风险场景，组建专业的数据库研究团队，积极探索风险识别与管理方法，并利用全面化、自动化、智能化测试工具，从静态规范检查、数据库变更评估、数据库运行状态监控等维度入手，构建了全面、有效的技术监督审计体系。与此同时，工商银行不断尝试将人工智能、机器学习等新技术应用在分布式平台数据库风险识别与性能优化领域，发明多项专利技术，为广大金融同业提供了可参考借鉴的成功范例。
一、数据库静态风险识别
一般而言，数据库静态风险识别主要指对数据库对象实施静态检查，范围包括使用数据库时所建立的各种数据库对象(如模式、表、列、索引、高级对象等)。实践中，通过静态检查，管理人员可对数据库面临的潜在风险进行判断、分类，并对风险特征和风险后果进行评估，最终形成一份合理的项目风险清单。在此过程中，静态风险识别对象又可进一步分为设计规范风险与版本变更风险两大类。
1.设计规范风险
在银行的各类应用系统中，若数据库对象设计、数据特征设计存在不符合规范的情况，将对数据库存储性能及操作产生直接影响，例如不规范的数据库设计可能会导致数据完整性丧失、数据冗余乃至性能低下，并引发数据插入、删除、更新操作异常等一系列风险问题。
对此，为识别静态数据库规范设计风险，工商银行特别编制了分布式平台数据库应用开发技术规范，并开展数据库设计规范静态风险检查工作，依照数据库、表、列、索引、高级对象等维度，对数据库风险事件进行整理，最终形成了理论检查指引与技术检查脚本，内容涉及数据库、表命名规范、主外键使用规范、索引设计、数据库对象长度策略、分库分区分表原则等多个方面。
此外，工商银行通过对生产运行环境中的数据库对象和特征安装检查点进行审查和监督，有效规避了数据库设计风险，高效达成了提升数据库运行环境稳定性和运维质量的目标。
2.版本变更风险 伴随金融业务需求的持续变化，业务相关存量数据库表结构的变更频次也逐步升高(如删表字段、修改索引等)，尤
其在生产运行环境中，当执行不停机投产数据库表结构变更操作时，可能会因为锁表而阻塞读写请求，存在版本变更超时等风险，并导致用户访问银行业务系统功能时持续受到影响。
对此，工商银行积极探索数据库版本变更风险识别的可行方法，并将其与测试、生产、开发环境联动，对生产运行系统中数据库对象变更所带来的风险隐患进行了重点排查。具体而言，该方法通过解析数据库变更版本包，可提取变更表名、变更 DDL 内容、变更类型等信息，进而将其与生产环境中获取的变更数据库表数据量、访问量等信息联动，用于训练变更风险评估模型，并输出变更版本在生产环境下的预估执行时长。在此基础上，根据大表结构变更、非停机窗口实施影响服务的变更操作等风险评估规则，可输出变更风险等级，形成可预警的数据库版本变更评估系统，精准定位投产期间可能引发超时等问题的变更内容，最终在生产环境实施版本变更前实现数据库风险评估和预警，高效规避数据库版本变更风险隐患。
二、数据库动态风险识别
与静态风险识别相比，数据库动态风险识别更为关注数
据库运行期间存在的风险。例如，通过测试和生产问题经验分析发现，无论是主机还是平台模式，访问路径选择错误均是导致 SQL 执行缓慢的主要原因，此外，具体原因可能还包括无合适索引(索引未建立)、有索引但是选择错误、索引失效等。性能测试是业界发现相关问题的重要手段，但必须配合正确的方法才能尽可能多地识别问题，而企业往往最为缺乏的即是发现、分析问题的方法和经验。为有效识别 MySQL数据库动态风险，工商银行重点关注了大事务风险、访问路径风险和运行指标风险等三类风险。
1.大事务风险 MySQL 数据库一般采用主从复制的方式来实现高可用，主从之间的数据同步基于日志传输，而大事务的产生则通常是因为单事务中包含了过多的 DML，导致网络和目标端数据库无法在短时间内完成处理，从而阻塞了其他交易，造成数据库的“假死”。对此，工商银行将日志大小和 DML 行数作为判断大事务的主要标准，认定超过 10 万行或 100M 的事务归属为大事务。为规避相关风险，工商银行对于联机交易采取了尽可能将事务控制在最小范围的策略，并在逻辑上规定必须是一次原子操作才放入一个事务。此外，对于批量处理大量数据的事务，则执行每 500 笔 COMMIT 一次，并特别关注了 LOAD DATA 和 BATCH INSERT 等内容。
2.访问路径风险 针对访问路径的相关问题，目前业界有两种常见的识别方法，一种是关注 SQL 语句的执行效率，另一种是对访问路径进行分析。其中，SQL 语句的执行效率可以通过慢 SQL 的收集来进行事后分析，也可以借助 AWR 报表或者检查 PM 库下的统计信息表完成。另一种方法则是主动对访问路径进行分析。通常情况下，开发和测试环境中数据量与生产数据的分布以及量级均存在一定差异，如某些 SQL 语句在测试环境中执行速度很快，但在生产环境中却执行速度缓慢。对此，工商银行通过对 SQL 语句的执行计划进行分析比对，并对生产数据库统计信息进行关联分析，有效发现了慢 SQL 没有收集到的“漏网之鱼”。
3.运行指标风险 数据库运行期间的基础数据对于问题分析非常关键，MySQL 作为开源数据库，与 DB2、ORACLE 等商用数据库相比，缺少官方的基础数据收集和配套分析工具。对此，工商银行在运行相关数据时，重点关注了系统资源、数据库连接数等指标。数据库运行指标见表 1。值得注意的是，实际工作中并非只有 SQL 语句执行缓慢会出现问题，如对大结果集的查询也可能出现内存不足(数据库内存或 JVM 内存)、网络阻塞
等问题。
表 1 数据库运行指标
三、数据库风险识别框架
现阶段，工商银行的平台数据库节点规模已经达到上万台，而高效收集风险信息也成为“技术”满足“业务”的关键能力之一。对此，工商银行通过将基础数据获取和风险分析分为两个阶段处理，将功能相近的部分划分为不同模块，实现了系统内及模块间耦合性的完美适配。工商银行分布式检查
系统如图 1 所示，该系统自上而下可分为应用层、存储层和调度执行层。
图 1 工商银行分布式检查系统
1.应用层 应用层即业务逻辑处理层，该层重点实现了风险检查脚本开发、数据分析报表展现、智能运维提升等功能，主要可分为监控视图、检查报表分析与配置管理等三大模块。其中，监控视图模块负责对采集的监控信息进行集中展示，包括数据库运行情况、大事务采集结果、锁信息采集结果、慢 SQL采集结果、风险事件信息等。检查报表分析模块可通过任务控制脚本执行范围和检查范围，以及根据检查结果生成报表任务或根据不同纬度生成统计信息，以便于直观识别高风险应用。配置管理模块重点负责数据库台账信息维护，范围包括主从库信息、宿主机等子系统信息，同时其结合运行监控信息，还可通过规则设置告警事件。
2.存储层 存储层不仅负责存储检查脚本，还负责存储检查结果，前者可通过 GIT 实现，后者则是基于分布式数据库进行存储。其中，巡检脚本管理主要是通过 GIT 仓库对巡检脚本进行版本管理，并使用打包工具将其同步至巡检执行机，以保证巡检脚本实时更新;分布式数据存储则是通过分布式数据库中间件将数据分散存储在不同库中，以提升数据存储能力和响应效率。
3.调度执行层 调度执行层重点负责数据采集，主要功能包括任务调度和巡检执行环境。当前，工商银行的巡检对象主要以分布式MySQL 数据库为主，同时还包括关联系统存储的相关数据，如资源监控系统、链路监控系统、PaaS 云及配置库等。在任务调度方面，该层通过消息队列将任务调度和执行进行状态隔离，且执行器支持以多线程方式并行拉取待执行任务，目前其完成全量 MySQL 数据库任务检查仅需 2 小时。在巡检执行环境方面，为提升处理效率，工商银行采用 zlinux 作为巡检执行环境，充分利用了大型机在 CPU 和多级缓存方面的优势来提升系统性能。
四、新技术探索
实践中，工商银行围绕数据库风险识别与管理的整体目标，搭建了完善、全面的智能识别框架，并从静态风险、动态风险两个维度对数据库风险进行了全面把控。在此基础上，工商银行从夯实数字基建的角度，着重提升数据库风险与管理体系的风险预判、超前预警能力，使用机器学习、人工智能、图计算等新技术进行了一系列探索，并提交相关专利，倾力打造工商银行在数据库领域的专利护城河，全方位提升
数据库的高性能、高安全、高可用属性。
1.高性能 在高性能方面，工商银行深入探索了基于机器学习的SQL 语句执行时间预测方法，并充分利用业务研发中心测试环境优势，通过获取每条待分析 SQL 语句在测试环境的执行情况，对比测试环境与生产环境性能差异，解析 SQL 语句结构信息，结合数据库测试经验对各应用待分析的 SQL 语句开展深度特征工程。同时，通过综合使用统计分析及机器学习方法，对每条 SQL 语句在生产环境下的执行时间进行预估，以及对于预估执行时间过长的重点测试语句组织专业团队进行技术分析，可准确判断是否存在数据库性能瓶颈、是否存在 SQL 语句编写缺陷等风险，并及时发现程序效率问题。此外，该方法通过挖掘、复用测试环境信息，还可在不改变现有投产测试流程的基础上，提升数据库性能与资源使用效率，突破性能瓶颈，最终为数据库相关应用投产提供额外的性能保障。
2.高安全 在高安全方面，工商银行深入探索了一种金融业数据库中数据表关联关系的定位及关联强度定级方法，该方法依据测试环境的数据库基础信息，可构建测试环境中数据库表的
关联关系图谱，并综合使用图联通性算法、图遍历算法、机器学习预测算法，对任意两张数据表之间是否存在关联关系进行判断，同时给出两表关联关系强度的等级划分。此外，该方法通过找到与重要业务系统数据表存在强关联关系的一系列数据表，还可针对关联数据表设计整体测试计划，进而为重要业务系统提供更为全面的安全评估、测试支持及性能容量保障，有效弥补因“木桶效应”带来的安全隐患。
3.高可用 在高可用方面，工商银行深入了探索基于机器学习技术的关键表定级及预测方法，该方法通过找出基础数据表，并界定其重要性等级，支持根据数据表不同的重要性级别来进行不同的高可用设置。通常来说，当期改造难度越大或重要等级越高的业务系统会安排相对较多的测试任务。在此过程中，测试环境数据在相关基础设施中不同数据表的访问次数会呈现出显著的不同，而访问次数的多少及数据表间的关联关系将可以真实反映出当期版本中不同数据表相对于工商银行业务系统的重要程度。此时，通过计算数据表的重要等级，即可针对相对重要的基础数据表进行资源配置优化，为其提供更为充分的高可用保障，进而提升工商银行业务系统整体的高可用能力。
展望未来，随着各行业数字化转型的不断深入，数据或将成为数字时代的“新石油”，而数据库作为极其重要的基础设施之一，更是大数据、物联网、区块链、云计算、人工智能等新兴金融科技的应用基础。顺应上述趋势，工商银行业务研发中心将继续深化数据库基础技术研究，在危机中育新机，于变局中开新局，跟紧时代浪潮，抓住数字化转型机遇，持续运用新技术探索新方向，不断完善数据库风险识别与管理能力，为工商银行积累数据、用好数据、实现深层次数字化转型提供坚实保障!
推荐访问:银行金融数据库风险识别与管理实践 识别 实践 完整