浅谈数据仓库与集市构建中小银行的基础数据平台

【摘要】随着国家对金融市场的进一步开放，小型地方性银行的政策性优势也在逐步下降，面对竞争日趋激烈的市场以及高度信息化时代，小银行的发展必须依靠后台科技的强力支撑，“数据挖掘”这一关键词也越来越多的出现在各家银行的规划日程当中。然而数据挖掘的基础“数据仓库”或“数据平台”的建设尤为重要，只有打下坚实的数据基础建设出一套完整的标准化基础数据平台才能更有效的驱动下一步的数据挖掘与分析，以及为日后建立更多样化的管理类分析系统提供强有力的支持。

【关键词】小型银行 数据仓库 基础数据平台 构建

一、背景介绍

近年来随着银行业的不断发展，竞争日趋白热化。外部监管机构、银行管理层、业务部门对决策、管理信息的需求也在不断提高，各种管理信息系统不断引入如：客户关系、绩效考核、管理会计、贷后、风险管理等。银行一方面希望通过先进的技术及管理思想提高自身的管理能力，增强银行在市场上的竞争力，而另一方面，在系统的建设过程中，内部多个业务系统之间又缺乏统一的规范和数据接口标准。因此，在系统建设中经常需要重复建设业务数据的加载功能，这不仅浪费了网络及存储资源，而且会给系统造成过大的压力，甚至产生风险。同时，这些有针对性的数据集市很难做到面向整个银行的全面性、标准性与统一性。面对业务部门及外部监管部门各式各样的数据需求，科技部门的数据提取工作往往会出现一团乱麻，东拼西凑的情况。因此，建立一套统一标准的数据平台已显得非常必要。

余姚农村合作银行是浙江省的一家区域性银行，在浙江省农信联社实现全省核心业务系统与数据大集中后，由省农信联社下发核心业务数据包到辖内各行社，供行社数据分析使用。2012年，为进一步加大对辖内农信系统行社的数据支撑，浙江省信用联社建立了新的业务数据统一下发平台，增加了重要的外挂系统数据源，对下发数据结构进行了优化调整。但由于各行社的规模、管理水平参差不齐，各行社对数据的利用程度也千差万别。我作为合作银行一名数据平台开发人员，根据近几年的工作经验和对农村合作银行数据平台建设的了解，从开发人员的视角提出适用中小银行统一数据平台的建设的思路，力求建立一套全面、标准、统一的基础数据平台，从而解决在以往的工作中所面临的诸多问题，以供同行参考。

二、解决方案的选择

如何建设或到底建设什么样的数据平台才是真正符合小银行自身发展的数据平台，是我们首先需要考虑的问题。明确的目标将指导我们在建设过程中正确的面对应用范围、系统架构、数据结构、开发技术、应用产品、软硬件等一系列问题。通常在明确这些需求时很多人会引入“数据仓库”这个名词，在这之后便是很多高层次的问题，高投入、高性能、高扩展、高冗余、面向主题模型重组、历史性等一系列的问题，当这些问题考虑过之后你将面对的将是一个庞大的、高投入的系统，这要求银行在这方面不单是庞大的资金投入，同时还需要有配套的科技力量予以支撑。

一是TearData、IBM等都是在金融领域有着不错口碑的解决方案提供商，国内很多软件厂商通过这些年与之在大中型银行项目中的积累对于数据仓库的解决方案也都是驾轻就熟。但通常这种概念的数据仓库却并不适用于小型银行。第一是从系统的整体资金投入出发，通常这种系统软硬件合计动辄数百万上千万的投入让小型银行望而却步。其次是从科技投入出发，小型银行的科技力量相对来说比较薄弱，要想深入到数据仓库核心就必然需要有相关科技人员的深度参与，而往往由于科技力量的不足导致系统在建设完成之后难以独立维护，需要依赖于科技公司，甚至被科技公司所绑架。

二是通过对国内几家大中型银行数据仓库模型的分析来看（TearData或IBM解决方案），整个银行的数据系统构成并不单是一个数据仓库（DW）能够解决的。与之配套的必然有业务历史数据库系统（SysHis）、ODS多层次标准化后的业务数据系统等。而数据仓库建设在这些系统之上，是将业务数据模型拆分或重组之后行成星形或雪花形的模型，并且统计与综合业务数据之后才进入仓库。其数据仓库的建设更是着眼于若干年后，通过SysHis+ODS+DW等多系统配合使用来完善企业整体的数据系统。如图1所示：

图1所示，银行的整个数据系统的完善过程必定要耗费大量的人力物理投入，小型银行在资金及人力投入上几乎不可能达到以上的程度，很难建设一套完整的数据系统。但如果从开始就以标准的数据仓库模型架构去建设，随着时间的推移历史数据将大大的丧失其集中的业务属性特性，那么在以后系统的使用过程中将会非常麻烦。所以在这里我的出发点或者说目标就并不是标准的数据仓库，而是适合小银行自身发展的基础数据平台。省去SysHis及DW部分，而通过扩展后ODS系统（图1中第②部分）作为全行统一的基数数据平台。

三、数据平台建设思路

就我所看到的几家大中型银行的标准数据仓库借据方案都来自TD或IBM。从模型设计特征来看，业务数据进入仓库后按照维度被拆分为星形或雪花状。从海量业务数据的角度出发，这种模型设计在数据检索和响应效率上有绝对优势，但同时也因为拆分使得原始的业务系统所下发数据的集中业务属性特征也不再存在。以往在一张数据表中存在的数据将被分拆到以事实表为主题的若干个数据表中，从操作层面来看日后的操作效率将会大大降低。接下来我将根据自己的经验，从系统目标和系统架构方面阐述符合小型银行特点的基础数据平台设计思路。

（一）建设目标

区别于大中型银行，小型银行的数据规模远远低于大中型银行。只要系统架构合理，数据层次清晰，数据效率和存储的问题在小型银行几乎不会存在，我认为小型银行的系统建设重点目标要围绕着以下几点：规模全+标准化+便捷性+历史性+适当的资源投入。

1.规模全。是指系统的数据范围要涵盖各业务系统数据，通过筛选将各业务系统中有用的数据都纳入到数据平台之中。小型银行的数据规模虽然较小，但目前所开展的业务种类却日益丰富，以往单纯的核心系统取数已经很难满足业务部门的需要。因此在平台建设初期就必须要考虑多业务系统并入的原则。

2.标准化。标准化要做到模型标准化、代码标准化以及开发标准化。

模型标准化：各业务系统的数据结构以及命名规范一般都不相同，那么我们需要在数据平台内对其进行统一整改，包括模型名称、字段名称、字段类型等，最终所要达到的效果是在不参照数据字典的情况下能够读懂数据模型中的数据内容。

代码标准化：不同的业务系统会定义自己的代码含义，如同样一个客户状态代码有可能在核心系统与外围业务系统中所表示的意义是不同的，这样我们就需要定义一套标准的代码，尽量在数据进入数据平台之后使用相同的代码。

开发标准化：开发标准化是指在开发过程中需要有一套完整并且标准的开发规范，整个系统的建设都依照规范中定义的规则进行开发，这样在新的人员进入后能很快的进入开发角色。

3.便捷性。便捷性是指要做到开发便捷、使用便捷、维护便捷、拓展及改造便捷。

开发便捷：最主要的是值要逻辑清晰，等级架构层级低，开发语言简单便捷。

使用便捷：指要求最终用户在使用系统时界面友好、操作简单、易上手。

维护便捷：通常在项目上线后能由一个后台+一个前端维护人员即可完成日常的维护工作及小量的开发工作。

拓展及改造便捷：要求能够在外部系统数据结构发生变化是只修改接口模型就能完成绝大部分的改造工作，能便捷的向其他应用系统提供增量或全量数据以及一些基础的加工汇总数据，如账户日均，客户资产负债等。

4.历史性。历史性不仅要求整个系统的历史周期长，同时还要保证历史模型对需求应用的响应效率。

5.适当的资源投入。主要指合适的资金和人力投入。整个系统的设计必须围绕资金投入去考虑，如投入100万的软件费用就需要清晰的认识这100万（40～50人/月）所能够完成的工作目标。否则会对项目的既定目标产生影响。

（二）系统架构

整体数据流向：

业务系统数据文件→到基础数据平台→各个应用系统。基础数据平台采用多层次的具有历史性的ODS系统架构思想，在整个基础数据平台部分对上文中目标所关心的点加以实现。如下图：

1.基础模型层。如图2所示，其中基础模型层保持与业务系统数据结构基本相同，通常只扩展必要的业务日期及系统来源字段，模型采用面向主题的命名规则对模型名称重新统一命名，将各个业务系统中对应的模型划分到不同的主题下（如账户余额、主挡、合同及签约信息、登记簿等划分到协议主题；客户相关如客户信息、地址联系信息等划分到团体主题；交易、流水相关划分到事件主题……），以便于以后使用。

图2中的基础模型层将所有的业务系统数据按照数据特征划分到公共、协议、团体、事件、产品、渠道、总账、其他这8大主题当中，这种主题划分为银行业内使用较多的划分方式。各家银行也可以根据自身的需要进行相应的补充拓展。同时基础模型除数据表名称、字段名称、类型标准化外还应进行必要的代码标准化处理。代码标准化尽量以核心系统代码为主同步到其他业务系统中。以达到在不参考数据字典的前提下能够读懂大部分模型内容的效果。

2.加工模型层。加工层为整个基础数据平台的通用整合层，合理地进行一些基础的业务汇总统计（如账户日均、月均）、模型整合和拆分、分户合并（储蓄、定期存款合并）、全行统一客户视图整合、相关交易流水整合等。完成后的加工层模型力求将常用的数据查询范围由多表向单表进行整合，这样将极大的方便科技人员应对业务部门繁多的数据提取工作。

平台应用层为建立在平台之上的统计分析报表层。这一部分也可以独立BI应用。

3.数据交互。整个系统具有开放性，这三个层次均可对外围应用数据及时提供数据，出于系统整体逻辑性的考虑，基础数据平台与外围系统的数据交互均采取落地文件交互的形式，以避免各系统之间的依赖程度。

4.历史机制。历史性是建立基础数据平台中的关键点，好的历史数据存储机制配合当前性能较高的服务器，对于小型银行来说一般至少能够满足5年以上的历史数据存储。图2中基础模型层采用普通的增量数据模型保存由业务系统下发的每日增量数据，除明细、登记簿及一些公共应用等模型以外的主挡、余额及客户相关数据采用当日模型+历史模型的形式存储，当日模型中储存全量的最新的数据，历史模型中保存每日增量。这样能够使正常业务处理过程中避免直接使用历史数据以保证系统的性能。加工层中尽量整合常用的数据模型后采用拉链历史存储机制进行历史数据存储。这样既能保证基础模型层与业务系统的切合度，又能保证历史数据的使用效率。如下图：

（三）优势及风险

小型银行的科技信息系统正处于发展阶段，很多银行亦在初期阶段，我认为标准的基础数据平台的建设必须着重考虑，无论是独立建设还是依托某一具体的系统建设都需要经过系统的分析，其目标一定要围绕企业发展的需要开展。以上文章中所描述的设计思路的主要优势为：

1.从系统层面来吸收DW数据仓库的优点，按主题划分数据模型，结构清晰、业务贴合度高，科技人员容易且比较好接受。

2.从投入成本来看因为其设计简单，无论从资金投入还是人员投入都要比建设标准数据仓库所要投入的资源低。同时建设周期短，能让企业很快的投入使用，及早的完成更多管理分析系统的建设，以体现其价值。

3.从长远使用来看其在外围业务系统发生变化之后改造成本低，只需要改造接口基础数据层结构即可，同时因为整个基数数据平台采用的标准化的模型设计其更能为企业打造出一套标准化后的基础数据，为日后的DW及应用系统打下坚实的基础。

通过系统整体的实施经验来看，在系统的建设过程中需要注意以下几点：

1.小型银行在建设企业统一数据平台的过程中切不能贪大，在企业自身没有标准的基础数据时尽量避免业务数据模型的拆分。否则将会给日后的系统升级改造及使用埋下严重的隐患。给企业带来不必要的麻烦。

2.数据准确性的保证是整个基础数据平台至关重要的一步，在系统建设过程中一定要有完整的数据校验机制，如总分核对、逻辑层次间核对以及数据完整性检查等，每日的数据批处理完成之后进行上述检查，否则一旦出现数据丢失或完整性缺失而重新处理历史数据将会是一个漫长及痛苦的过程。

3.从系统架构上尽量降低或避免基础数据平台与其他依赖应用集市的紧密程度，如基数数据平台所有与其他依赖的应用系统的交互都采用落地文件的形式，这样可以保基础数据平台不受其他业务系统的影响能够按时完成业务数据处理工作。

以上内容是作者根据多年在银行数据领域所积累的经验之谈，水平有限，考虑问题难免有疏漏，谨供同行参考。

名词解释

ODS：Operational Data Store，ODS具备数据仓库的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。

SysHis：业务系统历史数据库。

DW：Data Warehouse数据仓库。

作者简介：张兵（1987-），汉族，新疆乌鲁木齐市人，任职于宁波余姚农村合作银行，研究方向：软件设计。