新一代数据治理平台解决方案

   刊发时间:2016-11-17  


一、客户关注点

1、业务治理

银行业自诞生以来,一直与数据有着紧密的联系。在过去的非电子化时代,数据往往被记录在纸质媒介上。纸质媒介存在保存不便、易读性差与统计分析工作困难等诸多问题。当时银行业的业务品种与交易数量都处在相对较少的阶段。所以这样的矛盾表现的并不是很突出。在进入电子化时代后,银行所有的数据都陆续实现了计算机存储与处理,与此同时伴随着信息时代的到来,数据也显得愈发的重要与珍贵。

这样的情况在最近这些年显得尤其突出。银行即是数据的生产者也是数据的消费者。每日行内的交易产生大量的数据,同时银行业需要大量的数据来进行相关的分析与决策,数据已经成为了银行的生命线,而数据质量就像是这生命线上的重要保障。纵观目前国内银行的数据质量,从行内自身来说,大部分都认为其目前无法完全满足行内的数据消费需求。

大多数银行在想到提升行内数据质量时,都会自然地联想到数据治理。通过确定行内数据标准来约束各个数据项的含义、在行内各个部门明确各个数据项的唯一含义从而去从根本上来消除数据技术错误等问题。但是在实践中,众多的银行发现数据治理所进行的单纯性的数据标准咨询所得到的效果差强人意。并没有从根本上解决行内数据质量低的问题。根据我们的研判,以数据治理为载体的传统数据标准咨询项目存在以下问题:

第一,数据标准与数据质量分离。在传统项目中,往往是以咨询类公司作为主导,他们有着较为丰富的业务知识和能力。能够为行内建立一套大而全的数据标准。绝大多数的咨询厂商都将注意力集中于数据标准的体系与管理建设。但是对于数据治理的终极目的---数据质量却很少有实质性的方法去改善。

第二,缺乏约束流程。传统项目中咨询厂商能够陪同银行走到最终的标准发布这一步,随之而来的就是项目验收,人员撤场。但是众所周知,数据标准不是一成不变的,他会随着各种内部或者外部的驱动而改变。在进行新系统建设时,务必要进行数据结构与数据标准的比对,在落地环节也要指明新建或者修改的系统字段与数据标准的对应关系。只有做到这一点,才能真正的保障数据标准的生命。在现实中,针对数据标准的修订流程存在无法约束的情况,这样数据标准很快就会与实际落地脱节,逐渐的数据标准就不再被当作严肃的事情来对待了。

作为一家会思考的企业,中软融鑫也一直在总结过去、分析当下和创造未来,力求提供一个解决方案能真正从根本上提高行内数据质量。

2、系统建设目标

(1)提供能够完全适配任何第三方厂商数据治理咨询成果的数据标准管理功能。提供数据标准的完整生命周期管理功能,与完整的行内管理流程相适配从而能够使行内的数据标准以及其他成果物真正起到对数质量的提高作用。

(2)提供面向数据质量的数据质量检核体系。提供基于数据标准、监管以及银行自定义的数据检核标准以及规则。对数据进行全面定期的检核与问题纰漏。


二、方案概述

整个系统由两个主要功能模块组成,即数据标准管理、数据质量管理。

1、功能模块

·数据标准管理模块

具备完整的数据标准管理流程,提供多维度的数据标准查询以及检核标准查询。在查询功能之外,此模块最重要的功能就是引进了面向需求的数据标准变更以及落地流程。数据标准是严肃的,因此针对于数据标准的变更也必须要有相应完整合理的流程控制措施。数据标准的变更在模块内以数据标准变更需求为主导,针对每一个需求提出人提出的需求系统都有相应的闭环流程来应对。确保数据标准的变更与落地能够在系统内完全控制和呈现,配合中软融鑫针对行内数据标准管理组织的构架咨询,能够使数据标准真正在行内用起来、管起来。针对已经做过数据标准咨询的客户,此模块也完全支持根据数据标准咨询厂商的咨询交付物进行配置的功能。整个数据标准可以导入到模块中在功能上讲与中软融鑫自身所咨询交付的数据标准并无二异。

·数据质量管理模块

对于银行的重要性目前看来怎么强调都不为过。越来越多的银行意识到数据质量将是未来银行能否增加盈利的基础,而事与愿违的是目前大多数银行对于自身的数据质量都有或多或少的不满。数据质量不高会造成各种各样的问题,从日常经营到统计分析再到监管报表。数据质量的低劣主要表现在两个层面:

第一,技术层面。存储在数据库中的数据可能存在不满足技术标准的情况。例如,客户名称最多只能存储64个字符,大于64个字符的输入其超出部分将会被舍弃。类似于这样的问题会造成数据的改变,使其含义发生变化,带了数据质量的影响。
  第二,业务层面。存储在数据库中的数据之间往往存在一定的业务联系,彼此各种业务联系之间可以用一定的检核方法去进行验证,如果不满足验证关系,则可以判定所涉及的数据存在质量问题。例如,针对一笔贷款合同,其项下的所有抵押合同的金额应该等于贷款合同的抵押物金额。

从以上两个层面来看,如果能对数据进行以上两个方面的检核,并且将所发现的问题暴露给相应的业务人员,将会对行内数据质量的提升带来积极影响。

我们也是从这个角度出发,试图以这样的思维来解决问题。我们意识到所有的检核标准应该具有明确的业务定义,而监管机构所发布的针对于各类监管报表的硬性检核规则就符合这样的条件。如果以监管发布的检核规则出发,结合我们自身在长期监管项目中对数据质量的提升的知识与经验,将可以构造出完善且高度有效的检核规则。针对于监管检核规则无法覆盖的情况,我们亦可以提供自定义的检核规则配置。目前我们依据检核标准所构造的检核规则已经超过两千条,并且还在不断的增加中。

当数据质量问题如何检核的问题得到解决后,另一个难题又摆在我们面前。数据质量问题应该在哪里作出修正?其实一般来看,能够进行数据修正的位置一般有三个:

· 源系统层

· 数据集合层(ODS、DW或数据集市等)

· 数据应用层(例如监管报表中)

在这三个层中,如果数据的整改发生在最后一层,也就意味着我们直接去修改报表层,那么数据修改的效果将仅仅限于这一层内,无法影响到其他监管报表与上游系统。这与我们提高整个监管报送与行内数据质量的初衷不符。所以,显而易见的是,如果数据整改发生在源系统层,将可以一劳永逸的提各个下游系统的数据质量,这才是问题解决的根本之道。为此,在我们针对数据质量模块的设计中,我们的终极目的在于对数据质量问题的暴露与在源系统中的整改。

每周(月)行内数据被抽送至GDS数据质量模块中,数据质量模块在所需数据都到达后将检核规则作用于其上,发现其中的数据质量问题,然后将数据质量问题分发给相应的基层工作人员,指导其在源系统中修正问题。随后,源系统中的数据将会被再次送入数据质量管理模块,模块自动进行整改比对,给出数据整改统计报告。

数据质量模块就是这样一个提供检核规则配置、运行以及数据质量纰漏、分发的模块。利用完善的配置,将数据质量问题分发给相应的负责人。

2、技术架构

平台层次架构图

整个系统采用J2EE多层分布式应用模型。应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。在传统C/S模式中,客户端担当了过多的角色而显得臃肿,在这种模式中,第一次部署的时候比较容易,但难于升级或改进,可伸展性也不理想,而且经常基于某种专有的协议,通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层,这样使得每一层只关注某一逻辑,增强了系统的鲁棒性和稳定性,同时扩展起来也非常容易,当某一层业务逻辑发生了变化时,只需要扩展这一层就可以,使得系统的可维护性大大增强。因此构建一个松耦合的系统在J2EE多层分布式应用模型下变得可实现,整个系统可以真正做到模块化,可插拔部署。

一个多层化应用能够为每种不同的服务提供一个独立的层,以下是 J2EE 典型的五层结构:

· 客户层:客户层指的是访问应用的客户端设备和工具。

· 展现层:负责数据视图在客户端的展现,一般由运行在J2EE服务器上的Web层组件负责处理。

· 业务逻辑层:负责系统业务逻辑的处理,是系统的核心,一般运行在J2EE服务器上的业务逻辑层组件承担处理。

· 集成层:集成层向业务层提供统一的内部和外部资源的访问,为业务层的数据访问请求屏蔽不同的数据存储访问技术。

·资源层:负责系统的数据获取和存储,一般由运行在数据库服务器上的数据库、文件系统、数据仓库、数据交换平台或其他企业信息系统等。

整个系统分为标准的J2EE五层结构——客户层、展现层(表示层)、业务逻辑层、集成层和资源层。这保证了清晰的责任划分以及可维护性和可扩展性,以及系统的健壮性。

前端Web应用服务器采用了基于J2EE技术的ApplicationServer(IBM WebSphere 或 Weblogic),其主要完成系统业务逻辑的处理与用户交互界面的实现。在实际运行过程中,它是通HTTP协议、WebService报表展现服务器进行通讯,通过Socket协议与应用服务器进行通讯。


三、方案特点

1、数据标准全流程支持

本产品支持数据标准全流程管理,将数据标准变更需求的提出、受理、评审、修改、审核与发布环节完整的整合进产品,并且将整个数据标准的生命周期统筹考虑,从而支持数据标准新建与变更流程的灵活配置。在整个流程的不同环节,以不同的标准文档为流转,从而建立起严格并且高效的管控流程。为银行的数据标准精细化管理提供技术依托。在设计上采取灵活的方式,能够与各种不同的行内数据管理组织构架相匹配。

2、第三方数据标准广泛支持

产品对于第三方厂商所进行的数据标准咨询成果物具有广泛的支持,可以无缝导入到系统进行整体维护。针对于每一家不同的咨询厂商所指定的数据标准字段数量、技术属性、业务属性以及管理属性都可以在系统中进行动态的配置与添加。

3、基于数据标准的自动检核规则

在数据标准制定好后,针对于数据标准的不同情况,系统可以有针对性的自动生成相关的检核规则。例如针对数据的数据长度、数据类型、编码类型等等进行自动检核,无需人工配置,节约时间。

4、基于监管机构的检核规则

监管报送产品作为中软融鑫的核心产品具有悠久的历史。在长期的业务与技术积淀中,中软融鑫对监管制度具备较深的理解。各类监管报表对于数据质量具备统一而确定的要求,如何将这些监管的硬性要求转变为在源数据端依然有效的检核标准去对数据质量问题进行早期暴露,也是中软融鑫近几年的研究方向。到目前为止,我们已经将几千条的监管检核规则前置翻译到数据源层面,从而使大量的数据质量问题能够在早期进行暴露出来。

5、基于元数据的自定义检核规则

允许客户进行基于元数据的检核规则配置,提供通用的检核规则配置语义模板,将检核规则配置的难度大大降低。针对于检核规则语义模板所不能支持的情况,系统亦提供了高级SQL规则配置功能。


四、创新 

1、目前的GDS产品中的基于数据源的数据质量检核功能具备创新性,在业界首次提出了类似的方法以及概念;

2、最完整的流程体系,产品将数据标准的各个环节都使用流程严格约束起来,告别了以往同类产品有流程无约束的情况;

3、支持数据标准的历史版本维护,能够从根本上建立起银行数据标准的线上管理与查询;

4、系统的数据质量检核引擎可以建置于各类的数据系统之上,如ODS。通用性与适应性强;

5、通用检核语义模板是针对于自定义检核规则的高效配置。系统内置了十几种针对于不同数据源间表结构的常用检核语义模板,配置时无需编写代码只需要按实际需要填写表名、字段名、条件与阈值即可。

 


五、典型案例

乌鲁木齐银行数据治理项目(GDS系统落地)

乌鲁木齐银行日常各项经营活动中积累了大量数据资源,这些数据除了支持银行生产业务流程运转之外,也越来越多地被用于支撑监管报送、精准营销、决策支持、风险控制、产品定价、绩效考核等运营管理和决策过程的数据分析需求。近几年随着乌鲁木齐银行各项经营业务的迅速发展,对数据的精准度需求也要求越来越高,逐渐暴露出乌鲁木齐银行数据不完整、定义不统一、各系统之间数据不合理冗余等问题,这类问题给我行数据信息服务带来了很大的障碍。

结合以上问题,乌鲁木齐银行启动数据项目,对目前生产存量数据进行完整分析,解决目前生产存在的数据问题;结合咨询数据标准成果及中软融鑫的先进经验,完成数据标准、检核规则的体系建设(包括数据标准标准、检核规则的制定,相应数据设计标准规范文档的梳理,相关制度、组织架构、角色、人员职责的梳理与交付),以GDS平台为依托,对数据标准、检核标准、检核规则等进行系统管理;并且依托GDS平台提供后续新建系统的数据库设计管理功能。


六、联系方式

咨询热线:010-51527500 转 6051

官网链接:http://www.resoft.css.com.cn 

 

版权所有: 中国软件与技术服务股份有限公司 

京ICP备05050114号      400-160-1670