数据仓库技术及其在金融行业的应用

1. 前言

数据库仓库（DW）技术从1991年开始出现，经过多年的摸索和应用，目前在一些发达国家已经建设得比较成熟，为企业综合与灵活的分析型应用提供了强大的数据支撑，为管理层的分析决策和操作层的智能营销提供了技术保证，为企业带来了多方面的收益。而在国内，数据库仓库仍处于尝试或初级建设阶段。

国内的金融行业，随着外部监管和信息披露的压力、内部管理和决策分析的需要，在建设分析类应用时，也正在逐渐从孤立的数据层向统一的数据仓库层规划和转移。建立数据仓库能够减少对数据层的重复投资和资源浪费、统一数据标准、监管和提高数据质量、消除信息孤立、支持综合分析和灵活及时的分析型应用、适应管理和发展、提高业内竞争力。

本文对数据库技术做一个概括性的介绍，并对国内外金融行业数据仓库技术的应用现状做一个简单分析。

2. 数据仓库概念

2.1. DW的提出

2.1.1. 需求

业务系统的建设与逐渐完善，巨量数据信息的积累。

分析类需求不断增加，传统分析类应用造成巨大的资源浪费和管理困难。

业务数据平台异构、数据来源口径多、标准不统一、信息孤立。

整合部门级应用，建设企业级应用，满足综合分析、复杂查询、智能营销等高级需求。

2.1.2. DW概念的提出

MIT在20世纪70年代对业务系统和分析系统的处理过程进行研究，结论是只能采用完全不同的架构和设计方法。

1988年，IBM为解决全企业数据集成问题，提出了信息仓库的概念，确立了原理、架构和规范。但没有进行实际的设计。

1991年，Bill Inmon提出了数据仓库概念，并对为什么建设数据仓库和如何建设数据仓库进行了论述。Bill Inmon被称为数据仓库之父。

2.2. DW的四个特征

2.1.1. 面向主题

 应用或支持分析的应用是面向应用组织数据，数据分散，不利于综合分析。

为OLAP应用提供数据支撑的DW是综合分析业务需求对不同源系统数据进行提取、提炼，按主题重新设计数据模型和重组数据，覆盖所有的应用。

主题是在较高层次上将企业信息系统中的数据综合、归类，并进行分析利用的抽象。例如对于一个银行来说，DW所面向的主题域可能包括当事人、协议、产品等。

2.1.2. 集成共享

由于源系统的数据平台异构、数据标准不统一、数据模型差别大，在建设数据仓库时要进行数据集成，为所有应用共享统一标准的数据。

数据集成的工作主要包括三个内容。

数据清洗：按照数据质量管理的要求进行数据清洗，保证进入数据仓库的数据都是符合规范且可以使用的。

数据转换：将不同标准的数据进行转换与统一，并保证可以回溯。

数据整合：不同源系统的数据在数据仓库中可能会进入到相同的模型中，要对源系统与数据仓库模型的差异进行分析整合。

2.1.3. 随时间变化

DW自己不产生源数据，但需要根据源数据进行数据加工和汇总。DW中加工后的基础数据和汇总数据是随时间不断变化的。

2.1.4. 不可更新

这是指在DW中不会更新从源系统中传过来的细节数据。

在进行数据转换时，一般也并不删除原值。

2.2. DW与DM、ODS的关系

2.2.1. DW与DM

DM是数据集市（Data Mart），相当于部门级或应用级的数据仓库，一个企业内部一般建有多个DM，不为种类的分析型应用使用。各DM分别设计和建立，数据标准和数据模型没有统一。DM建设难度小，容易成功，但随着数据集市越来越多，无法解决数据冗余、数据质量、数据标准不统一、统计数据不一致等问题，无法满足综合分析和智能查询的业务需要。

DW是指企业级数据仓库，一般一个企业内部只建立一个，数据层大集成，可以为所有分析型应用所使用。由于技术条件的，DW在前几年的建设初期，难度很大，遭到过大面积的失败。

目前所指的数据仓库实际上包含了数据集市和前期数据仓库的概念，可以说是数据集市和数据仓库的融合。数据仓库内部即可建立企业级整合统一的数据层，同时也可建立为部门级决策支持所设计的数据集市。

2.2.2. DW与ODS

ODS是操作型数据存储（Operational Data Store）。与DW相同的是，它也是面向主题的；是集成的（可能是部分集成）。与DW不同的是，ODS要具有同时支持分析型应用和操作型应用的特性，因此它存储的数据是当前的，需要实时刷新，却不一定要求存储非常大量的历史；基础数据是随业务而更新的。

ODS也经历了多种应用形式，它曾做在数据仓库的前端，做一些初级的数据整合，数据快进快出，例如这可以支持要求每小时做一次分析的应用。它也曾作为初级形式的数据仓库，例如支持面向电子商务的ODS。

ODS产生的技术背景是由于早期的DW因为技术条件的，不存储细节数据、难以实现频繁的更新和删除，不能支持实时性要求较高的分析应用。但ODS具有数据同步复杂（一般需要两次数据落地）、数据共享困难、数据冗余、管理复杂等问题。目前由于条件的成熟，ODS和DW也有走向融合的趋势，在数据仓库内部分为动态数据区和表态数据区，分别相当原来的ODS和DW概念。

2.2.3. 走向融合后的DW

集成原来的DW、DM和ODS，融合后的企业级数据仓库，在内部划分出多个数据层次。在近期业务数据区，能够为一线业务人员提供战术性决策和操作智能；在长期历史数据区，能够为管理人员提供战略性决策分析和复杂查询。即可支持部门特色的应用，也可支持跨部门的企业级综合应用。

整合后的企业级数据仓库（EDW）简化了数据管理和维护流程，减少了数据冗余和延迟，减小了投资成本和协调工作，满足多种级别智能型应用的需要，为企业创造长期的价值。

3. 数据仓库架构

3.1. 数据仓库架构的构成

广义的企业级数据仓库（EDW）包括基础平台和分析型应用。

基础平台又可分为技术架构和数据架构。技术架构包括ETL体系、数据访问体系、数据存储体系、安全管理体系等；数据架构包括数据标准、数据质量、数据模型、数据管控、数据接口等。

3.2. 数据仓库技术架构

如上图所示，数据仓库技术架构由八个组件组成：源数据层、ETL服务层、数据服务层、中间服务层、访问控制层、用户层、元数据管理层、安全管理层。

源数据层：

作为ETL层的数据抽取源，为EDW提供原始数据支持。本层设计要考虑源系统状况和数据抽取方式，确定存储方式、数据量、交付时间、对时间窗口的影响，以及数据文件规范、文件压缩方式、传输模式、文件发送位置等规范信息。

ETL服务层：

完成数据文件转换和加载，并负责管理和调整数据仓库中所有作业的依赖关系，管理整体作业流。

数据服务层：

一般包括四个层次。数据缓冲区支持ETL处理；基础数据层基于面向主题的物理数据模型，用于保存数据仓库基础数据；汇总层是建立在基础数据之上的主题级汇总数据；应用数据层（数据集市）是建立在基础数据区和汇总数据区之上的一组数据库，分别对应一类应用主题。

中间服务层：

OLAP服务器通过ODBC等接口从数据仓库批量获取数据，按设计模型生成立方体，支持BI软件包的展现请求。

BI软件包通过ODBC等接口访问数据仓库，支持业务用户的灵活查询和固定报表请求；还可通过OLAP接口访问数据库支持业务用户的分析请求。

应用服务器：提供一个具有高可用性和负载均衡功能的基础平台，以支持BI软件包和其它应用软件包的运行。

访问控制层：

主要包括WEB、认证、安全、门户四方面的服务。该层为用户层提供HTTP服务、门户的单点登录、用户统一认证、提交用户层请求到中间服务层，对用户实施安全策略，为用户管理报表、查询文档，提供个性化定制等。

用户层：

数据仓库系统用户既包括进行系统建设的开发人员、系统运行人员和系统管理人员，又包括最终使用系统的业务用户，这里主要对业务用户进行描述。

业务分析人员主要是指使用应用界面访问数据仓库系统的总各业务部门、各分行的业务用户。该类人员使用数据仓库主要生成或预览定义报表，进行相对固定的查询和分析 。

管理决策人员主要包括各部门的领导、总行和分行领导。数据仓库系统为管理决策人员分配专门的系统资源，建立最为直观方便的存取界面，为决策人员赋予最大的信息访问权，实现对信息的自由访问。

知识工作者是指各部门、各分行较为高级的用户。可以对指定的主题、指标进行自定义的灵活分析和比较。分析的方式包括自定义查询和报表、旋转和穿透钻取等。

元数据管理：

元数据管理是将分散在数据仓库各环节的、的元数据统一存储在元数据存储库中，并将各个元数据有机的联系在一起，实现对数据流的跟踪管理，向前可以进行数据的血缘分析，向后可进行影响性分析。

安全管理：

安全管理主要包括网络安全、操作系统安全、数据安全和应用安全，这里不做专门介绍。可参考相关技术资料。

3.3. 数据仓库数据架构

数据仓库的数据架构分数数据流向、数据模型、数据标准、数据质量、数据管控和数据保留策略与容量规划六个部分来简单介绍。

数据流向：

一种比较典型的数据仓库数据流设计模式是，先通过ETL服务将源系统数据加载到临时数据区，本区主要用于源系统数据和ETL运行数据暂存；然后通过数据加工将详细历史数据、客户信息、账户信息、交易信息等数据存储到基础数据区；然后可定期进行账户信息和客户信息等汇总，将数据存储到汇总数据区；最后可将应用分析所需的数据存放到应用数据区。

数据模型：

由于数据仓库建设经验的积累，各行业有其比较成熟的数据仓库数据模型，例如在金融行业，Teradata和IBM各有其自己的数据模型。成熟的数据模型产品对建设数据仓库有一个很好的经验和方指导，但客户化依然具有很大的工作量。

数据标准：

数据标准化是一项关键工作。进行数据标准化工作必须有专职数据管理员，制定配套的管理流程；数据标准化包括数据映射和制执行准规则，如识别规则、归并规则、重要口径等；数据标准化工作还包括统一的业务定义，进行总体规划。

数据质量：

数据质量也是一项关键工作，数据质量太差的数据仓库，其应用价值可以几乎为零。数据质量问题来源广泛、复杂，可以设计或借助现成的数据质量检查系统进行数据质量检查。保证质量的工作内容主要包括：定义及初始度量、分析及发现错误、查找问题根源、解决质量问题、监控改进过程、发现及分析改进中的异常。

数据管控：

建立统一的数据管理体系框架，主要有三个层面组成：管理策略、方法和内部体系，其核心是工作内容包括数据规划、数据标准制订和管理、数据质量管理。数据管理体系的建立和完善是一个长期持续的过程。

数据保留策略和容量规划：

数据保存周期受三个关键需求驱动：业务分析的需求；法规需求、审计与投资者情况披露；基于历史数据为客户提供额外的服务。

在确定了数据仓库建设策略之后，可以进行数据容量规划，这包括计算用户数据量、计算磁盘空间需求、分析目前容量现状及对策等工作。

3.4. 数据仓库应用架构

国际先进银行的企业级数据仓库实践表明，实现需求主要有三种应用模式：灵活分析、数据挖掘（如评分系统）和应用开发。应用系统的开发离不开需求的成熟和稳定，只有通过大量的灵活分析和数据挖掘的应用，才能形成成熟稳定的应用需求，反之，使用系统在业务中的大量使用，又会促进分析人员更加深入、有效的分析探索数据。

灵活分析具有IT和业务两方面的知识和技能，利用查询工具进行任意的数据探索和查询，以回答各种未预定义的业务问题；

数据挖掘在灵活分析的基础上对某些业务问题进行数据属性层面的提炼和归纳，如典型的评分模型、违约模型等；

应用系统是指联机或批量访问数据仓库的应用系统，典型的应用有营销管理系统、利润贡献度模块、反洗钱应用、关键指标/平衡计分卡应用。

在进行分析应用的建设规划时，要根据业务需求的急迫程度确定业务实现的优先次序，并制定一个分析型应用的评估模型。

4. ETL设计与工具介绍 

4.1. ETL概念

ETL具有如下的含义：E（Extraction，抽取）、T（Transformation，转换）、L（Loading，加载）、C（Cleansing，清洗）。ETL是DW系统的基础。DW中的数据来自源业务系统，ETL的主要功能正是完成对源业务系统的数据抽取、清洗、转换和加工，生成DW中基础层和应用层数据。

ETL过程由处理单元和处理流程两部分组成。数据转换清洗规则主要体现在处理单元中；处理流程体现的是处理单元之间的正确顺序。ETL系统要有运行监控体系，监控是否有异常；ETL必须实现流程自动化。

4.2. ETL的模式

 有E-T-L和E-L-T两种模式。

E-T-L模式一般需要有一个强大的ETL服务器，而E-L-T模式则需要强大的数据库引擎，对ETL服务器的配置要求不高；

E-T-L模式将转换过程从数据库服务器脱离开来，减少ETL过程占用数据库服务器的时间窗口。可以将查询和加载分离开来，互不影响。

E-T-L模式的工具通常利用元数据实现整个加载转换流程。

E-T-L模式更适合用于从外部数据源直接一步加入目标数据库，同时无需用到目标数据库现有数据的情况。E-T-L模式不太适用于在加工过程中需用到目标数据库中现有数据的情况，特别是当这个现有数据比较大的情况，例如数据仓库模型中常用的历史拉链算法。E-T-L模式不太适用于目标数据库内部的再加工，如数据仓库基础层向中间及应用层的加工。

4.3. ETL任务与任务拆分原则

ETL任务：

制订数据接口规范

制订数据采集和传输规范

ETL策略设计

ETL体系结构设计

设计和开发数据采集/传输程序/脚本

设计和开发数据加载程序/脚本

进行数据质量检查

ETL设计和开发总结汇报

构建和测试初始加载的程序和处理流程

构建和测试日常加载的程序和处理流程

撰写ETL系统用户操作和使用手册

ETL任务拆分原则：

ETL任务拆分得太精或太细都不好。拆分需要考虑如下因素：性能；前续任务等候时间；事务的完整性和及最小化；任务的易管理性；脚本的可读性。

ETL任务拆分的最佳实践：以目标表为单位进行拆分；以源数据到达时间的不一致性进行拆分；以算法不同进行拆分。

4.4. 业界主流ETL工具简介

DATASTAGE：Ascential公司，现已被IBM收购

POWERCENTER：Informatica公司

SUNOPSIS：SUNOPSIS公司，现已被ORACLE收购

SAGENT：GROUP 1公司

DATA INTEGRATOR：BO公司

DECISIONSTREAM：COGNOS公司

TOS（TalendOpenStudio）：开源软件

其中，Informatica和Ascential公司是领导者。

5. 数据仓库前端设计

5.1. 企业级数据仓库的应用模式

EDW应用模式可分为：固定报表、应用系统、灵活查询、数据挖掘。

OLAP/固定报表提供日常业务管理统计，辅助发现业务发展趋势。固定报表是数据仓库信息共享的主要途径之一，是最重要的展现方式。部分常用的、能够提炼出共性的灵活查询可能会转化为固定报表。固定报表信息所涉及的维度和度量是确定的、权威的；信息具有普遍性，简单和容易理解，对用户要求不高；固定报表不依赖单一业务系统，需要全局视图。

分析型应用系统绝不仅仅是固定报表随意的堆砌，而是特定的业务逻辑整合，可以帮助用户逐步访问与分析一系列交互式的报表。分析型应用一定是服务某个业务主题的，例如风险管理、营销管理等。 

灵活查询提供解决那些无法预定义的查询分析需求以及查询问题时的详细钻取。灵活查询随时发生，可由任何部门发起；有应对突发需求的相应能力；可能是简单统计或某项明细数据查询，也可能是某种复杂逻辑的处理；灵活查询具有特定的目标、特有的度量、专用的视角和算法。

数据挖掘是从大量详细数据中提示出隐含的、先前未知的并有潜在价值的信息的过程，主要基于人工智能、机器学习、模式识别、统计学等技术，做出归纳性的推理，从中挖掘出潜在的模式，帮助决策者调整市场策略，减少风险，做出正确的决策。数据挖掘一般需要跨业务领域进行综合关联分析，信息全面；针对的是某个特定领域的特定问题，应用范围和服务领域具有专用性；数据挖掘使用的统计技术和模型的产生结果都具有高度的抽象性；数据挖掘模型需要进行周期性的回顾和调整。

各应用模式分解参考特征：

用户角色：

DW的数据可分为三层：缓冲层、基础层、语义层（即汇总和应用数据层）。不同用户访问不同的数据层。

80%的用户只需访问语义层，这一般是普通业务人员；20%的用户可能访问基础层，但其80%的时间仍然只访问语义层，这一般是高级业务人员和数据挖掘人员；只有很少的技术用户和审计可能偶尔需要访问缓冲层。

不同用户访问的数据权限不同，例如不同分行的用户需要访问不同的分行逻辑视图。

对不同角色用户需要制定不同的数据开放策略。

统一用户管理：

用户权限和用户角色设置比较复杂，不同工具和软件一般都有自己的用户管理机制。必须在整个系统范围内实现统一用户管理，由系统管理员对系统内各组件的用户进行统一规划和管理。

5.3. 应用系统体系架构

应用系统可以直接基于DW，也可以采用由DW导出数据给外部集市的方式，具体哪种应用采用哪种方式，需要根据实际情况具体分析。

直接基于DW的应用尽可能采用统一Portal入口，多采用B/S架构，绝大部分用户采种统一管理，单点登录。

基于DW也可以为少数高级用户开放C/S访问接口，这些用户具有较高的灵活性，通常直接通过数据库用户进行适当的权限管理即可。

基于导出集市的应用通常不集成于统一Portal，可根据自身情况合理选择架构方式，可采用B/S架构也可采用C/S架构。

5.4. 主流前端工具及应用

常用OLAP工具：

Hyperion Essbase

Microsoft Analysis Service

Oracle Express Server(9i) / Analytic Workspace Manager(10g)

Sybase IQ

IBM DB2 Server

Cognos Powerplay

常用前端工具：

Hyperion Client(Brio) 有业内最好的EIS

BO

Cognos

MSTR

Crystal Report

Excel

6. DW数据模型设计 

6.1. 关系模型和模型

关系模型是使用规范的二维表表示数据以及数据间的关系，设计关系模型要使用规范化理论。

模型使用数据立方体（Cube）来表示现实世界中的复杂关系，基本组成是维（Dimension）、度量（Measure）。

维是对数据进行分类的一种结构，用于从特定角度观察数据，例如时间、地区、产品等。使用维主要用来选择针对期望详细程序的层次的数据、分组对细节数据综合（聚集）到相应的详细程序的数据层次。

度量（指标）是 数据的实际意义，一般是一个数据值度量指标，例如销售量、销售额等。数字型指标和聚集函数是度量的两个组件。

Cube是一个模型构成的数据空间，其逻辑上相当于一个数组。

6.2. 分析的基本动作

模型的分析动作是将Cube中的数据进行可视化展现的方法。

切片：从立方体中切出一个二维。如选定时间维1998年1月，取出产品和地区两个维的数据关系。

切块：从立方体中切出一个小三维。如选定时间、产品和地区，取出分析数据。

旋转：改变一个报告或页面显示的内容。如把一个横向为时间纵向为产品的报表旋转为横向为产品纵向为时间的报表。

钻取：向上钻取获得更高层更宏观的数据，向下钻取获得到更低层更详细的数据。

6.3. 数据模型的实现技术

ROLAP（Relational OLAP）：

利用关系数据库来存储和管理基本数据和聚合数据，并利用一些中间件支持缺失数据的处理。具有良好的可扩展性。

关系二维表使用两类表（事实表和维表）来表示结构。事实表（Fact）用来存储变量值和维的码值。维表用来存储维的描述信息，包括层次和类等。

MOLAP（Multidimensional OLAP）：

利用数据库来存放和管理基本数据和聚合数据，其中需要用到稀疏矩阵处理技术。对预综合的数据进行快速索引。

HOLAP（Hybrid OLAP）：

利用关系数据库来存储和管理基本数据，利用数据库来存储和管理聚合数据。

6.4. 维度建模步骤

选取业务处理过程：

业务处理过程由一个或多个源系统存储其活动数据。建立的第一个模型应该是一个最有影响的模型，它应该对最为紧迫的业务问题做出回答，并且数据是可获取的。

定义事实表的粒度：

事实表的粒度是指事实表每一行的具体含义。应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子数据是所集的最为详细的信息，该数据不能再做进一步的细分。

维度模型的细节性数据是安如泰山的，并随时准备接受业务用户各种分析的需求。

选取维度：

用一组维度表来描述事实，每个维表包含了若干离散值。这些维度包含所有可能的描述信息。常见的维表有日期、产品、客户、交易类型等。

维表不能太大，太大可能需要拆分。

确定数字事实：

 事实确定要衡量和分析的内容。如数量或消费金融等。

6.5. Teradata公司的金融行业数据模型产品

Teradata公司有一套预先构建的金融行业DW逻辑数据模型FS-LDM，是一套较成熟的产品，利用它可以直接开始数据仓库模型客户化设计。FS-LDM包括十大主题。

PARTY（当事人）主题：

当人事是指银行作为一个金融机构所服务的任意对象和感兴趣进行分析的各种个人或团体客户、潜在客户、代理机构、雇员、分行、部门等。一个当事人可以同时是这当中许多种角色。

Internal Organization（内部机构）主题：

内部组织机构是指企业的内部组织和业务单元，如分行、客服中心、支行、储蓄所、部门、销售团队等。在技术上它是一种特殊的PARTY。不仅包括自身的内部组织机构，还包括其他的内部组织。

PRODUCT（产品）主题：

产品是金融机构销售或提供的可市场化的产品、产品包和服务。如果有必要，在模型中可以包括竞争对象所提供的产品。

AGREEMENT（协议）主题：

协议是当事人之间针对某种特定产品或服务而签立的契约关系。例如银行的账户，保险公司的保单等。包括协议的申请、报价、还价以及开立等完整信息。

ASSET（资产）主题：

当事人的资产主题是所有可能采集到的各种当事人的资产（负债）信息，包括有形的和无形的各种客户资产/负债，同时还可以存储银行向外租赁的各种资产信息。可能是客户的不动产、商品存货、珠宝、机动车辆、以及在其他金融机构的存款、贷款等。

7. 数据仓库项目实施方

7.1. 重视数据管控

数据仓库建设是一项长期的持续改进的任务，仓库中的各层数据会不断的丰富、完整。在这个过程中，制定和实施一套数据管控策略、保证数据质量是至关重要的。

数据管控的工作内容包括制定管控任务和指导原则，建立组织结构，进行业务改善建议和结果追踪，规划好数据管理的落地功能，获得用户的支持和参与，调整方案计划确保满足用户期望的质量、可用性、实用性和性能。数据管控的重点是组织管理和流程。

好的实施经验有：持续推进元数据精细化管理；建立数据质量评估模型；做好数据生命周期管理；制定物理模型优化策略和ETL加载优化策略；推进主数据和参考数据标准体系建设

7.2. 制定数据质量改进方案

保证数据质量五个“一”工程：必须有一个跨部门以上领导的重视和牵头；必须有一个专门负责解决数据质量问题的组织；必须有一个专门负责解决数据质量问题的平台；必须有一个专门负责解决数据质量问题的流程；必须有一个专门负责侦测数据质量问题的工具。

数据质量保证工作的好建议：以源系统数据质量为重心，兼顾数据仓库的数据质量，特别是业务统计指标的计算规则的统一；从单个系统的数据质量向多个系统之间的数据整合质量问题转移，以数据标准为出发点，提出数据整合的业务规则以及异常处理；从数据质量问题的发现到数据质量问题的治理进行转移，协调业务和科技，进行上游数据质量治理和下游数据质量修复的工作流程的建立。

7.3. 数据仓库项目的特征七要素

数据仓库项目不是技术主导型项目，是一个大的集成项目，更注重方法和流程。

数据仓库项目需要持续的建设。

数据仓库项目需要持续的成熟度评估和改进和建议，逐渐找出合理的策略。

除了一般的项目管理方法外，更重要的是实施方法。

不同阶段的实施方法需要技术和业务紧密结合的组织架构的支撑。

需要坚持不懈地推动业务的参与。

基于基础平台结合应用建设的大项目群管理必须建立有效的管理机制。

8. DW在金融行业的应用与发展

8.1 BOA典型的成功DW建设情况

BOA的元数据管理：

15年前已建立元数据管理系统，IT和业务部门均设有元数据专家。

源系统的变化通过变革流程通知到DW。

详细到数据要素（Data Elements）

真正发挥DW窗口的作用，能够为业务人员及应用开发人员提供如下信息：DW中有什么数据，这些数据从哪里来，到何处去，加工逻辑是什么。

没有针对元数据管理的权限控制，BOA认为元数据信息对每个人都有价值，合法的局域网用户均可访问

DW对应用的支持模式是PULL，而不是国内普遍使用的PUSH，大大减轻了DW支持人员的工作量，很大程度上得益于元数据的广泛应用。

数据标准制定与维护：

BOA通过主参考数据（Master Reference Data）和客户参考数据（Customer Reference Data）达到支持DW的数据整合，保证进入DW的数据的一致性。

数据质量：

关于数据质量的基本原则：业务部门是数据的拥有者，因此他们应当对数据质量负责，DW只接收数据，不修改数据。

DW非常重视数据质量，有一个集中的DQ团队负责对数据质量的监控，同时每个业务部门和IT部门都设有数据管理员，他们也对数据质量进行检查。

重点监控300多个关键的数据元素。

首要解决的是数据缺失的问题。

每个业务部门在年初的计划中会设定数据质量目标，年终会考核相关人员的数据质量目标完成情况。

用户支持：

 有一个32人的DW资源中心团队，定期发布更新数据；进行数据使用培训；监控前端应用， 如找出并解决过度消耗资源的查询；指导各层应用对DW的数据使用。

访问情况：

2900多个活跃用户，包括ETL、应用、业务信息工具、SAS和许多通过其他DBMS实现的连接。

2008年每月查询次数在1~1.4亿之间。

数据访问工具：

 包括SAS、Cognos、BO、Qqueryman、Hyperion、MSTR、DW分析平台等。

8.2 国内金融行业的DW建设情况

截止2008年1季度，国内12家银行的数据仓库分析型应用超过30个，主要分布如下：

成立了数据仓库决策委员会；

项目组织结构随项目进度而调整，前期组织结构面向开发，后期面向测试；

做好了ETL开发中两个关键环节：由模型到SDM（源数据映射）映射文档；由SDM映射文档到ETL脚本；

重视元数据管理和优化、数据质量检查、系统监控和管理；

针对超大数据量制定了可行的备份恢复策略；

对现有数据集市制定了发行和建设计划；

使用挖掘技术引导ERM建设；

建立全行统一的统计指标库。

9. 结束语

 建设企业级数据仓库是一项庞大的综合工程和长期持续的过程，成功的建设数据仓库一定需要丰富的实践经验和科学的实施方作指导。在DW建设过程中，要综合考虑系统和技术架构、组织结构和管理流程、数据监管和持续的数据质量改进、数据访问和用户支持方法、信息安全和可用性、应用系统建设模式和升级规划等多方面的因素。目前，成功建设DW的关键因素不是技术，而是科学的组织、流程和实施方。

参考资料：

《DW分析与设计方法培训》及课堂笔记