全面认识数据仓库.docx

全面认识数据仓库1. 前言随着我行信息科技工作进入后蓝图时代，后线分析系统注1建设的需求会越来越高，将在快速响应、高效实施、灵活应变、信息统一、全局分析、深度挖掘、监管有力、报送及时、降低成本等方面提出更多新的挑战。面对蓝图成功投产后新的产品体系，如何统一规划全辖数据资源、整合后线产品架构、预备各项技术预研可能是今后信息科技工作的一个重心。数据仓库（DW）是各行业后线系统进展的一个重要方向，它在克服部门级应用的局限（数据分隔注2、重复存储、重复中间加工过程注3、维护工作繁琐、资源重复投入等）、满足全辖基础数据共享、提供全局分析视角和应用组件、支持快捷灵活和低成本的开发部署等方面有着不可替代的功能和地位。数据仓库本身有着不同视角的概念解释，大可涵盖整个企业级应用架构，小可专注于单纯的数据建模与存储；数据仓库涉及重多相关技术，如ETL、数据模型设计、多维分析、数据挖掘等；数据仓库建设可能是一个复杂高难的全局性项目，正确的实施路径、策略、方法与有效的质量治理是项目成败的关键；另外，数据仓库系统实施后的治理与维护，也是保证各类后线应用系统长期顺利运行的重要因素。针对这些数据仓库相关的概念、技术、策略、方法等，可能并不是每个人都有比较全面的了解。因此有必要对这些做一个系统的介绍，使大伙儿对数据仓库有一个全面清晰的认识。2. 数据仓库入门介绍Ø 应用需求背景随着联机事务处理（OLTP）业务系统的深入应用，企业各类业务数据不断积存和丰富，越来越需要从大量数据中提取有价值的信息，以辅助决策和指导经营。治理信息系统（MIS）和早期的决策支持系统注4（DSS）要紧是基于传统的数据库技术和事务处理环境，这种系统结构随着业务系统建设规模的扩大、数据量的巨增和数据复杂度的提高，已无法满足综合分析型应用的需求，造成数据丰富而信息贫乏的困境。首先，人们逐渐认识到，分析处理和事务处理具有极不相同的性质，事务处理通常是对数据库进行联机的查询和修改操作，每笔交易的响应时刻和数据的安全完整是关键；而分析型处理往往是对大规模历史数据的批量加工计算，数据的规范统一和整体时刻窗口是重要关注点。因此直接采纳传统数据库技术和使用事务处理环境来支持分析型系统是不合适和失败的。两类系统的特点比较见表-1：事务处理型应用分析处理型应用专门多用户少量用户小事务、频率高、时刻短大事务、频率低、时刻长一次数据操作量小，是小单元的随机数据操作一次数据操作量大，是大集合的批量数据操作更新与插入操作都专门频繁更新操作较少，插入操作较多需要当前的细节的业务数据需要历史的整合的综合数据响应时刻是关键总的处理时刻是关键面向应用、事务驱动，数据范围小面向分析、分析驱动，数据范围大表-1另一方面，企业的各类应用系统是在不同时期通常由各部门或分支机构面向特定应用建设的，存在着数据平台异构、数据结构和数据标准不统一等问题。传统的数据库技术和事务处理环境关于实现基于个不业务系统的部门级MIS和初级DSS系统尚可支持，而对实现全局范围的离散数据整合和综合信息利用，建设跨部门的企业级分析应用已无能为力。Ø 数据仓库的提出麻省理工学院在20世纪70年代对业务系统和分析系统的处理过程进行研究，结论是只能采纳完全不同的架构和设计方法。1988年，IBM为解决全企业数据集成问题，提出了信息仓库的概念，确立了原理、架构和规范，但没有进行实际的设计。1991年，Bill Inmon提出了数据仓库概念，并对什么缘故建设数据仓库和如何建设数据仓库进行了论述。Bill Inmon被称为数据仓库之父。 Inmon对数据仓库的定义是“数据仓库是面向主题的、集成的、稳定的、随时刻变化的数据集合，它用以支持经营治理中的决策制定过程”。那个定义要紧描述了数据仓库的四个最差不多特征。在数据仓库的整体概念中，这是对最核心部分的狭义定义。我们还应该明白，除了那个最核心的仓库体之外，广义的数据仓库概念，还包括来自各源业务系统的数据通过采集、下传和加载等步骤进行入仓库体的过程，包括仓库体的数据针对各类分析需求进行多维加工、挖掘、利用的过程，并包括全程数据流程设计和数据质量治理等过程。从狭义上讲，数据仓库是一个具有四个差不多特征的数据仓储体，从广义上讲，数据仓库是一种架设企业后线分析类应用的解决方案。伴随着数据仓库，同时期还出现了联机分析处理（OLAP）和数据挖掘（DM）等新技术，从此，DW+OLAP+DM就逐渐形成新决策支持系统的概念。再后来的商务智能（BI）应用需求更是基于DW+OLAP+DM的支持。Ø 两种数据仓库设计思路提出数据仓库的不至Inmon一个人。Bill Inmon和Ralph Kimball差不多上数据仓库的首创者，但对数据仓库设计的观点专门不相同。首先需要了解一个数据集市（DM）的概念。相关于数据仓库是一个企业级的高度综合数据集，数据集市确实是部门级的轻度综合数据集。Inmon主张建立数据仓库时采纳DWDM方式，即先建一个统一数据层（狭义DW，中央数据仓库），将不同的OLTP数据集中到面向主题、集成、稳定、随时刻变化的统一数据层中，其中数据能够下钻到最细层，或者上卷到汇总层。再利用中间统一数据层，针对各部门的专门分析需要设计独立数据集市（数据仓库的子集）。见图2-1: 图2-1而Kimball主张DMDW方式，即直接将源数据抽取转换到面向各部门分析需要的数据集市中，然后将一系列维数相同的数据集市联合起来递增地构建数据仓库，通过一致的维（公共定义的元素）能够共同看到不同数据集市中的信息。也即数据集市的联合数据仓库。见图2-2: 图2-2两种设计思路产生两种不同的数据仓库建设模式，一种是先构建企业中央数据仓库，一次性的完成数据的重构工作，最小化数据冗余度和不一致性，再从中央数据仓库中建筑数据集市，数据集市从数据仓库中得到大部分的集成数据，且直接依靠于数据仓库的可用性。这种建设模式的问题在于：投资回报时刻如何保证？建设中央数据模型的必要性和可能性？初始费用如何预算？。另一种建设模式是先建数据集市，即由各个部门在各自的主题区域内进行数据重构，快速得到投资收益，然后通过联合数据集市递增地构建数据仓库，把建筑数据仓库作为一个长期的目标。这种由数据集市汇成数据仓库的建设模式面临的要紧问题是：各个数据集市的数据不一致性难以解决，且存在一定的数据冗余。 这种方法更能满足近期目标的需求，但增加了以后转换为独立的数据仓库的数据体系结构的困难。从总的比较结果来看，Inmon的建设模式起步难度大，但假如走好了第一步，长远利好；Kimbal的建设模式更能满足近期目标的需求，但当以后试图跨数据集市猎取联合视图时，可能面临严峻问题。数据仓库建设模式的选择要紧取决于商业驱动。假如企业正忍受糟糕的数据治理和不一致的数据，那么Inmon的方法就更好一些，能够带来全面革命和解放；假如企业迫切需要给用户提供信息，那么Kimbal的方法更能满足需求，能够通过逐步改革解决问题。大型项目一般会采纳Inmon的数据仓库建设策略，全球最资深的数据仓库服务商TERADATA确实是这种模式的忠实支持者。Ø 数据仓库的四个特征Inmon的数据仓库思想被奉为经典，他在数据仓库定义中描述的四个差不多特征是数据仓库之路上的入门概念，是数据仓库区不于事务处理环境和传统独立分析应用的最本质内容。面向主题OLTP应用或独立分析应用差不多上为满足个不应用需求而建设的，它们的数据是各取所需的、局部的，其数据定义标准和组织方式也各具特色。数据仓库的设计思想与此不同，它不是面向某个具体需求，而是对反映全辖业务经营情况的所有源数据进行分门不类、统一组织，从而为现有和潜在的各类分析需求提供一致范围和一致标准的基础数据支持。主题确实是对企业内结构各异的源数据依照可用性、及时性、前瞻性、方便性等需要在较高层次上进行综合、归类的抽象。例如对银行来讲，DW包括的主题域能够分为当事人、协议、产品等。通过按主题重构的数据模型，应当能够支持所有的分析应用。集成共享由于源数据的分散独立、平台异构、标准不统一、模型差不大、冗余度高等状况，在将其提炼、抽取到数据仓库时要进行必要的转换与整合。如此集成后的数据，具有一致的结构和标准，才能为所有分析应用共享。随时刻变化除了可能有小部分的业务数据补录，数据仓库自身不产生源数据，而只需要对进入仓库的源数据进行加工和汇总。加载处理后的统一基础数据和汇总数据总是随时刻不断增量变化的。不可更新源自业务系统的数据差不多上差不多发生的数据，除了个不分析应用可能需要对错误发生的业务数据进行日后的在应用层的纠错处理外，数据仓库差不多可不能更新和删除从源系统中传过来的细节数据。3. 数据仓库架构Ø 两类差不多数据仓库架构有两类差不多数据仓库架构，一类是Inmon提出的CIF架构（Corporate Information Factory，即企业信息工厂），一类是Kimball提出的MD架构（Mutildimensional Architecture，即多维体系结构）。CIF架构要紧包括集成转换层（I&T）、操作数据存储（ODS）、数据仓库（EDW）、数据集市（DM）、探究仓库（EW）等部件。MD架构要紧包括数据预备区（Staging Area）和数据集市。MD的数据预备区在功能上相当于 CIF 的staging area+EDW，要紧负责数据预备工作，是一致性维表注5的产生、保存和分发的场所。数据集市要紧是采纳一致性维表来完成维度建模，多个数据集市一起合并成“虚拟”数据仓库，这些数据集市能够是存在于一个数据库中，也能够是分布在不同机器的不同数据库中。两类数据仓库架构各有优缺点，CIF架构建设周期较长且初始设计复杂，但当建立起企业级数据模型并完成数据清洗整合工作，数据的完整性和一致性问题就能够得到全然解决，后续针对需求变化易于扩展，且成本较低。MD架构是先着眼于某些部门级应用创建快速见效的数据集市，而后以逐步创建和合并数据集市的方式实现企业级数据仓库，如此启动成本较低且初始设计较简单，然而全局数据的一致性和稳定性需要通过对一致性维表的持续维护来保证，后续扩展的工作量和代价较大。在实际的数据仓库项目解决方案中，往往是依照项目规模、实施目标、成本预算等在这两类差不多架构上进行取舍调整和变形。多数是采纳CIF架构；也有采纳CIF架构和MD架构相结合的方法，例如，IBM提出的CDW（Corporate Data Warehouse）确实是把CIF架构的EDW与MD架构的DM进行结合的解决方案。Ø 解析CIF数据仓库架构典型的CIF数据仓库架构见图3-1，大的层次上要紧包括源数据层、ETL层、数据服务层、数据展现层等部分。图3-1ü 源数据层源数据层是数据仓库的源头，包括采集反映企业经营状况的各类业务系统源数据、补录数据以及导入来自外部的数据。源数据能够采纳数据库直连方式由ETL抽取到数据服务层，但首选是先采集到接口数据文件，再传给ETL层。ü ETL层ETL的差不多设计任务是完成数据抽取、转换与加载。在各个项目设计中可依照具体环境进行调整，例如在我行已建立通用数据下传平台系统，因此能够不再需要数据抽取功能。ETL作为将整个数据仓库系统的数据处理过程串联起来的生命通道，还负责对整个过程中的批量任务进行调度、治理和监控。另外我们将元数据治理和数据质量管控也归为ETL层的任务。ü 数据服务层数据服务层也可称数据仓库层，其中包含多个层次。源数据缓存区：加载数据先进入源数据缓存区（也称staing area），在这一层（数据落地或不落地）通过进一步的清洗和转换之后进入全局统一基础数据区。加载过程中的临时表就属于这一层。ODS区：是可选层，其数据结构跟源数据结构一致，相当于业务数据的快照，保存相关于数据仓库比较实时的数据，要紧是针对需要实时数据的操作型应用需求，也可服务于实时性需求不强但需要按照源数据结构访问数据的应用需求，如审计。ODS层的数据存储周期一般不长，例如一周，一般不超过一月。如需长时刻保留，能够采纳单库同步处理或保留数据文件的方式实现。依照顾用需要，有时可能需要建立多个ODS区或ODS库。全局统一基础数据区：即CIF架构的EDW，存储面向主题的、集成共享的、历史的、不易变的全局视角企业数据。采纳关系模型注6设计，不面向具体应用，而是要考虑整体使用的方便性和效率。所有分析类系统使用的数据（除了可能有使用ODS数据的应用系统）都应通过本层提供，幸免出现数据孤岛。本层中能够存在面向一定逻辑视图的通用汇总数据，以方便数据集市加工或提供更好性能的数据直接访问，但理论上本层设计不用考虑最终用户的需求。应当减少最终用户对本层数据的过多直接访问，通常应该通过数据集市间接向最终用户提供数据，当数据仓库建设成熟之后，最终用户对本层直接访问的情况应该专门少，尽管有时也是必要且有益的。汇总数据缓存和DM区：由于EDW中存储的是关系模型的、统一标准的、最全面的基础数据，假如每个分析应用都直接访问EDW，应用的性能和EDW承受的压力都成问题，因此需要针对特定应用提早加工各类汇总数据。汇总数据在数据缓冲层（落地或不落地）完成加工后，存储到各个数据集市中。DM层的数据直接被具体应用访问，通常是按维度建模，依照顾用需要也可建成关系模型。将DM与EDW放在同一数据库中是可能的，但假如将它们物理上分开，放在不同的机器上处理好处更多，包括：将数据集市分不放在小一点的机器上，处理过程的费用会下降；数据集市与数据仓库的工作相分离，整个处理过程将更容易治理，对容量的打算也更容易预测和治理；不同的部门拥有相应的数据集市，能够令各方中意。ü 数据展现层本层要紧是通过各种工具或应用开发实现对DM中数据的目标应用。数据展现工具要紧包括报表、灵活查询、OLAP分析、数据挖掘等各类；应用开发更加灵活自主，还能够直接使用EDW中的通用基础数据和通用汇总数据。4. 数据仓库设计假如把数据仓库系统看作一个产品，那么这是一个涵盖了几乎所有后线分析子系统的巨型平台产品，同时还要轻松支持不断扩充的应用需求。如此的一个平台产品要能做到充满活力的按需运行，必须首先做好每一部分的规划设计工作，那个地点我们分ETL设计、数据模型设计和应用架构设计进行介绍。Ø ETL设计ETL操纵着整个数据仓库的生命线，其设计直接关系着仓库内的元数据质量、仓库结构的稳健和流畅运行。要紧包括差不多ETL、作业调度、元数据治理及其它方面的设计。ETL服务器能够独立一台机器，也能够与数据库服务器同机。ü 差不多ETL 差不多ETL功能要紧可分为两个，其一是把握着数据仓库的入口，今后自不同架构、不同形式、不同标准、不同结构的各类业务数据，通过清洗、转换、加载、加工等步骤送入EDW；其二是将EDW中的数据加工转换到DM中去。这部分的分析设计工作至少要包括以下方面的内容。1，确定数据抽取范围，包括数据源系统范围的确定和每个源系统内采集数据范围的确定。这项工作一定需要对行业需求有相当了解、对企业内的软件架构和业务系统特不熟悉的人牵头，并由各类业务系统的骨干人员组成工作组，从全局角度选定数据范围。这不仅需要全面考虑当前分析类应用的数据需求，还要有一定的前瞻性，将反映企业重要经营信息今后可能使用的数据也划入采集范围。2， 制定数据接口文件格式、数据验证规范、错误数据处理方法和高性能加载方法，保证进入仓库数据的及时、正确、有效。3，制定数据统一标准和转换合并规则。这项工作是进行数据标准化加工处理的前提，是仓库数据得以集成共享的保证。需要结合数据模型设计。4，梳理数据的加载、加工处理步骤和相互间的阻碍与依靠关系。保证数据依照依靠关系和时效需要、按照正确的次序各就各位。需要结合元数据设计。5，数据量和各时期处理时刻估算、时刻窗口评估等。采纳并行等方法满足时刻窗口需求。ü 作业调度整个数据仓库的批量作业流程依靠ETL的正确调度。首先要梳理清晰每个作业的触发机制、每个步骤的容错处理机制，以及各作业间的阻碍与依靠关系，才能正确配置ETL的调度表。要注意作业粒度的划分（不宜过小或过大）、并行度的合适设置、中断重跑措施等。并考虑采纳动态调整作业优先级等方法以满足下游系统的时刻窗口。ü 元数据治理元数据是数据仓库中用来定义和描述业务和应用数据、数据映射和演进关系、处理流程及任务依靠等几乎所有内容的描述数据，从而将数据仓库的各个角落和各个环节有机的串联在一起，以不仅支持数据仓库各种功能实现，而且应该支持跟踪数据仓库的状况和变化，从而给数据仓库的生命运动提供一个整体概貌视图。相关于数据仓库裸层的数据与功能，元数据就相当于治理层的数据，起着保驾护航的支撑作用。关于一个大型数据仓库项目，假如没有元数据设计，就相当于建设一个大都市而没有规划图纸、没有考虑基础设施建设，是不可能成功的。元数据自成一系，能够单独存储到元数据库，也能够与数据仓库共存在一个库中。元数据设计应力求全面、细致，能够参考业界的一些数据仓库元数据标准，如CWM（Common Warehouse Model）等，注意所有元数据要统一标准、统一设计和治理，保证各层、各类元数据的衔接，幸免出现数据断层。元数据设计适宜早做，关于一个复杂的数据仓库环境，事后维护比事先规划成本要大得多。元数据的质量在专门大程度上决定着数据仓库的健壮程度和可用程度。元数据设计应重点考虑描述清晰各层数据间的数据接口和转换关系，以直观的视图追踪哪些分析指标来自哪些业务数据、通过哪些处理步骤，支持数据血缘分析和阻碍分析，发挥对数据质量管控和系统运行监控的重要支持功能。随着业务系统和某些业务参数的变化，元数据也是不断进展变化的，要注意元数据的一致性和持续性维护。ü 其它治理功能ETL的护航作用除了依靠设计周密的元数据提供支持，还要设计开发相应的系统功能，如任务调度依靠关系查询、批任务完成情况查询、警告与错误查询、仓库数据使用状况、性能与资源状况查询、日志治理等。这些治理功能的设计应满足数据仓库日常运行的监管需要，能够逐步完善。对仓库数据的监控应包括进入仓库的SQL命令和这些命令的结果集，使系统治理员能够知晓数据仓库中哪些数据正在被使用、哪些数据经常被使用等，可能需要在表级、行级和列级进行监控，以清晰掌握数据的情况，为存储规划和治理等提供依据。Ø 数据模型设计数据仓库中的数据区大概有四层：源数据缓冲区+ODS数据区、EDW、汇总数据缓冲区和DM。依照不同数据层的使用目的和特性要求，应分不采纳不同的数据模型。要紧有关系和多维两种模型，它们要紧的区不在于灵活性和性能方面。关系模型灵活，支持各类群组用户任何形式的访问和数据重构需求，但在满足终端用户的访问性能方面不够理想；多维模型能够满足终端用户的直接访问，性能专门高，但灵活性不行。因此关系模型适合构造企业级基础数据模型，而多维模型适合构建范围有限的部门级应用数据模型。源数据缓冲区和ODS数据区差不多采纳与源系统相同的数据模型，可直接提供基于源系统结构的简单原貌访问，一般保留短暂历史。EDW采纳面向主题的关系模型设计，以存储整合后的企业全局详细数据，支持各种类型最低粒度的数据需求。EDW中的数据是稳定的、持续增长和长期保存的，保存期一般为2年或3年，超过保存期限的数据在本区备带。本层要紧为数据集市提供基础数据输入服务，也可提供小量级的随机业务查询服务。汇总数据缓冲区差不多是对EDW数据区的各层逻辑视图，要紧用于加工DM数据区的中间过渡作用，也可物化为通用逻辑汇总数据，提供对某些业务用户的直接访问支持。除物化汇总数据保留周期视需求而定（不超过EDW周期），其它数据保留周期短暂。DM数据层是面向某类应用的汇总成品或半成品数据，具有业务意义，用于支持特定而明确的需求，满足特定用户的快速访问，一般采纳多维模型设计，保留周期视需求而定（一般不超过EDW周期）。下面讲述EDW层的关系数据模型设计和DM层的多维数据模型设计。ü 关系模型设计EDW关系数据模型设计有几个目的：消除冗余、统一标准、中性共享、方便使用、完整一致的描述和组织企业数据。设计要点是面向全局业务、全面反映企业经营状况、包含最细节数据、灵活可扩展，并同时规划数据容量、存储周期、备份机制、访问方案和效率等；不需要太多考虑具体应用的数据模式需求。设计EDW关系数据模型的第一步是确定主题区域，立即种类繁多的业务数据依照业务领域划分成几个高度概括的类不，例如对银行业能够分为客户、产品、协议、交易、财务等主题。第二步是确定每个主题区域内的实体对象，及区域内对象和跨区域对象的关联关系，例如客户主题内能够包括客户差不多信息、家庭信息、名称历史信息、地址历史信息等实体；产品主题内可包括产品特性信息、利率信息、产品与客户的关系等实体类型。关于某些应用的个性化数据需求，尽管共享程度低，也须放入EDW，能够依照数据的共享程序和繁忙程序，在进行物理设计时划分出热数据区和冷数据区。由于每个行业的企业数据有较大的相似性，而一个结构稳定、扩展性强的EDW模型设计需要深厚的行业和技术经验，因此数据仓库厂商针对要紧行业都有自己比较成熟的数据模型产品。企业在进行EDW关系模型设计时，能够借鉴这些成熟产品的设计思想并依靠自己的经验与能力独立完成，也能够依托成熟的行业产品进行客户化。ü 多维模型设计DM层的要紧目的是用于特定分析应用的快速访问，通常采纳多维模型设计，因此依照分析型应用的特点与需要也能够采纳关系模型设计。多维模型恰是依照用户的请求而构造的，其设计的最大优点在于访问的高效性，因此必须收集和理解用户的最终需求，才能定义出优化的多维模型结构。确定结构后的多维模型固定服务于特定用户特定形式的访问，不能再轻易改变而用于其它需求。多维模型也称OLAP模型，是为了满足用户从多角度多层次进行数据查询和分析的需要而建立起来的基于度量（实际数据值）和维（描述数据的不同角度）的数据模型。在设计时应首先选择业务所需的度量指标，然后选择度量的维度和反映维度等级结构的层（粒度）。维度建模有三种实现方法：ROLAP、MOLAP和HOLAP。ROLAP是利用关系数据库来存储多维数据和完成多维操作；MOLP是基于多维数据库完成数据存储和分析操作（例如ORACLE的分析工作区Analytic Workspace，简称AW）；HOLAP是基于关系和多维的混合模型，即利用关系数据库来存储和处理细节数据，利用多维数据库来存储和处理聚合数据。多数采纳ROLAP进行设计。ROLAP模型有星型和雪花两种结构，星型是差不多结构。星型结构是采纳中间一个事实表和外围多个维度表来表达和存储多维数据，事实表用来存储度量值和维关键字，每个维使用一个表来存储维的层次结构，事实表和维表通过主外键关联成“星型结构”。关于层次复杂的维，能够将其进一步层次化而分成多个维表，星型结构就扩展为“雪花结构”。雪花结构有减少数据冗余等优点，但由于增加连接而导致性能下降等缘故，通常不推举。Ø 应用架构设计有了EDW的基础数据和DM的应用数据，如何样充分利用这些数据，挖掘其中的商业价值是应用架构设计的范围。应用架构设计既是建设数据仓库系统的动身点，也是目标。数据仓库的价值回报最终体现在所支持的各类应用。ü 一般应用模式应用模式一般有灵活查询、数据挖掘和应用开发等。灵活查询解决那些无法预定义的查询分析和详细钻取，可能是简单统计或某些明细数据项查询，也可能是较复杂的计算与处理。常用的、能够提炼出共性的灵活查询能够转化为固定报表。由于灵活查询的时效要求相对较高，对这类应用应该为各部门规定数据范围、操作范围和查询频率，以免阻碍数据仓库的性能；同时在ETL元数据设计时应考虑对这类应用状况的动态监控。数据挖掘是针对特定领域的特定问题，从大量详细数据中提取可能具有潜在价值的信息，基于机器学习、模式识不、统计学等技术，做出归纳性的推理，从中挖掘出潜在的模式，供决策者参考。数据挖掘一般需要跨业务领域进行综合关联分析，信息全面，信息量大，而时效性要求不是太强。通常采纳专业的工具。应用开发是挖掘数据仓库价值的最有效方式，能够灵活满足企业的各类后线应用需要。不仅能够为领导层提供分析决策支持，为中层治理者、市场分析人员和操作员提供智能商务服务，还可服务于各类监管、报送需求。ü 灵活设计数据集市EDW中的数据通常只在需要时才通过预加工后送入到DM中，DM并非只有一种模式，而是依照不同应用目的设计不同的模式，例如有的需要设计成多维模型，而有的设计成关系模型更合适；有的要求越快见到数据越好，有的只需在月底的时候见到数据。关于每一个数据集市的不同需求，应灵活区不对待，包括为其预测和打算不同的处理机器和存储容量。5. 数据仓库实施与维护策略数据仓库建设是一个复杂的系统工程，分析设计的每一个体步骤都专门关键，而在更高角度上有一个正确的实施策略和方法论更是保证数据仓库项目成功的先决条件。另一方面，建成后的数据仓库像一个结构庞大而逻辑严密的机器，具体的日常状态监控和错误应对措施十分重要，而在更高层次上有一套完善的维护策略对保障数据仓库系统顺利运行也必不可少。除了一般的项目治理方法外，实施数据仓库项目还应该重视以下策略：目标明确和需求：持续建设和改进是数据仓库项目区不于一般软件项目的一个特征，作为平台型综合性项目，数据仓库的价值实现不是一步到位的。要宏观规划和时期性预期目标相结合，通过论证评估，明确自己的需求。专门多数据仓库项目是由于需求不明确而导致失败的。高层领导支持和用户的充分参与：数据仓库不是一个一般的技术主导型项目，而是一个大的群集项目，需要高层领导的支持而保证和各部门间的紧密高效配合。同时需要建立有效机制而推动各业务部门的积极深入参与，只有持续不断的基于数据仓库的海量数据建立更先进的分析应用，才能发挥出数据仓库的应用价值。重视数据质量管控：数据质量太差的数据仓库，其应用价值能够几乎为零。除了做好具体的数据质量检查和维护工作，更重要的是建立一套完善的数据管控体系，不仅需要制订数据质量检查、改进和解决数据问题的任务、制度、方法与流程等，还必须有跨部门以上的领导牵头建立一个组织平台来负责数据质量问题跟踪解决和数据质量持续改进。数据质量管控是一个长期持续的过程，重点是组织治理和抓好流程，好的经验还有：持续推进元数据精细化治理；做好数据生命周期治理；建立数据质量评估模型；推进主数据和参考数据标准体系建设等。6. 同业数据仓库应用进展状况数据仓库技术在国内外银行业的应用已有多年，能够讲给银行业带来了比其传统基础业务系统更加鲜活的竞争力；然而，数据仓库建设的难度和风险也困扰着银行业的IT决策者。银行业数据仓库道路上的障碍并不是技术本身，而是在于建设策略、目标定位、需求落实、迁移过渡等逐多困难因素，这需要对数据仓库建设有深刻且高瞻远瞩的认识，同时借鉴国内外同行在数据仓库建设方面的成功经验，提高制胜把握。Ø 工商银行数据仓库建设情况工商银行运用数据仓库方法论建立的全行治理信息系统及在此基础上的整合平台，包含了全行业务交易信息、客户信息、内部治理和外部环境信息有关的细节数据，用于支持工商银行经营治理和科学决策。ü 建设策略坚持整体规划分步实施原则：1）总行统一规划，协同攻关，不搞重复建设。2）综合考虑业务重要性、数据可支持性和支持可行性。3）从全行治理、决策和业务进展需要动身，分时期逐个开发不同主题应用，合理部署进程。遵循企业信息化渐近进展逐步完善的建设规律：如图6-1。图6-1ü 业务功能全行统一的数据仓库平台（EDW）和客户统一视图：全行治理信息大集中统一平台（EDW）于2007年12月完成一期建设，实现了全行57个要紧信息系统（包括信贷系统、电子银行、核心银行等）2324张数据源表信息的逻辑集中，实现全行治理信息从物理集中到逻辑集中的飞跃。在此基础上实现对全行个人贷款、信用卡、理财金和金融资产超过万元的个人客户信息进行全面整合，实现全行重点客户单一视图、向人行报送个人客户征信信息、提供不良客户信息等功能。实现全行法人客户信息集成治理和单一视图等功能。自动化统计平台，分行特色应用数据返传与治理：建立综合统计系统，搭建全行自动化统计平台，实现全行3600多张经营治理报表的自动生成。建立动态监测子系统，实现全行境内全口径资产负债、损益等报表自动化生成，真正实现“天天损益表”目标。建立分行数据平台（BDP）报表应用系统，基于BDP的基础数据，关心分行开展特色信息应用工作。投产9个客户信用风险治理类数据仓库应用系统：如图6-2图6-2ü 架构设计总体应用架构：如图6-3图6-3总体逻辑架构：如图6-4图6-4总体数据架构：如图6-5图6-5Ø 建设银行数据仓库（DW&MIS）建行DW&MIS 是一个集中型的数据仓库架构，同时支持总体和一级分行应用。在数据仓库的总体架构框架中，分行将部署以internet扫瞄器为主的数据查询功能，同时部分一级分行也将依照其业务需要，部署支持其业务特色的数据集市和分析能力。在DW&MIS一期，分行将仅通过治理信息平台向分行公布相关的静态报表，不部署数据集市和动态数据分析能力。ü 总体逻辑架构如图6-6：图6-6源系统：在数据仓库的整个生命周期中，源系统的选择是在变化的。源数据的选择应首先从业务应用需求动身，依照一期和以后时期分析应用所需数据的需求，对建行的相关源系统进行数据筛选，并对每一个数据字段进行标准定义整理。应将所有相关表的数据都从源数据系统抽取出来，数据仓库临时不用的数据能够存放在数据整合层，以便支持以后的数据需求。在比较、选择源系统时，应采纳贴近数据产生源的原则，尽量使用归总、计算前的原始数据，选择正确的源数据。数据整合层：为了保证多系统对源系统数据抽取的需求，在数据从源数据系统抽取后在一个统一的数据整合环境中整合，完成技术层面的数据统一转换。采纳建行差不多上线的UDI数据整合环境完成数据的整合。数据整合层只承担操作型源系统的整合工作，数据仓库需要的其他中间业务系统如ERP系统将直接和数据仓库进行数据交换，而不通过数据整合层。数据整合层是批量交换数据的平台。所有从源数据系统卸载的数据，包括临时不进入数据仓库的数据都应有介质备份，以便日后需要时能够不需要对源数据接口进行大修改，这一方案需要UDI的扩容。整合层的数据保留原则：每日的数据保留一周、每周的数据保留一个月、每月的数据保留三个月。ETL层：要紧功能是完成数据从源系统的数据组织逻辑向数据仓库目标逻辑的转换及数据仓库的加载。ETL的要紧设计考量在于其数据转换及加载的效率、可扩充性以及ETL程序的自动化和可维护性，例如与元数据驱动的数据映射。出于费用和实施时刻的考量，在DW&MIS第一时期，ETL工具将采纳NCR的 Automation 数据转换及加载工具。但建行应该从企业数据架构层面考虑其长期的ETL工具和原数据治理能力的策略，以满足企业数据环境复杂性的需要。数据缓冲区及数据仓库：数据缓冲区是数据在加载至数据仓库之前的临时存贮区。数据仓库是DW&MIS的核心数据逻辑存贮空间。BI应用层：是数据仓库向终端业务用户提供应用功能支持的界面，依照顾用功能提供的形式和所采纳的应用系统的不同，BI应用层要紧定义在以下几个技术环境。治理信息平台作为数据仓库系统的一个有机组成部分，将承担着静态报表的展现、分发，手工数据的录入，指标数据的分发等任务。以后的治理信息平台需要在作业调度自动化，报表接口的标准化方向进一步提高。数据分析环境为数据仓库的高端用户提供动态的数据分析及挖掘能力，包括：动态报表的生成、多维数据分析、数据挖掘能力和治理信息仪表盘能力等。定制应用软件环境是为满足业务需要在数据仓库环境中配置的应用软件包。ü 总体数据架构如图6-7：图6-7应用主题涵盖的数据：见下表应用主题要紧数据类不用户及人数数据粒度/频率资产负债治理（ALM）公共类信息：机构、账号、科目、货币期限日期类信息：起息日、到期日等交易类信息：金额、摘要、日期时刻分户账余额类信息：余额、利息等余额信息：当前余额、初始金额等支付类信息：支付日、支付金额等利率类信息：利率、利差等总行ALM相关部门、一级分行每日财务绩效治理（F&PM）产品、客户经理、成本、利润、预算总行财务及相关部门、一级分行、二级分行和支行每月（除了应付款项外，其它为归总数据）风险治理（RM）客户、产品、机构、交易总行、一行分行每月更新分析型CRM(ACRM)客户、账户、渠道、产品、交易总行、一级分行、二级分行和支行13个月的每日数据，7年的每月归总数据多维分析报表（OLAP）客户、账户、时刻、产品、渠道、总账、货种、风险总行、一级分行、二级分行每日总行分行数据分布：见下表总行分行备注ALM总行集中统一部署无分行本地数据集市分行用户直接访问集中的ALM系统F&PM总行F&PM系统涵盖已汇总的分行数据DW分发汇总数据和应付款数据到分行本地的应用集市分行的F&PM应纳入分行本地的特色数据，如中间业务的详细数据RM总行集中统一部署无分行本地数据集市分行用户直接访问集中的RM系统ACRM总行集中统一部署无分行本地数据集市分行用户直接访问集中的ACRM系统OLAP总行OLAP系统涵盖已汇总的分行数据DW分发汇总数据和指标数据到分行本地的应用数据集市分行本地的OLAP数据集市应包括总行DW下发的汇总数据及本地特色数据大多数应用不需要大量详细数据通过网络传输，分行用户只需要结果数据。分行的F&PM和OLAP用户应首先考虑使用总行集中的数据集市，假如总行的数据集市不能满足分行的特色业务需求，分行能够采纳本地的数据集市。依照业界经验，数据集中、功能分散的方案比数据分散的总体成本低。数据仓库内数据的保留策略：见下表：基础数据包含每笔交易的详细数据、客户和账户的详细信息。对私客户的交易数据因数据量大，而且业务功能通常不需要专门长历史的详细数据，保留40天每笔交易的详细数据。对公客户的交易数据量比对私客户小，业务分析需求通常需要较长历史的详细交易数据，保留3年对公客户的详细交易数据。账户和客户为状态数据，所有的客户和账户和变化历史数据都因归纳到数据仓库里。汇总数据包括三大类数据：交易类、账户类和客户类。交易数据应按渠道、交易代码、机构、产品等维度汇总。对私客户的日汇总，如每日每种交易代码的交易额，日均余额，应保存13个月的历史。对公客户的日汇总，应保存3年的汇总数据。月汇总按国外银行的通常作法，应保留7年的历史。数据仓库系统的数据返回机制：应用数据集市只保留最新的评级结果，数据仓库保留分析结果和评级的历史。从应用数据集市到数据仓库的数据返回应采纳批处理的方式。另外，ERP系统建立之后，总帐数据直接从ERP抽取、导入到DW。DW数据质量检查：从文件级不和数据记录级不执行以下数据质量检查点。源数据质量检查。从源数据系统传输到数据缓储的所有数据都应首先同意质量检查后才能导入，源数据的质量检查应包括接口数据文件格式是否标准化的确认，并按照目标数据库系统的数据模型或数据字典将不同源数据系统的字段属性统一转换成目标系统要求的格式。ETL流程中的质量检查，每次数据的抽取、转换和加载都必须有日志记录，并确认