主题：[转帖]数据仓库技术在银行的应用和发展

 [转帖]数据仓库技术在银行的应用和发展

作者：宋玉长 （河南）

银行是国家经济的命脉，随着我国正式加入WTO组织，中国的银行业很快就会直面来自国际金融巨头的挑战，能否在竞争中取胜是国内银行业普遍感到困惑的问题。目前，国内银行业呈现出几大趋势: 一是数据走向集中化; 二是业务综合化; 三是管理扁平化; 四是决策科学化。这些特点促使数据仓库技术发挥着极其重要的作用，同时，也是银行业能否决胜未来的关键“利器”。

数据仓库的概念和体系结构

20世纪90年代初期，美国著名的信息工程学家W．H．Inmon在《建立数据仓库》一书中提出了“数据仓库”的定义：数据仓库（Data Warehouse）是面向主题的、集成的、稳定的、包含历史数据的数据集合。数据仓库是一个环境，而不是一件产品，它提供用户用于决策支持的当前和历史数据，这些数据在传统的操作性数据库中很难或不能得到。数据仓库是一种有效的管理技术，将分布在网络中不同站点的商业数据集成到一起，为决策者提供各种类型的、有效的数据分析起到决策支持作用。

90年代中期，数据仓库技术的出现和兴起，较好地满足了银行的要求。据美国国际数据公司调查，使用该技术的投资回报率平均超过400%，该技术成为继Internet之后又一技术热点。目前，在美国30％－40％的公司已经或正在建造数据仓库，以数据仓库技术为基础，以联机分析处理（Online Analytical Processing简称OLAP）和数据挖掘（Data Mining简称DM）工具为手段的决策系统日趋成熟。

一个典型的数据仓库系统是一种系统体系结构，一般有三层：最下的一层是数据仓库，最上一层是决策支持工具，如OLAP、DM等，中间的一层是中间件。其结构如附图所示：

由数据仓库结构图可见，在数据仓库系统中，有三个关键环节，即数据的抽取、转换、整理和装载（ETL），在目标数据库中存储转换后的数据和为用户提供对目标数据库的访问。

数据抽取、转换、整理、装载工具是从数据源中抽取数据，对其进行检验和整理，并根据数据仓库的设计要求，对数据进行重新组织和加工，装载到数据仓库的目标数据库中，并且周期性地刷新数据仓库以反映数据源的变化，并将数据仓库中的数据转储。

数据仓库是一个多维数据库，其目标数据库是整个数据仓库环境的数据核心，可以是关系型数据库（RDBMS）或多维数据库（MDBMS），其内部存放了数据建模的数据和元数据（MetaData），突出的特点是对海量数据的支持和快速的检索技术。

数据库管理中间件具有安全和特权管理、跟踪数据更新、数据质量检查、检查和报告数据仓库使用状态、备份和恢复等功能，能够对数据仓库的运行提供有效的监控和管理手段。

数据访问和分析工具供业务分析和决策人员访问目标数据库中的数据，并作进一步的深入分析之用。数据访问和分析工具不仅提供一般的数据查询、汇总、统计等访问功能，还提供对数据的深入分析功能，如数据挖掘，包括数据的比较、趋势分析、模式识别等，能够有效地从大量数据中发现潜在的数据模式并作出预测分析。数据挖掘面对的是经过初步加工的数据，对象是数据集合，数据仓库为数据挖掘提供了良好的物质基础。

数据仓库技术的实现方式

数据仓库技术作为一项数据管理领域的新技术，既没有可以直接购买到的现成产品，也没有具体的分析规范和实现方法，也就是说没有成熟、可靠且被广泛接受的数据仓库标准。下面我们介绍数据仓库系统中各个组件的技术实现。

1、ETL工具：通常有两种方式可以实现数据抽取、转换、整理、装载，即手工编程和现成工具。早期数据仓库的建立多采用手工编程的方式，如COBOL或4GL语言，现在ETL工具已经成为主流，主要有Informix的Infomover和Prism、Carleton、ETI等。

2、目标数据库：数据仓库的目标数据库的选择是数据仓库工程的关键之一。目前在实际应用中主要包括如下几种具体实现方式。一是在关系数据库上建立数据仓库(ROLAP)，二是在多维数据库上建立数据仓库(MOLAP)，三是在原有关系库上建立逻辑上的数据仓库。MOLAP方案是以多维方式来组织数据，以多维方式来存储数据；ROLAP方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。

由于目前正在运行的联机事务处理系统(OLTP)中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。尽管由于原有OLTP系统设计上的局限性，这样的系统可能无法实现很多分析功能，但这样一个系统中数据结构固定、信息分析需求相对稳定成熟，因此数据仓库的建模、实现过程会相对容易、便捷；同时，这样的系统也会成为将来真正数据仓库建设的原型。目前性能较好的产品有Informix/Redbrick、Oracle和Sybase等。

3、数据仓库管理中间件：数据仓库管理中间件是数据仓库的管理工具，HP公司的OpenView产品就能够提供这些功能，另外，Informix的Metacube Warehouse Manager为用户提供了GUI，可以有效对元数据进行管理。

4、OLAP工具：OLAP是利用数据仓库技术的真正价值所在，是多维数据分析工具的集合。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求。目前市场上的OLAP产品有Informix的Metacube ROLAP、Cognos的Powerplay、Oracle Express和Hyperion等。

5、DM工具：数据挖掘的分析过程是自动的，其用户不必提出确切的问题，只需去挖掘隐藏的模型并预测未来的趋势。DM产品有Informix的Redbrick Data Mine等。

信息系统与数据仓库的关系

由于数据量大、数据来源多样化，在构建管理信息系统时，不可避免地会遇上如何管理这些浩如烟海的数据，以及如何从中提取有用的信息的问题；而数据仓库的最大优点在于它能把企业网络中不同的商业数据信息集中到一起，存储在一个单一的集成的数据库中，并提供各种手段对数据进行统计、分析。因此可以说，在银行使用数据仓库构建管理信息系统，既有压力，又有数据基础，它们之间的联系是必然的，难以割舍的。

数据仓库在银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策(证券、外汇买卖)、风险预测、效益分析等。在建立银行数据仓库之前，首先需要了解现代银行数据本身包括的那些数据是银行重要的数据，以及他们的组成结构。银行的数据模型是一个理性化的分析工具，他不是从交易处理的角度来看银行可以提供什么产品，也不是从会计角度来看信息的类型和组合。它是从银行的工作流程角度出发，是从银行客户的获取过程、渠道优化和优质客户保留的周期出发来分析银行的功能和合理化，它的价值在于银行可以更好地研发金融产品和做好客户服务。

在银行信息系统构建时，由于历史情况和现实需求的不同，存在两种途径:

1、建设新系统

由于目前国内商业银行对银行内部运营的监管，缺乏很好的数据搜集机制，因此可以在构建管理信息系统时，分数据收集录入和数据汇总分析两部分来考虑。这样的系统中由于不需考虑大量历史数据的处理问题，同时考虑到搜集过程中可能存在多个数据来源，因此可以在系统建设的同时构建数据仓库，将搜集来的各种数据通过数据抽取整合到数据仓库中。

2、完善原有系统

而对于已经存在OLTP系统，其中沉淀了大量历史数据，则可以先在原有系统上建立逻辑数据仓库，即使用数据分析的表现工具，在关系模型上构建一个虚拟的多维模型。当系统需求稳定后，再建立物理数据仓库，这样既节省投资，又缩短开发工期。

目前我市人民银行已经运行的主要业务系统有中央银行会计核算系统、会计报表管理系统、财务管理系统、电子联行系统、帐户管理系统、信贷登记咨询系统、金融统计监测管理信息系统、货币发行监测系统等，原来这些系统相对独立，各系统的历史数据再利用率很低，但各系统中已积累的历史数据为数据仓库的建立提供了初步的数据基础。利用上述数据仓库技术实现各项业务的集成后，可以将正在运行的多个数据源进行统一组织，形成一体化的存储结构，为决策分析奠定基础。通过信息加工、分析、处理软件，管理决策人员可以对金融运行的每一个环节做出科学的判断，有效的控制和防范金融风险。该项技术的推广运用，为建设中央银行的现代化支付体系和金融监控体系奠定了基础，为履行中央银行的职能提供强有力的保证。

数据仓库实现中需要注意的问题

一、模型设计中的问题

模型设计(包括逻辑模型设计和物理模型设计)是系统的基础和成败的关键，在实际操作中，视实现技术的不同应分别对下列问题引起注意。1、直接构建数据仓库

直接构建数据仓库时，必须按业务分析的要求重组OLTP系统中的数据，并要按不同侧重点分别组织，使之便于使用。

*主题的确定

主题是一个逻辑概念，它应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系。划分主题的根据主要来源于两方面:对原有固定报表的分析和对业务人员的访谈。原有固定报表能较好地反映出以往工作对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但仅仅满足于替代目前的手工报表还远远不应是构建管理信息系统的目标，还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分。

*分析内容的细化

主题的划分实际上是与分析内容的范围直接相关的，一旦主题划分清楚了，下一步就是细化分析的具体内容以及根据分析内容的性质确定它在数据仓库中的位置。通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，但从实际操作中可以总结出如下的概念性经验:作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量的是连续型数据，取值无限。如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。

需要特别强调的是，在细化分析内容的过程中，务必解决指标的歧义问题。在不同报表中以及在业务访谈中同一名称的指标，是否是在同样条件限定下，通过同样方法提取或计算得到的，它们之间的相互关系是什么，这些问题都必须从熟悉业务的分析人员那里得到准确、清晰的答案，否则将会影响到模型设计、数据提取、数据展现等多个方面。

*粒度的设计

数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。事实表中以各种维度的什么层次作为最细粒度，将决定存储的数据能否满足信息分析的功能需求，而粒度的层次划分、以及聚合表中粒度的选择将直接影响查询的响应时间。

如果同一个信息系统要在大范围、多层次上同时运行，如部门级和企业级，还应考虑不同层次的数据仓库采用不同的粒度。

*模型设计中的技巧

复合指标尤其是比率类指标的定义，必须注意累加时是先加减后乘除，还是反之。户数、笔数的计算，这类指标在分析或报表中经常出现，但不需要作为单独的指标物理存在于数据库中，但定义分析模型时一定应该准备。度量的时间特性，针对分析指标在时间维上的不同表现，可分为可累加指标、半可累加指标和不可累加指标。

2、在原有数据基础上构建逻辑数据仓库

如果直接使用OLTP系统中的数据进行数据分析处理，会遇到许多麻烦，有时甚至是不可能实现的。这并不是说关系数据库不好，而是因为其设计思路不适应较大规模数据分析。因此在使用这种方法时，需要注意下列问题的处理:

*不同的时间单位

这是实现过程中最常遇到的问题，也往往是最难解决的问题。OLTP系统中存储的时间往往采用与实际业务发生相同的时间单位，如帐务数据单位为日期，财务报表单位为月或半年。而面向分析时，往往要将不同时间单位的数据统一到同一个结果中，这样就必须存在适当的转换机制才能实现。

*冗余信息

所谓冗余信息，就是指不同关系表中存在的同一含义的字段，而同一含义不仅指这些字段的取得或计算方式一样，还指它们成立的条件一样，例如截止某一时间同一地区的同一贷种的贷款余额。在OLTP系统中，这样的字段往往是基于性能考虑而设计的，而在面向分析设计模型时，为了保证结果的唯一性和准确性，就必须用且只用其中之一的数据产生分析结果。

*表间连接

由于OLTP系统中表的设计面向业务处理，既要保证数据的完整性、一致性，又要考虑响应时间，因此表与表之间既相对独立，又相互依赖。在设计数据仓库逻辑模型时，对表间的连接必须做出相应取舍，既要保证分析数据能通过连接取得或计算出，又要避免出现环路，造成分析数据的歧义。另外，不同的连接途径还会出现不同的查询速度，影响数据分析的响应性能。

*统计表的设计

如果上述问题不能在原有数据库基础上得到很好的解决，那么权益之计就是构建统计表，即简单化的数据仓库，形式类似数据仓库的事实表，定时计算统计数据放入，将时间、冗余、连接等问题摈除，进行简单分析。

二、数据抽取中的问题

数据抽取是一件技术含量不高，但非常烦琐的工作，必须有专人负责数据抽取的工作。在对其进行设计时，要注意的问题有:

1、数据抽取的规则要作为元数据进行规范和管理，抽取过程中的源表、源字段、目的表、目的字段、转换规则以及转换条件都要作好详细记录。这样不仅便于编程人员实现，而且在抽取规则或逻辑模型发生变化时也便于修改。

2、如何记录业务数据库中的变动情况是数据抽取中一个重要的环节。由于数据仓库中按时间保存数据，因此不同时间点之间数据的差异就成为一个关键性因素。通常可以利用数据库管理系统提供的手段在数据库级产生数据变动日志，根据日志再判断数据的变动情况完成抽取，这样是一个从性能、可操作性以及对原业务系统的影响等多方面综合考虑都比较理想的方法。

3、当数据仓库中同一表中的数据来自于原有系统中不同的表，甚至不同的库时，抽取时务必保证这些数据单位一致，而且都满足同一时间条件。

4、数据抽取不仅要考虑数据的提取，还要考虑抽取的时间安排和执行方式，这样才是一个完整的数据抽取方案，也才能保证抽取出来的数据准确、可用。

三、后期维护、优化中的问题

数据仓库的建设是一个长期工作，它同其他系统一样需要在运行的过程中不断进行调整、完善。这其中包括两方面的工作:

1、性能

数据仓库涉及海量数据的查询，数据的大量写入读出，不仅对数据库系统的要求很高，而且与OLTP系统的要求也极为不同，因此在系统设计、实施和维护的过程中，数据仓库系统的性能都是一个不可忽视的问题。尤其是在运行期间，要密切关注应用对系统资源的消耗情况，针对应用的特点及时对系统进行调整，包括调整数据库参数、数据分片放置、创建特殊索引乃至提高系统配置等。

2、模型

应用与需求是相互促进、不断发展的，随着信息系统建成运行，用户在对系统了解不断加深的过程中，也会对系统提出更新更高的要求。如何在最小投入的前提下满足用户的需求，也是一个值得注意和潜心研究的问题。首先要尽可能挖掘现有系统的潜力，其次考虑，对主题的增加或可在现有系统上增加少量指标就可解决的需求，对系统进行适当调整，最后才考虑对系统进行重构，尽可能减小系统建设中的投入。

数据仓库应用的深化

按照上述方法实现的应用中，主要完成了报表的生成和日常业务的分析，这并不能给银行带来真正的效益，也远远没有发挥出数据仓库的应用价值。在数据仓库建设中，不要把其视为一劳永逸的项目。数据仓库的建设不一定马上就能得到很大的效果，不能急功近利。如果在初始阶段就试图包罗万象，势必会造成整个系统的进度和质量难以控制。应该从急需的业务主题入手，逐步扩大信息的范围，这样才能准确把握需求，减少投资和减少风险，缩短阶段性的开发周期。随着应用的深入，可以由银行的技术人员与业务人员紧密配合，规划出对银行有实际价值的应用模型，并根据实际业务的发展不断调整模型自身的参数，以期找出业务运作过程中的规律，即在数据仓库上进行数据挖掘，构建决策支持系统（DSS），充分体现构建数据仓库的意义，从而最终为银行带来效益。

银行数据仓库的设计，提出了一种利用数据仓库技术及其工具实现银行电子化的设想，运用这项技术可以统一银行管理信息的采集，提高网络资源的利用率，改进银行的运转效率，能够提供多角度、多层次的查询、分析、预测功能，增强管理者的决策能力和水平。数据仓库技术的快速实施，将使我国银行的信息技术赶上世界最新潮流，更好的迎接加入WTO后的挑战。