基于数据仓库的商业银行反系统的架构
作者:汪婙
来源:《软件导刊》2011年第04期
作者:汪婙
来源:《软件导刊》2011年第04期
摘 要:主要阐述了银行搭建统一基础数据平台的必要性和深度挖掘“客户效益”所起的作用,对构建企业级数据仓库平台及实现银行反系统按层作了的详细的设计。
关键词:数据仓库;反;ETL;Business Intelligence
中图分类号:TP309 文献标识码:A 文章编号:1672-7800(2011)04-0160-03
作者简介:汪婙(1982-),女,上海人,上海建桥学院助教,研究方向为电子商务。
1 反系统的构建
1.1 构建目标
构建商业银行企业级数据仓库系统的总体目标分为以下2点:①构建统一的数据平台;②集成现有的核心业务系统、外围业务系统、管理业务系统、前置系统等数据,并进行一致性和完整性整合处理,按主题进行数据重组和格式转换,为银行管理层提供一个真正涵盖全部业务的统一视图,从物理和逻辑上满足数据仓库的建设要求。
构建统一的应用平台。通过完整的系统规划和设计,构造完善的系统体系结构和技术框架,保证系统的可扩充性和稳定性。按照用户的分析需求,使用报表、随机查询、多维分析和数据挖掘和门户集成等多种方式进行数据展现。
1.2 目标定位
商业银行反工作的主要目标定位在:通过检查确认银行在反内部控制制度的制定、执行等各个环节存在的缺陷,促进银行加强管理、降低经营风险;通过对银行交易数据的检查,发现等金融犯罪活动的线索,联合其他监管机构对此类范围活动进行打击,以维护公众利益,保障金融安全。
反系统平台作为开展反信息监控报告工作的核心,并保证反系统的稳定性
、可靠性、安全性及可扩展性。具备特点如下:①商业的全辖业务、反监控报告信息的ETL;②本外币、大额与可疑交易的统一平台;③可疑交易量化模型;④集中的信息数据存储;⑤灵活的计算引擎;⑥可扩展的规则引擎;⑦自动化的流程引擎;⑧完整的反工作处理过程;⑨丰富的反监测、调查与报告功能;⑩灵活的数据报送接口; B11
基于J2EE体系架构的系统平台。
2 系统设计方案
根据反系统的功能需求和上级监管机构对反工作的要求以及银行的内部反工作机制管理的需要,系统从逻辑机构上按以下5个层次进行设计开发,各层次采用灵活的接口设计进行衔接,分别实现不同层面的功能和业务需求。逻辑层次划分如下:
数据采集层、数据存储层、数据处理层、信息管理层、信息报送层
2.1 数据采集层
本系统面向银行的各数据源,提供了灵活的接口进行数据采集。
此外,数据采集层提供了一整套数据采集服务,实现了自动化流程的数据采集、bank文件Excel文件导入等功能。通过各种的加载策略,完成数据抽取、数据转换、数据装载等一系列过程。数据采集逻辑结构如图1所示:
考虑数据安全性,ETL过程的复杂性、合理性等方面,反系统的ETL过程分为两部分:①将外部数据源(数据仓库数据缓冲区或核心平台区)中的数据经过第一次ETL过程,加载到反的数据缓冲区(临时区);②将反数据缓冲区(临时区)中的数据,经过转换和处理,
加载到反数据集市中。
在上述过程中,数据在逻辑上划分为外部数据源,反缓冲区和反数据集市3个数据区域。外部数据源可以是数据仓库的数据缓冲区,也可以是其核心平台数据区,即经过数据路径1或数据路径2,但两条路径互斥。当反数据库和数据仓库在物理上是统一,外部数据源允许,且提供出错处理机制的情况下,也可以将外部数据源直接做为反的数据
缓冲区,从而减少物理存储空间占用,减少ETL环节,提高ETL时间效率。具体处理过程如图2所示:
为了保证反系统的顺利实施,满足监管机构的监管要求,配合银行内部IT建设整体规划,反系统的初次建设以数据仓库的缓冲区(类源业务系统数据模型)作为数据源,ETL过程经过路径1;待数据仓库核心模型建设完成后,反系统进行改造,将数据源迁移至数据仓库核心数据区,ETL过程经过路径2。
2.1.1 数据的抽取
在将数据从数据仓库抽取出来的过程,以非实时的数据采集方式实现,主要有以下几种方式,如下图所示:①第一种方式,是数据仓库将数据“推”出来(出于系统安全性、数据安全性、系统性能等因素),形成数据文件,再使用加载工具读取数据文件。 多适用于数据仓库和反数据库物理上是独立的情况;②第二种方式,是ETL工具通过各数据库连接方式(驱动),访问数据源,读取数据;③第三种方式,加载工具/应用程序通过ODBC/JDBC直接访问数据仓库,将数据直接从数据仓库中抽取出来,对于数据量不大的情况适用。
考虑我行的数据环境,软硬件环境,以及效率等因素,建议采用第二种方式。
2.1.2 数据的转换、分布及存储
作为反数据库的源数据的数据格式通常是相异于反数据模型的。因此数据在进入反数据集市之前都要经历一定的清洗和转化的过程。数据采集服务提供给用户丰富的转化程序以确保其可以满足各种对数据进行净化、重组、关联、标准化和求和的需要,从而使数据更为准确和有用。这些转换方式包括:SQL函数、计算监控数据库转换程序、统计算法以及自定义函数。
2.1.3 数据装载
数据采集服务充分利用目标数据库的快速数据装载功能,将数据装入到反数据库的目标数据库中。数据采集服务中提供的数据装载功能可以和其它数据抽取、转换功能结合在一起被统一调度执行。
一般地,在反数据集市的具体构建中,可以在反数据集市中直接对数据进行加工处理。对于比较大的数据量,往往采用将数据库中表的处理结果写入硬盘,然后再利用快
速数据装入功能装入数据库的方法来提高反数据库的处理速度。
2.1.4 流程的自动化
数据采集服务的定时调度功能有效地减少了在建立反数据库以及日常的抽取数据时所需要的人为的干预工作,可以保证所有流程的自动化。
数据采集服务的引擎调度对每一个采集流程支持如下流程控制:①成功时:指示一个采集流程将在它前面的流程运行成功时才开始运行;②完成时:指示一个采集流程将在它前面的流程运行完成后开始运行,无论前一个采集流程是否成功;③失败时:指示一个采集流程将仅在它前面的流程运行失败时才开始运行。
2.1.5 反数据库的维护
数据库所需的维护量与数据库的活动量或工作负荷量直接相关。为了提高最终用户的查询响应,在日常的维护中需要做如下的工作:创建索引,收集表的统计信息,重组表等。
2.2 数据存储层
本系统产品的数据存储层主要以按数据流向分层保存数据。并根据不同数据应用层次的需要建立不同的数据模型。系统产品分数据层模型与应用层模型,对于数据层模型按照数据层次不同划分为不同的数据模型,对于应用层模型应用角度不同划分为不同的数据集市。
数据层模型:
ODS数据模型:主要用于保存源系统数据,如来源于数据仓库数据。
标准数据源数据模型:主要用于保存反系统用到的数据源表,如客户信息数据、账户信息数据、交易信息数据等原始数据源及手工录入数据源。
应用层模型:
转换规则库:主要用于存储ETL采集过程中的数据转换规则以及数据计算任务。
反规则模型库:主要用于存储反的监测模型以及监测规则。
指标库:主要用于存储计算客户、账户、交易的各类指标数据,并将其应用于反规则的监测。
上报报告库:主要用于存储根据上级监管机构的监管要求,计算产生的反报告数据。
2.3 数据处理层
本系统产品的数据处理层主要是依据反数据集市,对本外币、大额与可疑交易提供交易数据的计算服务、行为的监测规则服务、反处理的流程服务。这些系统服务将由计算引擎、规则引擎、流程引擎构成的核心引擎服务提供。
数据计算引擎:负责进行数据计算、指标计算以及复杂数学公式的计算功能。
指标规则引擎:负责进行统计指标、关键指标、监测规则以及各种分析规则的制定、监测、分析过程。
处理流程引擎:负责处理系统中涉及的各种信息处理流程。
此外,数据处理层除了提供核心引擎服务,还将实现反的处理过程,大体如下所述:①交易数据处理流程;②
大额交易上报处理流程;③可疑交易上报处理流程。
2.4 信息管理层
上面三层主要体现了一些采集方式、反监测规则、核心引擎等后台管理的内容,而反监测与报告系统产品的信息管理层,则通过Web方式为用户提供了一个反信息处理的功能界面操作平台,对可疑的行为进行监测预警、调查分析、跟踪管理以及文件上报等反处理过程。具体功能如图3所示。
本层所涵盖的系统应用功能如下:
系统管理功能。产品的系统管理功能,是一个为用户提供了一个统一的机构、组织、用户、权限以及功能管理的公共控制平台。
系统管理子系统包括以下几个方面的功能:用户管理、角管理、组织管理、功能管理、任务管理、机构管理、参数设定、日志管理。
反监测与上报功能。系统满足上级监管机构提出的反监管要求,实现针对本外币、大额与可疑交易进行监测预警、调查分析、案例跟踪以及报告管理等反处理操作的功能。
反监测与上报子系统包括以下几个方面的功能:参数设定、预警配置、接口管理、预警管理、调查管理、案例管理、报告管理、统计查询、特征分析。
2.5 信息报送层
本系统产品的信息报送层,提供了可复用的反上报接口,快速适应用户业务和报告文件格式的各种变化。本层将实现针对人行反监测分析中心的报送要求进行反数据上报。如图4所示。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论