商务智能技术在银行业务中基于数据仓库的研究与实现.doc

1、摘要论文选定商业银行应用，分析了国内商业银行的BI实现的模式以及技术。对BI的三大支柱技术为支点，从BI的定义、BI的功能和应用、BI在银行的应用现状展开分析了银行BI的整体架构、核心技术：数据仓库技术、联机分析处理、数据挖掘技术，并且深入到了分布式数据仓库、应用数据库、ETL技术、分区映射、数据建模、维、度量、维的结构集合这些细节技术中结合银行的具体应用进行了分析。关键字：商务智能、数据仓库、联机分析处理、数据挖掘、多维分第 2 页 共 40 页目录论文摘要1目录2第一章、商务智能综述31.1商务智能（BI）的定义31.2BI的功能与应用范围41.3BI在商业银行中的应用现状5第二章、银行B

2、I系统构建72.1.BI系统模型72.2.银行BI实施方案9第三章、银行中BI系统核心技术143.1.数据仓库技术173.1.1.分布式银行数据仓库173.1.2.原始数据库193.1.3.应用数据库203.1.4.ETL技术223.1.5.分区映射(Partition Mapping)263.2.联机分析处理283.3.数据挖掘技术283.4.数据建模293.4.1.维293.4.2.度量303.4.3.维的结构集合313.4.4.建模函数33第四章、总结与展望38参考文献39第一章、 商务智能综述据MetaGroup统计，企业数据仓库以及商业智能市场已达到40亿美元，并有望在2008年底增

3、长至100亿美元。这样巨大的市场份额充分说明了商业智能市场的吸引力。深入了解吸引力的根源，要从商务智能的概念说起。1.1 商务智能（BI）的定义早在90年代末国外企业界就出现了商务智能这个术语，它代表的是为提高企业运营性能而采用的一系列方法、技术和软件。到目前为止，BI还没有准确的定义，大体可以分成方法论、数据分析论、信息系统论以及知识论笔者注：方法论的观点: BI是通过利用多个数据源的信息以及应用经验和假设来促进对企业动态特性的准确理解，以便提高企业决策性能的一组概念、方法和过程的集合。它通过对数组的获取、管理和分析，为贯穿企业组织的各种人员提供信息，以提高企业战略决策和战术决策能力。数据分

4、析的观点：BI是通过获取与各个主题相关的高质量和有意义的信息来帮助人们分析信息、得出结论、形成假设的过程。信息系统的观点：BI是为用户提供OLAP和其他对企业问题进行分析、预测趋势功能的信息系统。知识论的观点：BI是将数据转变成信息，而后通过发现，将信息转变成知识的过程。3 这样几种解释。综合这几种商务智能的解释，并结合软件技术实现，笔者比较认同如下的定义：商务智能（Business Intelligence，简称BI）是运用了数据仓库(DW)、在线分析（OLAP）和数据挖掘(Data Mining)技术来处理和分析数据的技术，它允许用户查询和分析数据库或数据仓库，进而得出影响商业活动的关键因

5、素，最终帮助用户做出更好、更合理的决策18。本文所要研究的商务智能主要是商务智能的软件解决方案，从这一角度来看，数据仓库、在线分析和数据挖掘是BI的三大技术支柱1。数据仓库（Dataware, DW）可谓是另外两种技术的实现基础，是用以更好地支持企业或组织的决策分析处理的的数据集合，它的关键技术包括数据的抽取、清洗、转换、加载和维护技术。数据仓库具有面向主题、集成、相对稳定、随时间不断变化这四种特性。正是这四种特性将数据仓库与传统的面向事务处理的数据库区分开来。在线分析（On-Line Analytical Processing,OLAP），又称之为联机分析，是以海量数据为基础的复杂分析技术。

6、 它支持各级管理决策人员从不同的角度、快速灵活地对数据仓库中的数据进行复杂查询和多维分析处理，并且能以直观易懂的形式将查询和分析结果展现给决策人员。数据挖掘(Data Mining)是和联机分析处理一起，称之为数据仓库之上的增值技术。它是从海量数据中，提取隐含在其中的、人们事先不知道的但又可能有用的信息和知识的过程。数据挖掘可以从数据仓库、数据库或其他数据源来进行，并且数据都需要再次进行选择，选择方式与任务相关。数据挖掘的结果只有进行了评价才能最终成为有用的信息。按照评价结果的不同，挖掘出的数据有可能需要反馈到不同的阶段，重新进行分析计算。常用的方法包括关联分析、分类和预测、聚类、检测离群点、

7、趋势和演变分析等。充分利用三种技术的这些特点，巧妙结合，BI具有了以下功能，并且广泛的应用在了企业业务范围中。1.2 BI的功能与应用范围在信息全球化的大潮流下，信息爆炸的趋势正在加速强化，再加上企业发展的节奏越来越快，复杂性也越来越高，如何聪明的筛选信息、善用信息、形成智慧、有效的支持决策，已经是银行业、电信业、保险业等需要处理海量数据的行业企业所无法逃避的问题。而BI可以说是处理这一问题最为有效的解决方案。从数据角度看，BI使得很多事务性的数据经过抽取、转换之后存入数据仓库，经过聚集、切片或者分类等操作之后形成有用的信息、规则，企业的决策者可以根据这些信息、规则进行正确的决策。从技术角度看

8、，BI经由企业的决策人员以企业中的数据仓库为基础，应用联机分析处理工具、数据挖掘工具对数据进行处理，再加上决策规划人员的专业知识，从数据中获得有用的信息和知识以后帮助企业获取利润。从应用角度看，BI可以帮助用户对商业数据进行在线分析处理和数据挖掘，例如预测发展趋势、辅助决策、对客户进行分类、挖掘潜在客户等等。只是在方案的实际实现过程中，数据和技术如果没有了实际应用作为组建的指导思想，它们也就没有存在价值。所以，解决方案往往在实际当中需要基于这样几种应用方向来设计：（1）客户分类和特点4：根据客户历年来的大量消费纪录以及客户的档案资料，对客户进行分类，并分析每类客户的消费能力、消费习惯、消费周期

9、、需求倾向、信誉度，确定哪类顾客给企业带来最大的利润，哪类顾客进给企业带来最小的利润同时又要求最多的回报，针对不同类型的客户给于不同的服务及优惠。（2）市场营销策略7：利用数据仓库技术实现市场营销策略在模型上的仿真，其仿真结果将提示所制定的市场营销策略是否合适，企业可以据此调整和优化其市场营销策略，使获得最大的成功。（3）经营成本与收入6：对各种类型的经济活动成本核算，比较可能的业务收入与各种费用之间的收支比例，分析经济活动的曲线，得到相应的改进措施和办法，从而降低成本、减少开支、提高收入。（4）欺诈行为分析和预防6：利用联机分析和数据挖掘技术，总结各种骗费、欠费行为的内在规律后，在数据仓库的

10、基础上建立一套欺骗行为和欠费行为规则库，就可以及时预警各种骗费、欠费，尽量减少企业损失。而笔者在实际实践当中，接触到的也正是BI系统在银行业务中的应用。1.3 BI在商业银行中的应用现状国内银行在多年的运作中，积累了大量的客户数据和经营数据。这些数据是企业的宝贵财富。企业的成败得失、经验教训都蕴藏其中。近几年各银行的数据大集中以及系统一致方面已经取得了很大进展，银行每一笔贷款的发放，每一项业务的经营每一个项目的安施，发生的数据在计算机信息系统中都有所记录，BI建制的信息化基础已经具备21。挖掘数据和把握数据中的规律性，使银行运作得更有成效，是每家银行所希望的。2004年9月，建设银行已经完成了

11、江苏、内蒙古等11个省（市、自治区）分行核心业务系统的统一、数据全辖集中的数据处理，实现了上挂南、北两数据中心的工作，行内将统一的数据系统称之为DCC系统（Data Centralization Construct）。而工商银行，中国银行等国有银行以及招商银行、光大银行等股份制商业银行也在不同程度上实现了将分散于各分行的业务数据集中到总行数据处理中心的工程，并且建立起高效、统一的信息处理平台21。正是在这样比较良好的的数据集中的基础之上，各银行已经开始步入提升系统应用水平的阶段。以山东建行为例，银行最核心的功能已经实现由综合实力优越的BI系统来完成。2004年山东建行每天分析出来的结果就有40

12、0多张报表，产生了大约8万多个分析结果，涵盖了全行地市285个核算机构。这些结果能够满足从普通客户经理、县级管理层到高层决策人员的多层需求22。而BI系统在预警方面更满足了银行的特殊需求。根据山东建行信息中心技术经理杨欣华的介绍22，BI的警戒线预警、趋势预警和业务提醒三种功能正是建行预警方面需求的解决方案。银行的营销高层领导在系统的提醒和分类下，能够及时准确地得到市场分析结果，从而能够更早地决策和处理，使他们由指导、策划、控制事无巨细的监管者变为实现规范管理的简约管理指挥员。而趋势预警对收集的信息进行分析处理之后，一旦发现某个业务指标连续多个时间段下降或者上扬，连续的大幅度波动，预测结果的异

13、常走势，系统都可以进行预警提醒。至于业务提醒，是根据信息的重要程度设置的不同的优先级别，以及突发重要事件，来进行提醒的。例如：如果不良贷款的某项指标大幅度波动，通过警戒线预警和业务提醒就可以迅速地提示决策者和相关的业务人员，及时地采取相应的行动。建行的不良贷款率在全国国有大银行中是比较低的，这其中BI系统起了重要的作用。由此可以看出，BI对于银行来说是非常必要而且重要的，所以BI系统的建制更是正当时的，非常紧迫的。本文将在后面的章节中，针对银行的BI建制进行详细的技术方案分析。第二章、 银行BI系统构建如前章所提，银行商业智能的建立需要通过数据仓库的整合，实现对银行所有经营信息和客户信息的有效

14、存储，并针对银行不同的管理决策需要，进行多层次数据加工处理以满足银行管理决策和客户分析的需要。所以，BI系统需要根据这样的系统功能结构来设计，并结合技术的特点进行系统构建。2.1. BI系统模型众多的世界顶级IT厂商业已纷纷介入BI领域，提出了自己的方案体系，如：Business Objects、Brio、Cognos、Oracle、微软、IBM、惠普等。而IBM提出的BI构建模型在项目的架构及流程设计、系统的维护、性能的优化等方面都颇有借鉴价值。下面就IBM提出的“Business Intelligence Methods”BI模型，结合银行需求进行分析。(4)(1)(5)(6)(7)(8)

15、(3)(2)(9)图2.1 IBM BI系统解决模型从上图中，可以看出IBM的BI解决方案由9个模块组成，其中：模块(1)是“可操作的、e-Business、外部数据”,这部分是整个BI解决方案的数据源头，来自银行的各个业务系统，也是银行在数据集中时所针对的数据。模块(2)-(9)则属于BI系统的内部，其中模块(2)“系统管理”是贯穿整个BI内部的系统管理和维护模块，模块(3)“元数据(MetaData) 见本页“3）元数据管理定义”。 ”是贯穿整个BI内部的数据标尺，是最小的数据单位即数据原子，也是数据管理粒度的基础。除了模块（2）（3）是根据管理需要从原始数据衍生出来的数据以外，另外几个模

16、块都是对原始数据进行处理的。数据由模块(1)收集之后，进入模块(4)“数据仓库建模及构造工具”，进而通过模块(5)“中间件服务器”流入模块（6）“数据管理”，进行数据仓库的维护。新的规范好的数据从“数据管理”再通过模块(5)“中间件服务器”的数据访问支持，并流向模块(7)决策支持工具。在模块（7）的决策支持工具模块中可以产生分析报表，然后提供给模块(8)“商业智能应用软件”。通过模块(8)“商业智能应用软件”将数据传送给最终的模块（9）企业信息入口展现。每一模块的具体功能描述如下11：1) 可操作的、e-Business、外部数据是指数据仓库的数据来源，包括在进行的商业运作过程中产生的各种业务

17、数据、电子商务(e-Business)系统运行过程中产生的数据和从企业外获取的商业数据。北京建行的数据从总帐MIS系统，个人信贷业务系统PCB，国际综合业务系统，网上银行系统WBS等，银行原有的业务系统中抽取数据。2) 系统管理对商务智能系统进行管理，包括安全性和验证、权限设置、设备和恢复、监控和调整、审核等。银行工作人员，可以通过BI系统的WEB端，根据系统程序中设定的标志性数据监控全程的系统运作。例如在数据装数过程中，EC程序本身设定了参数tag来判断装数是否成功，如果tag=1则表示本日数据装数成功，WEB端直接截取tag值就可以监控数据的装数过程。3) 元数据管理(Metagata)是

18、用于管理整个商务智能系统的元数据。元数据是关于数据的数据，也就是对数据仓库中的数据加以说明的资料，包括数据存储格式、数据量、数据来源、数据内容的关键字和数据的存储位置等。4) 数据仓库建模及构造工具用于从可操作的和外部的数据源系统中收集数据，并进行清理和转换，然后存入银行数据仓库或部门数据仓库。5) 中间件服务器：用于维护支持数据管理的服务器。实际项目实施中，因为客户要求节省服务器资源，所以并没有设置中间件服务器，而是在系统设计中加强程序维护的设计。6) 数据管理用于管理用户采集的商业信息。商业信息被分成三个层次：最上面是企业数据仓库，集成整个企业的商业信息；中间层是部门数据仓库（一般被称为数

19、据集市），包含部门的商业信息；最底层是个人信息库，用于存放用户个人所需或特殊用途的信息。7) 决策支持工具包括查询和报表工具、在线分析处理OLAP和信息挖掘工具。所有这些工具都支持GUI客户界面，也可以在WEB界面上使用。这些工具能够处理来自不同数据库和文件系统的信息，包括结构化和非结构化的数据。项目中选用了具有目前世界先进水平的MicroStretegy（MSTR）技术平台作为决策支持工具的实现平台。8) 商务智能应用软件提供许多针对不同行业特点或特定应用领域的商务智能解决方案软件包，帮助用户解决在商务活动中所遇到的复杂问题。9) 企业信息入口企业信息入口(Enterprise Inform

20、ation Portal)提供了一个用户与企业的商业信息和应用软件间基于Web的接口。企业的商业信息，不只是被储存在数据仓库中而是分布在不同的系统和应用软件之中。2.2. 银行BI实施方案对于大型集成应用系统，合理的规划是建制成功的关键，并且需要降低开发风险与成本，排除潜在的障碍，这也是北京建行的项目实施原则。结合IBM公司的商务智能系统结构的理论，建立如下一套完整的银行BI系统。（8）系统管理(4)(3)(5)(7)电子报(2)(1)(6)图2.2 银行BI系统实际方案上图中相对于IBM的解决方案存在一些不同之处：这里省去了元数据管理模块，整合到了(5)MSTR模块中，因为针对数据的报表展现

21、、OLAP分析、数据挖掘建立模型形成的元数据需要配置比较集中的管理。至于(3)和(4)两个模拟数据库，采取直接以原始的数据最小粒度来进行数据的整合、清洗、主题划分的方式处理。另外该方案中加入了一个数据流向(7)电子报表，这是根据银行管理的特殊需求设计的。因为(2)外部数据源DCC位于总行，这部分数据是从各个分行下属的营业网点直接传送到总行系统中，并不经过分行，更主要的是分行需要这些原始数据打印相关的报表。出于银行安全考虑（分行必须且只允许从总行得到电子报表数据）采用特殊处理模式。为了兼容原有的管理模式，设定位于分行的数据处理部分(4)模拟应用数据库接收(7)电子报表这条数据流向。而商业智能应用

22、软件模块的功能对于银行来说可以根据未来实际需要定制开发即可，所以暂时没有进行统一规划。因此，完整的银行BI系统结构如下：在此次项目中，银行数据仓库建立成逻辑思想上的两个虚拟数据库，原始数据库和应用数据库，根据数据的转换的性质，他们分别实现不同的功能。模型中（1)和(2)两个模块是分行业务系统的数据和总行DCC返传数据这两大不同的源数据来源，它们遵循源数据表结构不变原则保存在(3)模拟原始数据库，建立全局性原始数据库。而(3)模拟原始数据库的这些数据是可以直接从历史数据管理系统得到总行的DCC返传数据，并且从分行业务系统中抽取数据以实现数据自动采集的。再加上，还需要将一些手工管理的数据纳入到系统

23、中进行管理，于是这些数据就需要补录并且保存在原始数据库或者应用数据库中。补录由银行的业务管理人员来操作，所以需要提供灵活、方便的录入、审批流程和友好的用户操作界面。在上面陈述的这些数据采集过程中，原始数据库需要做的是对数据统一类型，统一管理，使数据符合一致性和有效性，最终消除“蜘蛛网”和数据异构等问题。而字段名称、字段类型和数据说明则仍然需要保留原样。采集到(3)模拟原始数据库中的数据主要是按照主题分类保存，其中包含一些下属分理处已经生成的固定报表、统计报表。这些原始数据通过ETL工具Adt_moia进行清洗、重组，实现数据集市的构造、建模转换以后，经中间件送到(4)模拟应用数据库，进一步转化

24、成为全局性应用数据库中的基础数据集(4)模拟应用数据库中的数据除了从原始数据转换过来部分数据以外，还包括了针对交易数据在原始数据与应用数据库之间关系而遵循映射方式或快照方式建立的元数据，并且还有从下属分理处抽取的部分特定应用主题（例如信贷风险）分类的固定报表、统计报表。这些数据将根据MSTR的OLAP分析、数据挖掘的请求送到(5)MSTR。除了（5）MSTR分析时的调用以外，固定、统计报表还需要接受(6)internet模块的直接查询。(5)MSTR可以根据具体的银行需求，进行数据分析和挖掘，快速灵活的生成各种对应的统计报表以及分析结果，并送到（6）Internet。整个过程不可缺少的还有（8

25、）系统管理模块。这部分包括了监控管理、参数维护、用户权限、日志管理和客户化发布管理，让整个过程在系统监控与管理下进行，实现从数据采集、整合、存储管理到信息应用的整体信息管理及利用的功能。根据以上系统描述可以将各个模块的功能分为数据处理、信息应用以及系统管理这三种，从这一角度又可以将系统看作如下结构：图2.3 BI系统功能分布图数据处理以及系统管理部分在前面已经较为全面的阐述了，而信息应用部分的功能却因为实现得比较分散，所以对信息应用部分在这里做一个总结。信息应用部分包括了报表管理、信息查询、电子文件、数据补录、数据卸载、系统公告等功能模块。信息查询、报表管理以及电子文件功能模块主要实现业务人员

26、所关心的业务数据的信息、报表以及电子文件的查询功能，并且需要设定浏览的不同密级。信息查询按照业务类型分为资产负债类、损益类、客户类、产品类、其他类。而电子文件因为是直接从源数据保存而来，未进行任何处理，需要在这一模块中配置管理及检索的功能。配置管理功能对电子文件进行分类、建立索引，而检索功能则是按索引查询电子文件并在浏览器上展示内容。除了以上查询功能外，还有数据补录和系统公告功能模块。数据平台系统提供了数据补充录入功能，使业务人员可以进行数据的补充录入、修改和删除功能。而系统公告功能是在每个用户的网上个人首页提示公告信息或者在用户自己的权限内编辑、发布公告的功能，免去发送电子邮件和书面报告的麻

27、烦。这些功能模块的可以总结为这样几种功能：（1）对信息、报表的访问、使用来进行许可、控制和监督，以保护信息拥有者和最终用户的利益；（2）满足分行信息应用和管理的信息要求，为分行业务管理提供灵活便捷的信息查询功能；（3）将报表集中分类管理，并且系统化、标准化地发布出来；（4）补录必要的数据，使信息更加准确有效。以上是对商业银行的BI模式设计思想的分析，下面来分析一下BI的软件实现。系统采取了UNIX/Linux操作系统、J2EE架构以及Web应用层等技术，如图所示：图2.4 BI系统技术应用分布从图中可以看出，这一银行BI解决方案中，涉及到了众多的软件技术，下一章将就解决方案中所用的一些基于数据

28、仓库的核心技术进行分析。第三章、 银行中BI系统核心技术银行运营多年的数据是海量的，从数据方面一点点来整理去除冗余判断数据的有效性，肯定是不明智的决定。所以，以银行目前需要的各种报表为依据，对报表数据来源以及计算方式进行整理核对以后，确定数据仓库的建立方式以及各分析所需要的数据关系才是建立BI系统的选择。考虑到银行内部资料的安全问题，下面根据实际的情况假设有“网上银行客户服务系统使用率调查表”要求每月申报一张银行报表为例进行分析。报表格式如下：机构名称本期转账使用客户数转账使用率某某支行或某某分理处合计根据银行专业知识以及银行原有系统的结构资料，数据源为“各机构客户明细表”（设表名为m_bma

29、_guest）。系统架构设计中，这需要作数据清洗将储存在原始数据库中的各机构客户明细表转换成与“网上银行客户服务系统使用率调查表”所与数据准确对应的应用数据库中的中间表（1M_BMA_ACCOUNT_INOUT），字段对应、计算方法、关联和限制条件等等，都由EC程序或者数据库存储过程来实现。如果报表中还需要有另外手工补录的内容就需要提交补录设计文档给EC程序员，在数据补录模块中加入数据。作为中间表 又称为临时表 的“各机构转帐使用率情况表”（1M_BMA_ACCOUNT_INOUT），需要通过抽去“各机构客户明细表”（m_bma_guest）中的网银企业客户信息，这需要对每个机构的客户交易数进

30、行核对比较，即遵循SQL关于判断筛选的语法规则，调用到客户编号branch_no、本期转账客户数count(*)以及统计时间段month_i进行比较。由于这是网上交易，所以还需要特别在中间表1中设立类型限制txn_type=A（A设为网上交易类别代号），然后将交易数比较后的结果（差额）以及类型设置等相关信息数据组合成为中间表“各机构转帐使用率情况表”。中间表转换生成以后，需要的就是确立表内数据之间的关系。数据仓库中根据数据关系有星型模型、雪花模型和混合模型这样几种设计模型。常见的是星型模型，包括维表、事实表两种表，它的查询响应功能很有优势。其中两种表包含的就是维与事实，每一个维表通过主键连接到

31、事实表中与之相应的外键上，多表相连之后就建立起了完整的模型。在这里采用的就是用星型方式来建立的数据表和维度表之间的关系。时间维表 TIME_DIM_MONTH、营业机构维表M_BMA_V_ORG_UP、数据表M_BMA_ACCOUNT_INOUT以及客户维表M_BMA_GUEST关系图如下 M_BMA_V_ORG_UP:营业机构维表（分行）；M_BMA_V_ORG_UP1:营业机构维表（支行）；M_BMA_V_ORG_UP2:营业机构维表（分理处）；Brach_no:机构编号；brach_name:机构名称；org_up1_no：支行内编号；txn_type：交易类型；quarter_id：季

32、度号（例如3代表第三季度）等等：图3.1 星型关系图根据该图，并加上对于报表维度进行多维分析，最后就可以生成各种银行管理以及决策方面所需要的报表。而分析各个维度所能进行的多维分析操作，如上钻、下钻、切片、切块、旋转等，也需要根据每张报表的需求来进行，例如上面这张报表需要的多维分析，因为营业机构网点支行以及分行之间的附属的关系，统计月与其他统计时间之间的转换关系就需要做出相应的关于上钻下钻等设计如图：维度编号维度名称上钻下钻切片切块旋转P_d01营业机构（网点）P_d02营业机构（支行）P_d03营业机构（分行）P_d05统计月P_d06统计季P_d07统计年m01本期转帐使用客户数m02本期客

33、户数存量m03转帐使用率根据多维分析得到的模型，就可以得到一个动态报表：图3.2 报表模型报表储存以模型的形式存在，只有当执行运行操作以后才能够呈现所有的报表所需要的数据，如图所示：图3.3 动态报表如果需要将运行结果储存，只要使用pdf格式转换工具就可以保存下静态的报表结果。这样的设计更为灵活，客户如果需要改变报表结构，直接就可以看到报表原来的模型结构。虽然说银行的各种报表基本上结构是固定的，但是，由于建行正处在上市（转变为股份制公司）前期，很多报表结构以及数据计算方式都会有变化，所以需要保留原报表的模型结构。并且，在报表结构的基础之上，用户还可以运行图形功能，如图所示：图3.4报表图形分析

34、展现根据图形，决策人员可以清晰的看到所关心的银行各方面变化，同时可以发现仅从数字报表看不到得的变化细节，根据这些变化及时做出决策判断。实现以上报表的构建展现，首先要用到数据仓库技术。3.1. 数据仓库技术在BI几大技术支柱中，数据仓库可以说是基础磐石。所有的数据分析与挖掘都需要建立在良好的数据仓库基础之上。它的面向主题、集成、相对稳定、随时间不断变化四个特性，让它成为一种有效的管理技术，将分布在内部网络中不同站点的商业数据集成到一起，为决策者提供各种类型的有效数据分析，发挥决策支持作用。3.1.1. 分布式银行数据仓库银行的总部和分支的各位一方处于不同地域或城市的布局众所周知，建设银行也不例外

35、，自然形成了银行的分布式格局。在经营管理上，银行总部负责总体监管和经营决策，要有总的决策和信息中心，而分支结构也有相对独立的经营权，对自身的发展进行决策，也要建立自己的决策支持系统。对于一个银行如果只是建立集中的单一的数据仓库，即使建立的数据仓库是面向主题的，并为分析的需要保存了许多综合数据，也不能满足银行数据分析得需要。因为分析要求千变万化，我们不可能要求一个集中单一层次的数据仓库满足各种条件和要求。数据仓库的主题需要不断完善和调整，综合数据的内容和形式需要灵活多变。再加上随着数据是不断在入的，数据仓库自然会越来越庞大，分析工作若完全基于集中单一的层次，性能将成为很大的问题。所以，银行的数据

36、仓库多为分布式系统结构14。在建行的分布式数据仓库方案中，总行和分行、支行都有相对独立的数据仓库。总行成为在分布式数据仓库模型中的上级节点，分行相对于总行称为下级节点。以此类推，支行相对于分行成为下级节点，分行是其上级节点。图3.5分布式数据仓库如图所示，分布式的银行仓库中，总行和分行模式一样，都是通过分布式的网络结构，从下级节点抽取加载，运行ETL模块 ETL: 数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中

37、去。25以得到数据，而支行还有一些其它数据来源。而每一个节点的数据仓库系统都采用两个数据仓库的结构，由多维数据仓库和关系数据仓库来组成26，这就是经典的双库结构。关系数据库RDBMS是以二维关系表为核心表达多维概念和多维结构的，划分为维表和事实表两列表。而在项目中，关系型结构能够较好的适应多维数据的标识和存储，并且RDBMS灵活性较好，支持分布式操作，能够实现异地数据仓库之间数据传输，所以原始数据库采用了这一实现方式。而多维数据模型MDBMS中，多维矩阵比关系表更清晰，如果同样多的原始数据需要增长，MDBMS能够迅速成比例增长，虽然增加了一些冗余，但是提高联机分析处理的速度。对于小型的数据仓库

38、，如数据集市，MDBMS相对于RDBMS性能更为出色，更为简明。在查询方面多维数据库的响应速度比RDBMS要快，索引和数据聚合可以自动进行并管理，方便了银行人员的使用，减少系统的开发和维护工作。系统除了多维数据仓库、关系型数据库外，还有元数据库，后两者在项目中合为应用数据库。各节点的数据仓库可以通过ELT模块，加载本节点的联机处理业务，也可以获得下级节点的数据。而每个节点的数据仓库输出则是直接提供给决策分析调用。如图所示：图3.6 节点数据仓库输出输入图3.1.2. 原始数据库原始数据库的主要目的是实现原始数据类型的统一，所以基本上没有改变这些数据表的逻辑结构。它们主要是通过客户信息系统、存款

39、信息系统、贷款信息系统、货币信息系统等系统等银行原有业务系统中得到的诸如个人信贷业务、证券登记、委托型住房等数据表，如图所示：图3.7 原始数据库空间分布图正如前面章节分析的，在本项目中，原始数据没有建立元数据。考虑到成本问题，留到后一期工程中，涉及到原始数据的某些特殊管理以后再进行实现。3.1.3. 应用数据库数据仓库在银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策（证券、外汇买卖）、风险预测、效益分析等。但是银行的应用数据库基础架构却不是从应用范围的角度来设计的，也不是从会计角度来看信息的类型和组合，而是从银行的工作流程角度来考虑的。在银行的信息系统构建中，为了更好

40、的区分不同性质和应用的数据，保证逻辑上的清晰，将数据库划分为系统记录区、汇总数据区、分析数据区、操作数据区、反馈数据区和系统管理区六个区，一方面满足了数据的一致性和完整性，另一方面也为了满足现有业务系统（客户分析子、信贷监管、营业管理、经营分析系统等）和未来具体管理应用的特殊业务系统的要求。系统记录区用于存储整合以后的各业务系统基础的操作型数据，原则上这个区域只存储与管理相关的基础数据而不存储统计数据，并且不作数据加工。当然，即使只是与管理相关的数据也不能不作检查的全存储，仍然要对各系统冗余及标准不一致的数据进行整合。整合按照团体、内部组织、产品、渠道、合约、事件、地域、营销活动、资源这九大主

41、题将数据进行分类组织和存储，如图所示。图3.8 九大主题表关系图九大主题划分是按照银行经营管理过程涉及的对象来划分的，在对象之间都存在着关系，理清楚银行的数据关系即可准确的建立对象之间的关系，为银行的综合分析和管理打下数据信息的基础。系统记录区中不作存储的统计数据则是被按主题进行区分存储在汇总数据区。这部分因为会计管理而汇总加工的数据，主要是为了便于将庞大的统计工作分布到每个营业日或周期进行。这些常用的汇总数据统计好以后将为总帐，客户月银行卡统计表、半年期末数据统计表等统计分析应用打下基础。还有就是为了满足一些特殊的业务需求，例如银行的年初计划等，系统中需要存放客户、风险等系统中的业务操作数据

42、到操作数据区。这些数据来自业务应用系统，并且包含一部分根据具体的业务需求独立设计的补录数据，所以数据格式并不统一规范。剩下的分析数据区、反馈数据区与系统管理区中的数据都是需要其他区域存放的数据作为支持的。分析数据区用于建立OLAP的数据集市，其中从原始数据库转换过来的中间表以及中间表中含有的业务数据，作为数据模型的实施载体。而反馈数据区则是每次银行调用分析以后产生的结果的存放区，用以调整和控制操作型应用。至于系统管理区，是存放支撑平台及各应用系统的运行所需数据的区域，由各应用系统根据自身需要自行设计。这六大区域中的数据都是应用中最基础的数据，而数据库始终是要面向应用的，所以，需要建立客户经理管

43、理、信贷风险、经营分析集市、系统数据这四大数据集市。加上了这四大集市以后，一个完整的应用数据库就组成了：图3.9 应用数据库空间分布图数据仓库中的数据既相互独立，又互为补充，共同组成了北京建行的信息库，为银行的客户经理管理、信贷风险、营业管理、经营分析等分析系统实施打下了坚实的基础。3.1.4. ETL技术在众多的银行管理信息系统方案中，信息应用和管理是否能全面、正确地反映银行的实际状况取决于能否采集到完整全面的业务数据。它是整个信息系统的信息起点。所以，ETL是系统建设的不可轻视的环节。只有保证有高质量、完整的数据模型和数据基础，数据分析和挖掘的结果才具有其实现的价值。ETL根据不同专题的数

44、据分析模型从银行现有的多种结构相异的业务及管理系统中抽取、过滤转换需要的数据，并将它们按照不同的数据集市要求装载到原始数据库中，为各种面向主题的分析提供高质量的数据，完成银行多种有价值的异构数据的整合和集成。所以ETL工作实施的好坏，直接影响到下一步的分析、挖掘系统结果。ETL需要首先在原始数据库和业务系统之间搭建起一座桥梁，确保新的业务数据源源不断地进入原始数据库。其次，ETL的作用在于屏蔽了复杂的业务逻辑，为各种基于数据仓库的分析和应用提供了统一的数据结构与接口。第三，为用户的分析和应用反映出最新的业务动态的支持。因为这部分需要的是动态的技术支持与维护，所以也往往是ETL中需要精力最多的部

45、分。图3.10 经典ETL流程ETL工具的选择，根据对信息平台支持的需求、对数据源的支持、数据转换功能、管理和调度功能、集成和开放性、对元数据管理等功能来判断。在实习项目中，采用的Adt-moia是实习所在公司独立开发的产品，开放性自然是不用置疑的。依据北京建行BI系统的需求它更被灵活的分配了三部分数据整合的任务：图3.11 面向对象ETL图一）面向原始数据库的ETL功能在面向原始数据库的数据采集过程中，需要将从业务系统获取的数据在BI系统的原始数据库中对号入座，即放到以各业务系统命名的目录之下。不同性质的数据需要不同的装数策略：对于账户、客户、总帐、参数表等原始数据类数据需要采用同步装入方式

46、，如果原来已经有同命名的数据，在数据再加过程中就需要修改，如果原来没有，那么增加这些数据；对于业务明细类数据则需要采用追加方式装入；对于有复杂计算处理的数据装入，则需要采用客户化装入方式，即调度事先已经根据客户需求分析并编译好了的客户化程序进行装入处理。比较特别的是如果要得到历史数据系统目录下的数据，需要从DCC返传电子文件中抽取数据才能够装入到库表中。装入文件格式都是标准的ASCII码，而总行返传文件格式却都是EBCD编码格式，因此需要调用后台转码程序对文件进行转码操作，将文件转换成系统能够正确识别的格式。在初步的数据处理过程中，还需要注意解决海量数据的存储管理和查询优化的数据管理的问题。如

47、果把这一问题留到后面步骤中来解决，没有经过优化处理的数据会拖慢后面复杂数据处理过程的速度。所以在这个过程中，需要从数据底层存储管理和应用优化两方面入手。一方面ETL提供大数据量表切分存储管理功能，通过数据库的各类优化机制（如分片技术分片技术：即将数据按照某种逻辑划分分布在分布式数据库中23 、索引优化），来解决大数据量表带来的查询效率问题。另一方面，外挂磁盘阵列、光盘库、磁带库等二级存储介质，将在数据库中存放长久但不经常用到的数据清理出来进行管理，满足海量数据的存储、管理需要，解决信息系统由于数据量过于庞大而导致的数据访问和后台计算效率低下问题。二）面向基础数据集的ETL功能承上节所述，应用数据库分为基础数据集和数据集市两部分。从原始数据库到基础数据集之间的数据处理功能由面向基础数据集的ETL来完成。1）数据采集在这一步骤中的数据采集对象主要是原始数据和补录数据。需要补录的数据有补录台帐、土地费用库、土地出让合同、立项文件库等，他们有的非固定时间能确定，有的变换频率较高。根据这些数据以及数据库查询的特征，为ETL设定采用的抽取方式（是全量还是增量），定制源数据和目标数据之间的映