商业银行数据仓库浅析

商业银行数据仓库浅析营口银行内部资料BYK商业银行数据仓库浅析BYK商业银行数据仓库浅析商业银行数据仓库浅析第一版孟凡涛2012年12月目录引言 51 基本概念 61.1 操作型系统 61.2 OLTP和OLAP 61.3 数据源系统 71.4 数据仓库 71.4.1 面向主题 71.4.2 集成 81.4.3 非易失性 91.4.4 随时间变化 101.5 决策支持系统 111.6 维度和度量 112 数据仓库的好处 123 数据仓库核心内容 143.1 典型数据仓库架构图 143.2 数据模型 143.2.1 模型设计思路 153.2.2 模型设计原则 163.2.3 模型主题划分 163.2.4 拉链表 193.2.5 快照表 203.2.6 流水表 203.3 ODS层 203.3.1 ODS定义 203.3.2 ODS作用 213.4 FDS层 223.5 IDS层 223.6 数据集市 223.7 ETL过程 233.8 调度管理 233.9 元数据管理 243.9.1 基本定义 243.9.2 元数据管理的作用 253.10 数据质量管理 264 数据仓库规范 274.1 数据层规范 274.2 主题域命名 274.2.1 基础数据层（FDS）主题命名 284.2.2 集成数据层（IDS）主题命名 294.2.3 实体/表命名 294.2.4 属性/列命名 325 历史数据 346 常见问题 346.1 数据量 356.2 拉链表 356.3 索引 36引言近年来，由于计算机技术的飞速发展和科技的不断进步，数据库技术的应用在各个领域也不断的深入。在金融领域，数据库技术的发展和应用为商业银行积累了大量的日常业务数据，这些数据对于商业银行来说无异于一个巨大的宝库，蕴藏着大量的对银行管理和决策有用的信息。但如何使这些数据转换成有用的信息，为商业银行各种业务的发展提供正确的决策，传统的数据库系统已经无法满足需求。于是人们不断尝试对数据库中的数据进行再加工，形成一个综合的、面向分析的环境，以更好的支持银行决策者进行决策分析。在这种情况下，就产生了一种新的信息处理技术——数据仓库技术（DataWarehouse）。数据仓库技术在商业银行领域的应用越来越多，那么究竟什么是数据仓库，如何构建数据仓库就是本文所要探讨的内容。目前国内的很多商业银行都在建设自己的数据仓库，然而不同的厂商、不同的银行对于数据仓库的理解也各不相同，建设的成果五花八门，有很成功的案例、也有很多失败的案例。无论是哪种情况、也无论是采取哪种思路建设数据仓库，如果所建设的成果能够真正为银行所用、能够对于银行的统计分析、决策支持起到一定的作用，并且对于后续的维护工作、升级工作能够很顺畅的进行下去，我们就可以说，这样的数据仓库对于银行来说是成功的。本人从事金融行业的软件系统建设工作已经近七年的时间，也参与过一些商业银行数据仓库的规划、建设过程。对于商业银行数据仓库有一些基本的理解与认识，为了使自己的经验以及所学、所想不至于随着时间的推移而遗忘和丢失，特整理了本文关于商业银行数据仓库方面的知识。本文是基于相关数据仓库项目的经验、结合数据仓库一些书籍、文档以及本人对数据仓库的理解和在数据仓库项目中遇到的一些问题总结的一份适合银行内部科技人员在数据仓库方面学习的文档。数据仓库技术本身包含的内容较多，文中还有很多章节还可以进一步的精斟细酌，我会在后续的工作和学习中不断的对其进行完善。每个人对数据仓库的理解程度也各不相同，针对本文如果有欠缺之处，希望在数据仓库领域的资深前辈加以斧正。基本概念操作型系统操作型系统也称为面向交易的处理系统，联机事务处理（OLTP）系统。其基本特征顾客的原始数据可以立即传送到计算机中心进行处理，并在很短的时间内给出处理结果。其最大优点是可以即时地处理输入的数据，及时地得到响应。也称为实时系统，它的一个重要性能指标是响应时间。OLTP是由数据库引擎负责完成的。OLTP数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。OLTP数据库能够支持大量并发用户定期添加和修改数据，对个别事务能够很快地处理完成，并且只需访问相对较少的数据。OLTP旨在处理同时输入的成百上千的事务。对于商业银行来说，核心业务系统、国际结算系统是典型的操作型系统。OLTP和OLAP当今的数据处理主要分成两大类：联机事务处理OLTP（on-linetransactionprocessing）、联机分析处理OLAP（On-LineAnalyticalProcessing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。原始数据/操作型数据导出数据/DSS数据面向应用的面向主题的详细的综合的或提炼的在存取瞬间是准确的代表过去的数据为日常工作服务为管理者服务可更新不更新重复运行启发式运行处理需求事先可知处理需求事先不知道生命周期符合SDLC（传统的系统开发生命周期）完全不同的生命周期对性能要求高对性能要求宽松一个时刻存取一个单元一个时刻存取一个集合事务处理驱动分析处理驱动更新控制主要涉及所有权无更新控制问题高可用性松弛的可用性整体管理以子集管理非常冗余时常有冗余静态结构、可变的内容结构灵活一次处理数据量小一次处理数据量大支持日常操作支持管理需求访问的高可能性访问的低可能性或适度可能性数据源系统数据仓库中的数据通常都是来自于操作型环境中的数据，在商业银行中操作型的系统主要包括核心业务系统、国际结算系统、信贷管理系统、财务系统、ECIF等等。这些系统每天都会产生大量的业务数据和交易数据，数据仓库可以每天从这些系统中获取有用的数据加载到数据仓库中供决策分析使用。随着银行业务的发展壮大，银行产品的不断增多，数据源系统也会不断的扩充，如银行卡系统、网上银行系统、资金系统等等。也正是由于数据源系统是会不断扩充的，所以说数据仓库建设对于银行来说不是一个项目而是一个过程。即随着银行操作型系统的不断增多、数据仓库的构建也需要一直持续下去。数据仓库数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策。数据仓库是一个环境，而不是一个产品，提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。数据仓库技术是为了有效的把操作型数据集成到统一的环境中以提供决策型数据访问的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息，提供决策支持。面向主题对于商业银行来说，传统的操作型系统是围绕银行的业务应用进行组织的。对于一个银行来说，应用问题可能是储蓄存款、对公存款、住房贷款、银行承兑汇票。那么对于数据仓库来说银行的主要主题范围可能是客户、存款、贷款、中间业务。如下图所示：集成集成的是数据仓库的重要特点之一，数据仓库中存储的数据都是经过集成之后的数据。传统的数据是在操作型环境中存储的，当把数据从操作型环境转入到数据仓库时，如果不进行集成就没有意义，如果数据以一种非集成状态存放到数据仓库，它就不能很好的支持决策分析。下图为一个客户信息集成的简单的例子。非易失性数据仓库的数据非易失性是数据仓库的另一个重要特征。如下图所示，操作型环境中的数据通常是一次访问和处理一个记录，并且操作型环境中的数据是可以被更新的。但是在数据仓库中的数据通常是一次载入与访问的，并且数据仓库中的数据并不进行一般意义上的数据更新。随时间变化数据仓库的另一个显著特征是随时间变化的。如下图所示，数据仓库随时间变化的显著特征主要体现在以下几点：■数据仓库中的数据时间期限要远远长于操作型系统中数据的时间期限。操作型系统的时间期限一般是60～90天，而数据仓库中数据的时间期限通常是5～10年。■操作型数据库含有“当前值”的数据，这些数据的准确性在访问时是有效的，同样当前值的数据能被更新。而数据仓库中的数据仅仅是一系列某一时刻生成的复杂的快照。■操作型数据的键码结构可能包含也可能不包含时间元素，如年、月、日等。而数据仓库的键码结构总是包含某时间元素。决策支持系统在商业银行内部，决策支持系统（DSS）与传统的操作型系统有着明显的区别。它不是面向交易的系统，它属于银行内部的管理类系统，可以用于指导营销、分析银行的业务经营情况、预测银行的各种业务风险、指导经营决策，它的数据来源为银行内部的各种交易型系统（如核心业务系统、信贷管理系统、国际结算系统、银行卡系统、资金业务系统等）。通常是面向行内管理层、决策层和营销层的系统。典型的决策支持系统有商业银行管理驾驶舱系统、商业银行CRM系统、商业银行绩效管理系统、商业银行全面风险管理系统、商业银行全行报表系统等等。决策支持类系统的特点是利用银行各个交易系统的数据进行统计、分析、预警以达到管理和决策的需要，通常需要大量的历史数据和全方位的业务数据的支持。因此，银行建立了数据仓库的基础上建设决策支持类系统更加满足系统建设和规划的要求。维度和度量维度是指一种视角，而不是一个固定的数字；是一个判断、说明、评价和确定一个事物的多方位、多角度、多层次的条件和概念。在数据仓库的理论中，维度是一个与业务相关的观察角度，是依赖于数据的有效性和表达业务成效的关键性能指标。度量是业务量化的表示、用于评价业务状态的数值型数据、用于检测业务的成效，不同度量反映不同的业务性质，度量之间的相互独立的。如下图所示，以贷款基本信息表为例分别列出了维度信息和度量信息。数据仓库的好处众所周知，数据仓库的建设对一个银行甚至一个企业都是有着非常多的好处的。那么，为了能够更清晰的理解数据仓库的好处。可以将数据仓库与传统的操作型系统对比来看。下表从各个层面列出了数据仓库的好处：数据仓库的好处比较方面传统的操作型系统数据仓库1．系统用途面向交易的联机事务处理系统，注重的是事务处理的响应结果和响应效率。可以同时处理成百上千的交易，并且能够很快的返回结果。操作型系统主要是面向日常工作服务。面向复杂的分析操作，侧重决策支持，能够支持灵活的数据查询需求，并且提供直观易懂的查询结果。数据仓库主要面向管理者服务。2．数据方面【A】数据属于分散存储状态，均独立于各个操作型系统本身。便于高效的进行联机事务处理。不利于对数据的统一管理和维护。【A】形成了统一的数据平台，对各个操作型系统的数据进行了整合。便于对数据的统一管理和维护。【Ｂ】数据没有按照业务主题进行划分，没有进行集成和整合。【Ｂ】将来源于不同的操作型系统的业务数据按照主题进行了划分并且对数据进行了集成和整合。便于分析人员使用数据，便于对数据的灵活查询和分析。【C】数据属于面向交易的数据，数据可以被更新，随着交易的发生，数据是在实时发生变化的。没有记录某一时点的数据状态，不能反映数据的历史变化情况。【C】数据是代表过去的某一时点的数据，数据不会被更新，不会发生变化。记录着某一时点的数据状态。能够反映数据的历史变化情况。【D】数据存储时间较短，有些数据实时发生变化的，不存储历史数据。无法对数据进行持续的分析。【D】数据存储时间较长，通常为5到10年，便于对数据的长期持续性分析。便于从数据中提取出指导决策和营销的有价值的信息。【E】数据质量受系统功能及使用者的习惯决定。无法保证有较好的数据质量。【E】数据仓库的建设过程涉及到数据的集成和整合的操作，在此阶段可以通过补录的方式完善数据质量。是数据的可用性更强。3．数据仓库核心内容典型数据仓库架构图数据模型模型是现实世界的抽象，数据模型（DataModel）是数据特征的抽象，是数据库系统中用以提供信息表示和操作手段的形式构架。数据模型包括数据库数据的结构部分、数据库数据的操作部分和数据库数据的约束条件。其中，数据结构主要描述数据的类型、内容、性质及数据间的关系；数据操作主要描述在相应的数据结构上的操作类型和操作方式；数据约束主要描述数据结构内数据间的语法、词义联系、他们之间的制约和依存关系以及数据动态变化的规则，以保证数据正确、有效和相容。数据模型是数据仓库的灵魂，一套设计合理的数据模型是数据仓库建设成功并能够持续良好运行的关键。模型设计思路 数据模型的设计是一个比较复杂的过程，需要经过多次迭代过程，经过反复检验和修正，才可能逐渐接近能够反映业务的真实现状。数据模型设计的思路如下：数据源驱动：确定ODS层。 对现有的数据源系统（核心系统、信贷系统、国结结算系统等）进行分析，按照模型贴近源系统的基本原则，可以确定ODS层的数据模型。统一规范和管理驱动：确定FDS层。 需要在对源系统分析的基础上，对基础层模型各系统之间的同类数据进行轻度整合，并结合本行的业务特点和目前的应用需求，按一定的业务主题重新组织数据模型，形成基础层逻辑模型。拿来主义：选择共性加工层的参考模型，完善基础层。 选择同业成功案例的数据模型作为参考模型，结合法人行的业务特点，对参考模型加以修改完善，形成本行的数据模型。这种方法效率高，但得到的数据模型需要不断地进行修正。由此，借助他行的模型经验，可以确定本项目共性加工层参考模型。目标驱动：确定应用集市层，完善共性加工层。 根据本期项目的目标和应用系统的需求，需要产生轻度的数据应用层模型。并在此基础上，对各种应用需求进一步分析，整理出一些共性的数据加工需求；必要的话，可以对共性加工层数据模型进行完善，以满足多个目标应用的公共加工汇总要求。模型设计原则根据关键业务要素，或业务关注视角，及关键业务要素（业务关注视角）之间的关系，对数据模型进行主题划分；基础数据层的主题划分是通过抽象银行业经营活动中的要素及要素之间关系的形式，来表达商业银行的实际业务和具体的业务联系。它是独立于业务应用需求的，具有高度的稳定性和可扩展性；共性加工数据层的主题划分则是基于业务关注的视角，也就是和业务应用需求紧密相关，会根据应用系统的共性需求变化而变化；不同的数据层次，由于其业务关注视角不同，其主题划分的结果可以不同；各模型层次的主题可根据实际情况划分二级主题，便于用户定位所需数据；模型主题划分八大业务主题客户：主要组织和存放与银行客户有关的信息。包括基本信息、地址信息、信用信息、黑名单信息、财务信息等。在客户主题域中以客户号为唯一识别，通过客户号与存款、贷款、银行卡、中间业务、渠道、公用主题进行关联。存款；组织和存储企业和个人客户的在银行的存款业务相关信息，主要包括账户信息、事件信息及事故信息。主要分为按个人活期、个人定期、企业活期、企业定期四个子主题。在存款主题域中以账号为唯一识别，通过账号与客户，中间业务、渠道、银行卡、公用主题进行关联。贷款：组织和存储客户的所有贷款业务数据。根据客户的性质，将贷款客户划分为企业贷款和个人贷款两类。在贷款主题域中以账号为唯一识别，通过账号与客户、公用主题进行关联。银行卡:组织和存储客户银行卡的基本信息和交易信息。在银行卡主题域中以卡号为唯一识别,通过卡号与存款、客户、渠道、公用。中间业务：主要整合银行除存、贷款业务以外的业务，即非利息收入以外的所有业务。中间业务主题逻辑划分按中间业务种类进行划分，如国内结算业务、银保通、证券基金、外汇买卖等业务相关信息。在中间业务主题域中以客户号、账号、产品、机构、渠道为唯一识别,分别通过客户号、账号、产品、机构、渠道与客户、存款、公用主题进行关联。渠道：主要存储渠道信息、签约账户信息、渠道账户信息以及交易流水信息。根据客户性质可将渠道数据分为企业客户和个人客户。在渠道主题域中以客户号、账号、产品、机构、渠道为唯一识别,分别通过客户号、账号、产品、机构、渠道与客户、存款、银行卡、公用主题进行关联。总账：组织和存储银行当前会计核算总账以及内部帐有关的信息。在总账主题域中以产品、机构为唯一识别,分别通过产品、机构与公用主题进行关联。公用：用于存储各种业务主题公用的一些信息。主要整合内部机构、人员、公共代码等相关信息。包括统一标准代码，以及标准代码与各个源系统代码的映射及人工补充代码。各个主题间关系：业务主题优点：以贴源的原则进行设计，设计基础层的时候以具体业务作为主导，体现在银行方面就会划分出类似贷款，存款这样的常用主题。数据能保证完全和真实，因为基础模型和数据源相似率很高。拉链表拉链表是数据仓库在存储数据时最常用的一种方式。拉链表的优点是数据不会产生冗余，节省存储空间；缺点是容易出现断链的情况，数据质量会受到影响。拉链表的具体形态如下表（存款账户信息表）所示，该表中体现接链表的一个显著特征是通过字段开始日期（SDATE）和结束日期（EDATE）来标识，表示某一条记录在开始日期和结束日期之间是有效的数据。当前日期的有效数据是以‘99999999’为结束日期；当数据发生变化时，会将‘99999999’更新为变化的前一天，并插一条变化后的数据作为当前数据，以变化当天的日期为开始日期，以‘99999999’为结束日期。这就是整个接链表的变化过程。SDATEEDATEACCT_NOCLIENT_NOACCT_NAMEACCT_BALLAST_D_BAL20120924201209286224150008514747001010032809397张颖9077.0710077.0720120929201209306224150008514747001010032809397张颖6077.079077.0720121001201210106224150008514747001010032809397张颖4077.076077.0720121011999999996224150008514747001010032809397张颖3577.074077.07在数据仓库设计时选择使用接链表存储数据应该考虑以下几点：■大数据量的数据表，可以考虑使用拉链表。因为数据仓库中的数据是长期存储并且数据量是不断增长的。使用拉链表的好处是当数据发生变化才插入新的记录，使用拉链表不会重复存储数据，这样对于大数据量的数据表的数据增长速度就不会成倍的增长。可以有效的节约存储空间，并且能够提高对该数据表数据的存取效率。■字段较少的数据表，可以考虑使用拉链表。因为拉链表的数据是在发生变化是插入新记录，在插入新记录时需要将新记录与原有记录做比较，比较的时候需要逐个字段进行比较。如果字段较多会影响数据的比较效率，直接影响数据仓库的跑批效率。■数据表的逻辑主键明确，需要清晰反映数据业务变化过程的时候，可以考虑使用拉链表。众所周知，数据表中一条数据的主键是不会发生变化的，变化的只是主键之外的其它信息。拉链表的数据在发生变化进行关链和开链的时候需要通过增量数据的主键与原有数据进行比对。如果主键不明确或定义错误，在两条数据比对时如果数据变化体现在我们所错误定义的主键上面，那么就不会将原有的应该关链的数据进行及时的关链，造成拉链表数据错误。另外，拉链表的数据能够连续的反映某条数据记录变化的过程，通过整条数据链就能清晰的看到该条记录的整个变化情况。快照表快照表是每天保存全量数据，通过时间戳来表示整张数据表的每一个时间点的快照。快照表的优点是数据处理逻辑简单、方便，数据质量较高不会出现错误；缺点是数据存在冗余，存取效率低。快照表的具体形态如下表（贷款借据表）所示。FDATEDUEBILLNODUEBILLSUMDBRESTSUMDUEBILLDATEDBMATUREDATEYSYJLX20120706XDYC0000949580000.0050950.052011071920140718373.6320120707XDYC0000949580000.0050950.052011071920140718396.9820120708XDYC0000949580000.0050950.052011071920140718420.3320120709XDYC0000949580000.0050950.052011071920140718443.69在数据仓库设计时选择使用接链表存储数据应该考虑以下几点：■数据量较小的数据表，可以考虑使用快照表。因为快照表是每天一个快照，数据量重复存储。如果数据量较大不宜使用快照表，会占用大量的存储空间，并且随着时间的推移，访问效率会越来越低。■字段较多的数据表，可以考虑用快照表。因为，字段较多，如果不采用快照表而采用拉链表会影响数据仓库数据的跑批效率。流水表流水表即按照每天的交易日期增量存储数据。通常在数据仓库中，对于交易流水数据采用流水表进行存储。如存款余额变动明细表、总账流水表等数据均需要采用流水表的方式存储。流水表的特点是，数据真实性高、与原系统流水表信息一致。ODS层ODS定义ODS（OperationalDataStore）操作型数据存储，是数据仓库体系中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。ODS层的数据是对数据源的缓冲，通常不保留历史数据，根据数据量的大小数据通常存储七天到一个月的数据。ODS作用ODS的设计主要体现在以下几个作用：■在业务系统和数据仓库之间形成一个隔离层。数据仓库通常都有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据抽取不是一件容易的事情。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。■转移一部分业务系统细节查询的功能在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致性，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。■完成数据仓库中不能完成的一些功能通常，带有ODS的数据仓库的体系结构中，数据仓库层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。在一个没有ODS的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据。而是“历史的、不再变化的”数据。FDS层FDS（FundationalDataStrore）基础数据存储。所谓基础数据，即数据不进行更新、与源系统的数据保持一致。FDS层在整个数据仓库中位于ODS层之上，是数据仓库的核心层。FDS层的数据特点是“面向主题的、集成的、非易失的和随时间变化”的。对于商业银行来说，FDS层的主题通常分为客户、公共、渠道、贷款、银行卡、存款、贷款、中间业务和总账共八类主题。各个主题下的数据是由来源于ODS层的各个业务系统的数据进行了集成后的数据。数据在集成的过程中不进行更新，只加时间标识，数据的存储方式主要分为拉链表、快照表和流水表的方式进行存储。FDS层的数据每天通过增量和全量的方式进行加载，数据不进行删除，持续保存历史数据。IDS层IDS（IntegratedDataStore）集成数据存储。IDS是位于FDS之上的一层数据，数据的特点是对FDS层的数据进行了高度的整合和汇总。数据汇总方式主要将存款、贷款、总账、中间业务、客户等各个主题下的数据按照时间维、机构维和币种等维度进行汇总。这样处理的目的是便于下游各个应用系统之间是有数据仓库中的数据。IDS层在数据仓库中所做的汇总通常是针对共性的信息进行处理。而对于更进一步的汇总和加工处理通常由各个应用系统根据自身对数据的需求进行加工处理。数据集市数据集市在整个BI领域是经常提及到的概念。在很多银行已经建设了针对不同业务应用需要的数据集市，如监管数据集市、风险数据集市、信贷报表数据集市等。在银行没有建设数据仓库的情况下，数据集市是介于银行各类业务系统与应用系统之间的一层数据的集合，作为源系统数据的缓冲和应用系统的数据源。例如，在2003年银监会成了之后提出了1104工程，在2006年初便要求全国所有的商业银行报送1104报表。当时，大多数银行在建立1104报表系统时在没有数据仓库的情况下只能从银行的各个源业务系统抽取数据，在这种情况下，为了更好的实现1104报表，提高报表的取数率，大多会为银行建设监管数据集市，即从各个源业务系统中抽取出所需要的数，对数据进行一定的整合、集成，视报表情况进行一定时期内的报表历史数据的存储，以便于1104报表能够方便的从数据集市中取数。这种实现方式既不影响源业务系统又实现了监管数据的统一存储、统一规划、又为日后的监管机构的现场检查提供的依据。在银行建设了数据仓库的情况下，数据集市通常建设在整个数据仓库的基层数据模型的最上层，应用系统之下。并且，数据仓库的建设是根据各个应用系统的需要进行灵活设计，这种做法的好处是保证数据仓库不会因为外围应用系统的增加而受到影响，也不会对数据仓库造成任何性能上的压力。ETL过程ETL即数据抽取（Extract）、转换（Transfer）、加载（Load）的意思。是构建数据仓库的重要环节。ETL的过程即从数据源抽取出所需的数据，经过数据清洗转换，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。数据抽取：数据抽取程序能将数据从高性能联机事务处理方式中（如银行的核心系统、信贷系统、国结系统等）转移出来，所以在对数据进行总体分析和使用时就不会影响联机事务处理的性能。当数据抽取程序将数据从操作型事务处理范围内移出时，数据的控制方式就发生了转变。最终用户一旦开始控制数据，就最终“拥有”了这些数据。就可以直接对数据进行进一步的加工使用。ETL将数据加载到数据仓库的过程最终实现了从操作型业务系统到最终数据应用分析系统的彻底分离。调度管理调度是数据仓库运转的总协调员，任何一个数据仓库平台都离不开调度管理。一个好的调度管理是一个数据仓库平台平稳、高效运行的关键。一个好的调度管理平台通常应包含以下内容：任务作业的编排和配置；任务调度过程的监控和查看；调度日志。任务作业的编排和配置是在调度平台上线正式运行之前进行配置的内容，通常将整个数据仓库的所有的跑批任务进行统一的编号，设置前、后置的任务依赖关系，然后将具体的任务关系配置到调度平台中，之后调度管理平台就可以按照我们希望的先后顺序及并行和串行的关系进行调度。任务调度过程的监控和查看通常是提供可视化的界面供数据仓库的维护和管理人员使用，维护人员可以通过在界面上操作，方便灵活的查看到每一个任务节点的运行情况。包括查看任务节点中包含哪些子任务、每个子任务的运行状态、运行的开始时间、结束时间、正在运行的任务个数、等待运行的任务个数、成功运行的任务个数、失败运行的任务个数、任务运行的时长等。调度日志主要体现在整个调度管理平台能够接收各种ETL工具及脚本返回的日志，如可以集成Datastage、Kettle、Infomatica、存储过程、Shell、JavaClass等，即具有较好的兼容性。元数据管理基本定义元数据是数据仓库环境中一个重要方面。元数据是关于数据的数据。在数据仓库中，元数据扮演一个新的重要角色，通过元数据，可以最有效地利用数据仓库。元数据使得最终用户、决策分析人员能够探索各种可能性。元数据在数据仓库的上层，并且记录数据仓库中对象的位置。典型的元数据记录：■数据仓库表的结构。■数据仓库表的属性。■数据仓库的源数据（银行的各种操作型系统)。■从各种操作型系统到数据仓库的映射。■数据模型的规格说明。■抽取数据的历史记录。■访问数据的公用例行程序。■数据模型和数据仓库的关系。元数据为访问数据仓库提供了一个信息目录（informationdirectory），这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、怎么访问这些数据。是数据仓库运行和维护的中心，数据仓库服务器利用他来存贮和更新数据，用户通过他来了解和访问数据。元数据分为技术元数据和业务元数据。技术元数据是存储关于数据仓库系统技术细节的数据，常见的有库表结构、数据映射、汇总算法等。业务元数据从业务角度描述了数据仓库中的数据，使得不懂计算机技术的业务人员也能“读懂”数据仓库中的数据。业务元数据具体包括以下信息：企业概念模型、指标定义、代码标准化、用户访问报表的规则、权限等。如下图所示，说明了元数据与数据的区别。元数据管理的作用在数据仓库中，元数据管理具有多方面的作用。主要包括：知识共享与标准化、影响分析、血统分析、数据质量改进、版本管理、改善业务人员数据访问界面。◆知识共享与标准化降低学习与沟通成本；减少缺乏共享与标准带来的数据问题；减少员工流动带来的影响；◆影响分析减少元数据变更出错率；提高开发效率；◆血统分析支持数据分析与审计；减少数据冗余处理；◆数据质理改进跟踪数据加工环节，提供数据质量预警；为数据质量管理提供标准和依据；◆版本管理保证版本的实时性和一致性；◆改善业务人员数据访问界面标准业务术语支持；业务数据快速检索；数据质量管理数据仓库是数据的载体，数据是数据仓库存储的对象。数据质量的好坏直接影响下游系统能否从数据仓库中获取有效的、可供分析使用的数据；直接决定数据仓库的成败。因此数据质量问题是整个数据仓库建设必须重视的问题之一。数据质量指的是否能有效地支持所需要的管理应用，数据质量不能用绝对的好与坏来衡量，应该用多种数据质量度量来衡量，通常的数据质量度量包括完成性、及时性、合法性、唯一性、一致性及准确性。数据质量的管理是一项长期的工作，并不是可以一次做完，有些可以通过程序检查、有些需手工进行。并且需要客户方与数据仓库建设厂商共同来完成。通常数据质量控制可以按下列方式进行：质量标准度量标准定义控制规划完整性主要是记录缺失和字段值缺失等方面主要对ODS层的基本数据进行分析，收集基本的统计数据。基本的统计信息包括属性类别的分布、重要数字度量的最大值和最小值，空白字段。及时性指数据抽取、传送、处理、装载、展现的及时和快速性这部分内容通常需要由调度平台来完成。唯一性指主键唯一和候选键唯一两个方面需要再ODS层来完成。系统间一致性指不同系统之间的数据差异和相互矛盾的一致性数据仓库通常是多个源系统数据的整合，需要在ODS层向FDS层转化是进行处理。元数据一致性元数据管理应一致主要检查各个源系统的数据字典与ODS层之间的一致性。数据仓库规范俗话说，没有规矩不成方圆，那么一个好的数据仓库的建设在很多方面要遵循一定的规范。在这种规范下建立的数据仓库无论是对于后续数据的使用还是对数据仓库的维护都会非常方便。数据层规范在数据仓库中，统一存储和管理全行的数据，数据类型比较多，数据库表也比较多，有从源业务系统直接采集按主题整合而成的基础业务数据，有经过中间加工汇总的汇总数据，有管理应用专用的操作型数据和应用分析需要而加工出的多维分析数据。因此在平台数据库中，各数据层的数据表统一存放到一个数据库中，不同数据层采用不同的数据表命名规范，采用不同的表名前缀区分不同的数据层。下表对数据层的规范进行说明：数据区域中文名数据区域英文名数据区域前缀表命名规范备注操作型数据存储（ODS）OPERATIONALDATASTOREODSODS_源系统标识_源物理表名基础数据存储层（FDS）FOUNDATIONALDATASTOREFF_主题标识_表标识_存储标识主题标识包含一级、二级、三级主题域；存储标识为保存当前（Snap）或历史His，带H结尾即为历史表集成数据存储层（IDS）INTEGRATEDDATASTOREII_主题标识_汇总标识主题域命名“主题域”是数据模型类面向业务功能应用的概念区分，每个“主题域”由一组面向某类应用的核心“实体/表”及一组辅助“实体/表”构成。原则上，主题域及主题域细分的命名应遵循下述规则：基础数据层（FDS）主题命名序号一级主题域中文命名一级主题域英文命名二级主题域中文命名二级主题域英文命名细分细分英文名业务主题域物理表明前缀1客户CI客户公用PUBF_CI_PUB_对公客户CIEF_CI_CIE_个人客户CIPF_CI_CIP_2存款DP活期存款SA账户ACCF_DP_SA_ACC结构存款SD账户ACCF_DP_SD_ACC协议AGRF_DP_SD_AGR定期存款TD账户ACCF_DP_TD_ACC协议AGRF_DP_TD_AGR3贷款LN企业贷款LNE账户ACCF_LN_LNE_ACC协议AGRF_LN_LNE_AGR个人贷款LNP账户ACCF_LN_LNE_ACC协议AGRF_LN_LNE_AGR4银行卡CR卡公共PUBF_CR_PUB_贷记卡CRTF_CR_CRT_储蓄卡/准贷记卡DBTF_CR_DBT_理财卡FINF_CR_FIN_5中间业务AG外汇买卖XTF_AG_XT_证券STF_AG_ST_票据BLF_AG_BL_本币结算STLDF_AG_STLD_国际结算STLIF_AG_STLI_6总账GL总账GLF_GL_GL_内部账INNF_GL_INN_7渠道CH公共信息CHCF_CH_CHC_企业客户CHEF_CH_CHE_个人客户CHPF_CH_CHP_8公共CM内部组织IORGF_CM_ORG_业务参数BPF_CM_BP_公共事件PEF_CM_PE_集成数据层（IDS）主题命名序号一级主题域中文命名一级主题域英文命名主题标识+汇总1客户CII_CI_2存款DPI_DP_3贷款LNI_LN_4银行卡CRI_CR_5中间业务AGI_AG_6总账GLI_GL_7渠道CHI_CH_8公共CMI_CM_实体/表命名原则上，实体/表名称应使用易于理解、能准确描述该实体、表意义的业务术语，同时命名应遵循下述规则：

[1]物理模型表名以英文命名，中文名与英文名含义应严格一致；

[2]实体/表名不要使用不易理解的方言或有地域性/部门局限的业务术语，应使用统一的、正式的、全局范围内通用的官方业务术语；

[3]表名尽量参照原有的通用数据标准的中文名；

[4]关于物理模型实体/表中<实体标识>的命名，如果实体表所属业务在行内有比较权威的源系统，且该系统的命名已经规范化，则尽量贴近权威源系统的命名，如：核心业务贴近FIS系统，尽量参照数据字典中表命名；

[5]物理模型实体/表英文名全部使用字母大写。如果实体/表英文名由多个单词组成，单词之间用下划线分开；

[6]物理模型实体/表命名不超过30个字符，应尽量使用简练的英文拼写。个别超长的需要提出来，模型组统一综合考虑（主要考虑一些数据库（如TERADATA、ORACLE）定义的表名不能超过30个字符）。

[7]历史实体中文名一般用“<当前实体中文名>”命名；英文名用“<当前实体名>”。操作数据层（ODS）命名[1]格式为：O_源系统标识_源表名称示例：核心系统客户信息表O_FIS_CUSTMERS(注：ODS存储层_FIS核心系统标示_客户信息表)[2]物理表统一增加字段：DATA_DATEVARCHAR2（8）--数据日期YYYYMMDDLOAD_DATEDATE--加载日期PROD_IDVARCHAR2(5)--数据源系统标识SOURCE_DATA_TYPEVARCHAR2(1)–源数据类型LOAD_TYPEVARCHAR2(1)--加载方式（全量或增量）基础数据层（FDS）命名[1]格式为：F_主题标识_表标识_存储标识。示例：企业贷款账户信息表F_LN_LNE_ACC示例：企业贷款账户信息历史表F_LN_LNE_ACC_H[2]物理表统一增加字段：FDATEVARCHAR2(8)--数据日期/交易日期SDATEVARCHAR2(8)--拉链表的开始日期EDATEVARCHAR2(8)--拉链表的结束日期[3]FDS物理表设计考虑如下字段信息：机构信息机构编码（开户机构营业机构账务机构均考虑下）客户信息客户号（涉及到关系档主档交易流水等）卡信息：卡号（涉及到交易流水信息）集成数据层（IDS）命名格式为：I_主题标识_汇总标识其中汇总标识可以为：<指标的主词>_<指标的类词>_<汇总维度>_<时间维度>。示例：个人存款余额按账户月汇总表I_DP_PER_AMT_ACCT_MONTH取值说明：类别说明取值说明备注分区代码汇总区分区代码全部取为：IIDS层主题标识分析汇总区的业务主题分区存款：DP；贷款：LN；

银行卡：CR；中间业务：AG

渠道：CH；客户：CI；

总账：GL；公共：CM；指标主词该表存放的指标的关键词缩写如：活期存款：SA

企业客户：CIE指标类词对“指标关键词”的进一步说明如：数量：NUM；金额：AMT

交易：TX；不明确的：ALL汇总维度按机构：INST

按客户：CUST

按客户经理：CUM

其它维度选：ALL时间维度汇总时间频度年：YEAR；月：MON

日：DAY；季：QUAR

旬：TEND；半月：HALFM

半年：HALFY数据类型规范字段含义数据类型说明配置类型日期类（年月日）日期类型数据。定义为：date时间类（时分秒）时间类型的数据。定义为：char(6)

格式：HHMMSS24小时格式日期时间类（年月日时分秒）日期及时间类型的数据。定义为:date精确到毫秒的时间戳

（年月日时分秒毫秒）9(15)COMP-3CONVTIMESTAMP定义为:timestamp太阳日太阳日，表示某年的第几天，

格式为：YYYYDDD

YYYY表示年份；DDD表示该年

的第几天，取值范围从1到366；

将转换为正常的日期格式：

YYYY－MM－DD定义为：date旬日期格式：YYYYMMT（年月旬），T=1

代表上旬，T=2代表中旬，T=3

代表下旬，例如：2010年10月

下旬表示为2010103。定义为：char(7)指示器表示“是/否”意义的指示器，

例如：外部产品标志，雇员标

志，等等。定义为:char(1)

具体含义：“1－是，0－否”。整数类数据包括长整数和短整数。定义为：number(12,0)金额类数据所有金额类数据，例如：资产

评估价值，负债余额，等等。定义为:number(20,2)或

number(20,3)(20位数字字

符，其中包括小数点和两（三）

个小数位)。一般数值类数据一般的、无特殊含义的数值

例如：不动产面积，等等。定义为:number(16,2)利率利率数据。定义为:number(8,6)汇率汇率数据。定义为:number(15,10)费率费率数据。定义为:number(8,6)占比（百分比类数据）某种情况相对另一种情况的占

比，一般在0和1之间取值，

例如：市场占有率，资产折旧

率，等等。定义为:number(8,6)比率（百分比类数据）两种情况之间的比率，可能会

出现大于1的情况。定义为:number(16,8)一般字符串记录描述性的文字。varchar2(n)属性/列命名原则上，属性/列名称应使用易于理解、能准确描述该属性/列意义的业务术语，同时命名应遵循下述规则：[1]逻辑模型属性名以中文命名，物理模型列名以英文命名，中文名与英文名含义应严格一致；

[2]属性/列命名不要使用不易理解的方言或有地域性/部门局限的业务术语，应使用统一的、正式的、全局范围内通用的官方业务术语；

[3]属性/列的中文名称尽量保留实体所属主题的名称作为前缀，比如“活期账号”、“定期账号”；

[4]属性/列名称通常由两部分组成：“主词”和“类词”，“主词”部分标明属性/列标明所描述的对象内容；“类词”部分标明属性/列所描述的内容的类别。如：属性“CUST_TP”中，“CUST”是“主词”部分，表明该属性/列描述的是“客户”；“_TP”是“类词”部分，表明该属性/列是一个描述“（客户的）类别”；

[5]关于属性/列的命名，如果实体/表所属业务在行内有比较权威的源系统，且该系统的命名已经规范化，则尽量贴近权威源系统的命名；

[7]英文名全部使用字母大写，如果属性/列英文名由多个单词组成，单词之间用下划线分开；

[8]属性/列命名不超过30个字符，应尽量使用简练的英文拼写。个别超长的需要提出来，模型组统一综合考虑（主要考虑一些数据库（如TERADATA、ORACLE）定义的表名不能超过30个字符）；

[9]对于以“编号”作为标识符的属性/列，中文名一般统一命名为“××编号”；英文名后缀应是ID，如“参与人编号PTY_ID”，“渠道编号CHL_ID”等；

[10]特殊的，对于一些有习惯叫法的编号类属性/列，如，“银行卡的卡号”，为了遵循使用习惯，以使模型更易理解，可不将之命名为“卡片编号”，而遵照习惯直接命名为“卡号”，其英文名也可以遵照习惯命名为“CR_NO”，而不用命名为“CR_ID”。但这种情况不多，如果遇到需要单独提出来交模型组统一批准；

[11]日期类型的属性/列，后缀应是DT，如“开户日期OPEN_DT”等；时间类型后缀应是TM，如“事件发生时间EVT_TM”等；遇到时间戳类型称为“时间标签”，用DTTM后缀，建议尽量不要使用，如果需要提交项目组批准；

[12]实体/表和属性/列的命名中英文都应保持同步。历史数据数据仓库