银行数据中心应用平台项目方案建议书

1、银行数据中心应用平台项目方案建议书目 录 TOC o 1-3 h z HYPERLINK l _Toc492504544 第1章项目概述 项目概述项目背景目前，商业银行已经建立了可以覆盖全省的网络中心，1个营业部33个机构网点主要分布在德阳市、成都市、广汉市、什邡市、绵竹市、罗江县、中江县。并且，随着业务的发展，行内已拥有28个业务系统，目前有28个业务系统：信贷系统、核心系统（改造中）、财务系统、中间业务、大额支付、小额支付、银联前置、微贷系统、网上银行系统、ATM&POS&CC、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像

2、、财税库银、身份核查、柜面通、城商行清算中心、电子回单柜系统、同城票据交换、银医联名卡系统、理财业务系统、渠道平台。 业务系统现状核心系统目前正在改造，综合报表系统（包含1104报表、人行支付报表、反洗钱报表、行内监管报表）待建。信息技术部针对目前应用系统对业务系统的数据使用情况出台了一套数据使用标准、规范，目前还没有进入到具体实施阶段。 数据使用现状目前行内所使用的各种应用和来源数据之间交叉成网状。 众多业务系统的建立使我行的业务在准确性、实时性上得到了极大的提高，同时也降低了业务人员的办公出错概率。虽然，电子化系统能极大的提高业务效率，但是，随着电子化系统的不断增多，其存在的缺点也逐渐的暴

3、露出来：数据孤岛，使得各业务系统之间数据共享困难。不同业务系统的相同指标数据有可能不一致，使得系统之间的衔接困难，不能满足后续应用系统的快速构建的需要。大量数据冗余。为满足多个应用系统，需要同时对多个源系统进行频繁数据采集，且每个应用系统都会向源系统采数，效率不高，对源系统的压力较大。不能满足后续应用系统快速构建的需要。 每个系统的开发商不同，其数据模型和标准也不同，数据的可用程度降低。 这些缺点，降低了行内数据的数据抽取、数据转换、数据整合、数据加载、数据归档、数据监控调度等，影响了相关部门对数据的管理分析。项目目标数据中心应用平台项目的目标是：解决目前我行各业务系统数据间存在的数据孤岛、数

4、据冗余、数据标准化的问题。整合所有的业务系统（不仅包括我行现有的系统，还需要考虑到我行以后将要建设的系统）源数据准确完整地分析我行现有的数据及其流向，为各个业务部门的管理分析提供统一而且完整的数据支持（如数据抽取、数据转换、数据整合、数据加载、数据归档、数据监控调度等）为今后各个面向主题的分析型应用系统的开发建设提供数据基础和技术基础。通过实现统一数据视图和数据的服务和共享，提高商业银行企业管理电子化水平。符合银监会银行监管统计数据质量管理良好标准的相关要求，并配合人行金融统计标准化试点工作的建设。项目需求项目要完成以下功能需求：数据中心能够方便完成数据处理、数据存储、数据使用、数据备份、恢复

5、等工作的全程管理。提供自动化处理管理机制，能够管理任务调度和查询日志。数据源整合数据中心应整合的源系统数据有（但不限于）信贷系统、核心系统、财务系统、中间业务、大额支付、小额支付、银联前置、微贷系统、网上银行系统、ATM&POS前置、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像、财税库银、身份核查、柜面通、城商行清算中心、电子回单柜系统、同城票据交换、银医联名卡系统、理财业务系统、渠道平台。能基于数据中心管理业务系统产生的新的数据。针对缺失的数据能提供手工补录功能。能够分析缺失数据的源头并针对数据源提出合理的改造方案。数据抽取

6、采用先进的ETL工具，将不同数据平台、不同源数据形式、不同性能要求的源数据数据抽取到数据中心系统中。在数据抽取时需要重点考虑数据抽取的效率，以及对现有业务系统性能及安全的影响。数据采集过程应该是自动化的，在每天业务系统日结完成后立即自动化进行数据采集，不需手动出发。避免抽取过程中源系统发生业务而导致抽取数据差异问题。数据转换对从不同数据源采集到的数据，根据数据模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性，为应用平台提供高质量的数据服务。项目前期确定数据转换的粒度和规则。数据加载采用高效的加载性能数据加载工具，将处理加工后的数据载入数据中心

7、。历史数据归档数据中心的建设应充分考虑行内至少20年的历史数据的存储及在线查询。统一监控调度数据中心做为全行的数据交换中心，是一个非常庞大的系统，其投产后的运转情况均是自动化的，那么必然需要一套合理的、健全的、成熟的、统一的监控调度策略，以保证整个系统安全、稳定、简单的运行。金融数据模型建立高度抽象、实用的数据中心模型：数据中心项目对数据模型要求较高，数据模型的合理与否将关系到项目的成败，因此必须选择先进合理的建模理念，紧密契合已有业务系统，深刻了解银行业务和核心系统，建立高度抽象、实用的数据中心模型。建立适合商业银行的指标库体系。数据中心模型的建立应充分考虑下列应用（但不限于）对数据的使用：

8、综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表）行长决策系统（领导驾驶舱）财务管理系统管理会计系统绩效管理系统非现场审计系统操作型客户信息系统（OCRM）分析型客户关系管理系统（ACRM）银行风险管理系统数据分析及业务应用展现通过先进的展现工具及多样化的展现方式，向用户提供灵活而强大的查询、统计、分析功能，并按要求生成报表。在数据中心基础上需要建立的业务应用包括：综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱

9、报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表）行长决策系统（领导驾驶舱）（要求支持移动应用）元数据管理建立有效的元数据管理平台，保证系统与业务的运作保持同步并且根据市场和业务需求的变化随时作出调整，一旦业务需求发生改变，用户可以通过对元数据的维护使系统的运行作出快速的响应。数据质量管理建立有效的、可视化的数据质量管理平台，能够通过建立检验规则，对源数据质量进行持续监测，并自动生成数据质量管理报告；能够实现可视化的数据追溯展示，清晰展示数据指标与源数据之间的逻辑关系。解决方案概述数据中心应用平台我们建议商业银行以业界通用的数据仓库理论来建设数据中心应用平台项目，数据仓库之父H

10、WInmon是这样定义数据仓库的：数据仓库是一个面向主题的、集成的、不可更新的且随时间不断变化的数据集合。数据仓库是基于大规模数据库的决策支持系统环境的核心。它具有以下特征：海量数据 （TB 级）：包括来自于不同数据源的不同粒度的信息 面向主题：面向业务分析人员、管理决策者关注的主题（或者说分析目标） 集成性：将多个数据源异构数据按统一的结构和规则进行数据抽取、转换、清洗、装载时序性：数据仓库中的时间期限要远远长于操作型系统中的时间期限，比如一些应用数据保留510年。数据仓库中的数据是一系列某一时刻生成的复杂的快照。持久性：除了记录变化时间的之外，一般不对业务数据做修改。而独立的ODS或者数据

11、集市是为满足已定义的用户组或业务领域对于特定业务信息的需求而创建的。它们比数据仓库更小且更关注在数据中构建复杂的业务规则来支持功能强大的分析。我们建议的数据中心应用平台是由ODS，数据仓库和数据集市统一构成，建立在企业级的数据模型之上的。ODS是数据仓库的数据准备区域，重点完成数据的整合与转换，数据仓库完成数据的内容整合与统一，保留数据变化的历史，并按照业务需求进行汇总等加工运算。数据集市就是企业级数据仓库的一个子集，数据集市的数据来源数据仓库，但是数据粒度上看，都是汇总数据，它主要是面向某个特定的分析主题解决方案体系架构根据对数据仓库的建设经验，在充分理解商业银行的项目需求的基础上，我们制定

12、出符合商业银行实际的整体解决方案，包括以下四个部分：系统规划方案：规划商业银行未来几年内数据中心应用平台系统建设，包含应用规划、技术规划、实施规划等内容技术解决方案：从技术实现角度说明商业银行数据中心应用平台系统的解决方案，包括总体逻辑架构、物理架构、方案详细设计等内容产品解决方案：对实现技术解决方案中所采用的软硬件产品配置进行说明实施方案：介绍在项目实施中的方法论，在本次项目实施中的组织架构、时间计划等内容系统规划方案总体规划数据中心应用平台规划蓝图数据中心系统建设是一项循序渐进，迭代上升的系统工程；需要协调不同业务线价值释放及不同业务应用的优先级。一个完整的数据中心建设应包括规划设计、平台

13、建设以及应用建设等几个部分。数据中心建设的内容和优先级可以参考下图： 数据中心建设从长远看，要达到如下的目标：建立统一的数据、业务视图，完成基于数据仓库的企业信息整合，建立完善的基础数据平台，为数据分析和数据分发奠定基础。建立综合报表系统，解决业务上急需的各种业务报表。建立主题分析应用，比如资产负债分析、利润分析、客户关系管理、风险分析等。逐步实现对银行日常操作流程的支持，分析系统成为业务流程的不可或缺的一部分，实现业务系统和分析应用之间的闭环。商业银行数据中心实施路线图数据中心规划实际上是一个确定应用优先级的过程，业务需求是确定优先级的标准。数据中心建设历程建议划分成为几个阶段，根据实际情况

14、可以适当调整。各个阶段中的应用建议迭代周期不要超过8个月，这样最有利于项目实施过程中的质量控制、风险控制，而且在短的时间内不断的取得应用成效。根据商业银行的项目需求，结合我们对商业银行的理解，建议的项目实施路线如下：项目一期建设内容需求调研、规划、建模阶段 以当前数据源系统和报表集市为主要调研对象，详细分析加载到数据中心平台的数据源信息、对数据的加工处理、数据中心平台之上实现的应用功能 根据需求调研结果，给出数据中心平台的架构设计 完成数据源分析，结合数据源分析结果，对IBM的BDM模型进行客户化，完成商业银行数据中心应用平台建模工作 根据商业银行IT和业务的现状及战略规划，针对数据中心应用平

15、台系统及基于该平台的业务应用的长期建设给出详细规划 项目实施阶段（在需求调研与规划阶段评审结束后进入该实施阶段） 数据中心应用平台建设 数据仓库及ODS，数据集市搭建元数据管理平台 数据质量管理平台 企业统一调度平台综合报表平台建立 搭建统一技术架构的报表平台，实现T+1报表的展现 由于核心系统正在改造过程中，因此综合报表系统部分可以先完成需要迁移的报表的设计和开发；逐步完成1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表向综合报表平台上的迁移。针对需要迁移的报表对源系统（核心系统除外

16、）进行整合。视数据源状况逐步完善目前28个业务系统的数据整合。按主题完成面向报表应用的集市区数据的分析与加工。统一数据展现门户 综合报表展现都按照统一的展现规范集成到该门户中 实现统一登录、统一认证、统一权限管理 实现页面个性化定制，不同角色的用户可以自行根据自己的喜好、习惯及关注的内容定制不同的展现页面 项目二期建设内容项目二期主要是应用的迁移和丰富过程。在项目一期数据中心应用平台上线后，本期项目的主要目标就是快速完成旧有的应用迁移和扩展 建设适合商业银行的KPI体系 ，梳理、分析商业银行的关键绩效指标，建设完整的KPI体系 综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融

17、稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表）领导驾驶舱。经营分析决策支持系统经营决策分析绩效考核 数据归档平台项目三期建设内容本阶段为建议内容，视具体需求而定，项目三期深化数据平台的应用效果，并在数据积累达到足够成熟度的情况下，建设如下基于数据平台的应用系统：资产负债管理产品创新平台实现高层次的客户洞察分析 深化决策支持系统应用 分步实施应用系统，快速实现业务价值数据中心的业务价值最终是通过应用实施来体现的。我们建议在本期项目中，依托先进的金融数据模型进行数据内容整合，提升数据的内容价值，为后续高阶应用进行数据积累，我们如下建议的

18、基于经济资本的绩效考核、风险管理项目群、流动性分析等解决方案，都属于前瞻性需求，规划在数据中心应用平台的二期或三期进行实施。支持CRM建设的360客户视图360客户视图的概念360客户视图本身是一个平台层面的概念，其核心是把客户自然属性信息、客户的账户信息、交易信息、偏好等信息整合到一个统一的平台中，并且在此平台上建立一系列的操作型和分析型的应用，帮助银行提升客户服务质量，制定合适的产品策略等。360客户视图的需求是随着银行加强个性化服务而提出的。随着中国金融市场的快速发展和竞争加剧，中小银行在目标客户选择和营销服务战略上面临着新的决策，如何建立自身的竞争优势，确立市场地位成为关键。而这一任务

19、的重心和基石就是如何分析客户特性并与自身特点相结合，进行针对性服务和营销，从而成功建立细分优势，真正形成以客户为中心的银行。随着近年来客户关系管理的成熟，现在普遍认为360客户视图是CRM应用建设前必需的一个过程。国内银行目前正处于从传统的以账户为中心模式向以客户为中心的业务模式转变的过程中，对于中小银行来说，这个过程需要更快地完成，才能发挥自己的灵活的优势，建立忠诚的客户群体；但是，许多银行对CRM解决方案进行了巨额投入，但很多未能提供预期回报，重要原因在于传统CRM虽然在支持某个既定渠道或销售功能（例如呼叫中心或销售队伍）方面表现出色，但它并非是为满足全行客户管理的复杂性需求设计的；因此，

20、CRM计划不得不设法克服数据同步、多渠道集成和可扩展性等问题，许多银行被迫进行昂贵的修改和扩展。客户关系管理应该包含操作型和分析型两个部分，同时360客户视图也分为操作型和分析型两种。在客户关系管理过程中，销售、市场和客服人员可以在分析型和操作型360客户视图上进行合作，完成销售、客户分析和销售策略的制定。如下图所示：客服人员和销售可以通过操作型的360客户视图迅速完成客户信息、偏好、历史交易的查询，同时操作型的360客户视图具备数据写入的功能，可以支撑业务人员完成销售流程。市场部可以根据客服和销售人员的信息在数据中心应用平台中的分析型的360客户视图中进行客户细分，从而制定市场活动或者销售策

21、略，反馈给服务和销售人员。基于经济资本的绩效考核绩效考核是银行经营管理重要的风向仪和导向器。银行可以根据企业资信等因素对各项业务、产品分别设定风险系数或权重，对各项资产进行风险计量，并测算各分支行的经济资本占用额，核算经济资本增加值，从而计算经济资本回报率。然后，将经济资本回报率与其业务费用、工资奖励进行挂钩考核。同时，设定目标经济资本回报率，对实际回报率较低的机构减少经济资本配置，促使其调整资产业务结构。经营业绩考核系统实际上是贯穿银行实行价值管理的两个核心机制，一个是以经济资本为核心的风险和效益约束机制，另一个是以经济增加值为核心的绩效评价和激励机制。新的绩效考核渐行渐近绩效考核不仅是银行

22、对一定阶段经营管理状况和战略执行的检验和价值判断，同时其制度设计本身也反映了银行在特定时期的经营发展理念。我国商业银行正在从追求规模最大化的“跑马圈地”向平衡风险与利润的“价值最大化”的经营模式转变，因此，其绩效考核体制总体上也呈现出从过去的以利润最大化为核心的盈利能力考核，逐步转变为以价值管理为核心的综合效益考核，即从管理利润提升到管理价值。以管理利润为指向的绩效考核，核心任务是规模的扩张或既定规模下的利润最大化，从投入/产出角度分析，主要实现对产出水平的结果考核；以管理价值为指向的绩效考核，核心任务是在合理运用资本的基础上，通过调整各部门、各业务、产品、客户等内部结构的投入/产出关系，实现

23、整体的价值最大化。这种绩效考核方法更关注与银行的资本结构的合理配置，提高银行的利润率。 以经济资本为核心的绩效考核起点较高，建设的难度较大，需要专业的实施团队参与，表现在以下几个方面：经济资本的计量复杂。现在国内普遍采用系数法计算，也就是Basel II中的基本法，这种方法的关键在于需要制定大量的系数，系数的准确性要求很高，我们建议采用进一步细化系数类别的方法，从区域、行业、产品、客户等不同维度细化经济资本系数。经济增加值计算的准确性。经济增加值的计算是盈利减去经济资本的最低回报率，最低资本回报率一般采用市场的拆借利率或者长期国债利率等，这种方法比实际值低，有待进一步提高。我们建议在绩效考核的

24、实施过程中，逐步建立适合本行的最低资本回报率的预算办法，使经济增加值的计算更准确。过于偏重财务指标。基于管理价值的绩效考核统一也需要关注非财务指标，比如客户服务质量、员工发展、内部管理等KPI，这样更统一把企业的长期战略和员工的绩效关联，减少短视的行为，确保企业的持续发展。与长期战略联系不紧。以下就如何使得绩效考核与长期战略相结合给予详细的描述。风险管理项目群风险管理整体解决方案商业银行遵循巴塞尔新资本协议满足最低资本要求的第一步即是实行定量风险计算和管理。商业银行不仅通过定量风险管理来满足监管机构的要求，获得更低的资本金要求，也通过控制自身风险在提高资金运营效率的同时减少风险损失。基于其多年

25、在数学和分析优化方面的积累，结合其在银行领域的客户经验和行业知识，提出了端到端的Basel II 银行全面风险管理解决方案。上述架构包含一下几个关键模块：数据分析、Basel II差距分析模块。数据整合模块。进行数据的整合、元数据定义、数据质量管理、清洗、转换、装载。数据平台。采用数据仓库技术建设风险平台。计算引擎。数据集市。为外部风险报表和应用提供数据。展现模块。包括和风险相关的报表和分析型应用。针对我国中小银行风险管理案面临的挑战，我们的解决方案使用了如下措施应对：其中，风险计量模块的架构如下所示：上述计量模块具有如下特点：此模块中，使用了仿真技术在一定程度上弥补了国内严重的数据差距问题。

26、通过业务建模和规则录入的方式，把业务条件的变化通过建模的方式提供给风险引擎，从而使得风险引擎可以根据外部条件的变化选择合适的算法完成风险的计量通过流程建模的形式分析操作风险。 通过对建模后的流程的执行进行仿真，结合专家知识、活动与风险因子的关系等，识别出来高风险的活动和风险因子的管理关系。流动性分析流动性分析的功能流动性分析是资产负债管理领域中非常重要的一个应用。商业银行的流动性意味着商业银行满足存款人提取现金和借款人合理贷款需求的能力，保持流动性是商业银行的生命之本。如银行不能保持一定的流动性，即使从技术上讲，该银行仍然有清偿能力，也会被强制关闭。传统的流动性分析是采用资产和负债的比例管理的

27、方法，给资产和负债规定一系列的比例，通过对比例的值的限定，使得银行不能过度使用自己的资金，从而达到一个合理的规模。例如下述比例指标：资产流动性比例指标本外币合并：流动性资产期末余额/流动性负债期末余额25% 外汇：流动性资产期末余额/流动性负债期末余额60% 中长期贷款的比例指标人民币：余期一年期以上（不含一年期）的中长期贷款期末余额/余期一年期以上（不含一年期）的存款期末余额120% 外汇：余期一年期以上（不含一年期）的中长期贷款期末余额/外汇贷款期末余额60% 存贷款比例指标（分别本、外币两类按月考核）人民币：各项贷款期末余额/各项存款期末余额75% 外汇：各项贷款期末余额/各项存款期末余

28、额85% 国际商业借款比例指标（仅对外汇进行按季考核）（自借国际商业借款+境外发行债券）期末余额/资本净额100%可以看出，上述方法可以确保银行的流动性风险在可控的范围内，但是计财人员无法得到准确缺口的值，所以，在建设完成数据中心后，我们建议采用基于现金流的方法进行流动性的分析。技术解决方案数据中心整体架构设计数据中心应用平台的数据沉淀和分析功能的开发伴随着银行的成长甚至转型，所以平台需要具备足够的稳定性，以应对源系统和外部分析需求的不断变化。因为源系统改造或者重建，而导致数据仓库重建往往会引起数据仓库项目的失败。从整体上数据仓库的架构具备足够的稳定性，能够适应数据源的不断变化。数据中心的设计

29、应当充分考虑数据质量的问题，准确的、业务人员可信的分析结果建立在准确的数据基础之上，数据仓库应该有良好的机制确保数据的准确性。能够尽早发现数据质量问题，定位数据质量问题，在数据仓库的范围内尽可能提高数据的质量。在架构和技术层面，数据仓库和外围业务系统应保持松耦合的关系，确保数据仓库的数据运行不会对关键业务系统的性能和稳定性有影响，最重要的就是体现在数据仓库如何从源系统抽取数据，既要保证对源系统的影响最小，同时也可适应源系统的数据源的变化，这就要求数据抽取这一层的设计具备足够的灵活性、稳定性和源系统的无关性。 随着数据量的增加，数据仓库应该提供有效的数据生命周期管理策略，和高性价比的水平扩展和垂

30、直扩展能力，确保数据仓库的效率和成本的可控。大量数据仓库的失败是因为董事会不愿意承担因数据量的增长导致巨额的平台扩展成本 。支撑数据中心的数据源和应用非常丰富，随着数据中心的发展，会有不同机构的数据进入数据中心或者需要在数据中心上部署不同厂商的应用，所以数据中心平台应该采用开放的技术 系统设计原则优秀的系统设计需要满足很多要求，例如开放性、扩展性、安全性等等。基于IBM的数据仓库实施方法以及IBM的软硬件产品架构，我们的系统设计符合以下原则：开放性与先进性：基于开放式标准，遵循国际标准，提供开放的数据接口，可以进行数据的转入和传出，实现系统间互连。采用先进成熟的设备和技术，确保系统的技术先进性

31、，保证投资的有效性和延续性；灵活性与可维护性：系统应易于扩展、升级和移植，并具备支持业务处理的灵活的参数化配置，业务功能的重组与更新的灵活性，新的业务应用可灵活增加，不影响系统原有业务流程。具有灵活的、可进化的数据体系结构，允许任何数据被有序引入，并与原有的数据保持一致和集成；可扩展性与可伸缩性：具有开放的、可扩展的系统结构，允许系统与其它应用系统集成，新的功能模块可以被迅速增加或定制出来。具有平滑分布和升级、灵活的可伸缩能力，允许将不同的计算任务分布到不同的机器上去，而不妨碍其它部分的运行；完整性：对整个系统进行统一规划和设计，确保统计应用、数据中心系统和第三方工具紧密集成，共同构成一个达到

32、目标的系统，并且在数据、应用、服务、风格、操作方面，都能够做到一致性和完整性；安全性与可靠性：提供良好的数据安全可靠性策略，采用多种安全可靠的技术手段，保证系统及数据的安全与可靠；可用性和容错能力：系统具有安全运行的管理措施，即使在系统遭到非人为破坏，也能够在最短的时间内恢复使用；准确性与实时性：保证系统数据处理的准确性，提供多种数据审查手段，数据的传输要及时、准确、可靠和安全；易用性：系统设计面向最终用户，必须保证易操作、易理解、易控制；系统所出现的问题能够及时预报并迅速解决。总体逻辑架构在该总体逻辑架构中，我们根据应用架构的设计，结合IBM整体数据仓库平台方案来满足商业银行的需求。源系统层

33、收集和存贮操作数据以对业务现状进行分析。数据源指存储于各系统中的数据及外部数据，包括：核心系统以及信贷系统、中间业务、国际结算等业务系统。ETL层提取/Extract, 转换/Transform 和 装载/Load (ETL) ，ETL层解决跨系统的数据收集与整合。抽取是指识别最佳的数据源，并从中获得所需的数据。它是将数据导入数据中心的第一步。抽取意味着读取并理解源数据，并复制数据中心所需要的部分。转换泛指使数据中心数据适合于终端使用的过程。这一过程包括那些将源数据格式变为目标数据库格式的模块。一般而言，转换包括映射、清洗、汇总、重排和排序等步骤。从源系统到数据仓库之间的ETL 将需要完成对源

34、数据的清洗和整合，最终在数据仓库中形成企业范围内的统一的、一致的数据集； ETL还包括数据仓库到数据集市的分发。从数据仓库到各数据集市之间的ETL 过程主要是根据不同主题数据集市分析的需要，从数据仓库中提取数据经过转换生成主题特定的数据集。这一部分的处理往往也是最为复杂的。企业级数据整合策略，或者称之为我们熟悉的ETL，不过这里的ETL是经过扩展的，数据处理的过程和手段更为丰富，整个数据流程的处理更有策略性数据抽取和转换，后面会介绍到，我们采用信息集成总线的思想来处理数据抽取，这样数据集成收取采用模块化的方式设计，同时又能支持源数据的多样性和异构性，集成总线内最主要的功能CDC用来做实时的数据

35、抽取，联邦可加速数据集成开发的效率和易用性，同时可便捷的实施数据质量相应的管理应用。数据仓库层中央数据仓库存储输入的数据和结果数据，数据仓库做为所有分析功能的单一数据源。数据仓库的数据存储要保持稳定性、灵活性、扩展性。一般的，数据仓库会采用成熟的数据仓库模型进行构建。数据仓库中的数据按照数据模型分主题进行组织和存放，包括当期的和较长时间的历史数据。数据仓库的核心是企业级数据模型的规划和设计，是所有应用的基础。数据仓库，数据的核心存储区域，以面向主题的方式，细粒度的保存原子数据，即屏蔽数据源的多样性和变化，又可方便的为BI应用提供数据支持ODS（Operational Data Store）操作

36、型数据存储通过ODS提供单一的主数据管理，比如客户主信息管理、产品主信息管理等等。另外，通过ODS可以完成实时数据仓库要求。对于高价值客户的一些信息，可以通过复制的方式，实时或者近实时地复制到ODS系统中。或者通过ODS完成为其它的系统提供数据源的任务。ODS，可操作数据存储区域，身兼二职，一方面保持与源系统的业务数据同步以满足一些实时性应用的数据需求，另外作为一个与源系统近似的数据加工区为仓库提供数据加工服务数据集市层数据集市的数据为最终的前端分析、报告提供支持数据集市的数据是面向最终应用的，比如CRM、绩效、反洗钱等等。数据集市的数据基于数据仓库之上进行汇总加工而成。数据集市设计用途是要满

37、足特定的目的，同时具有查询、分析和报表功能。这与企业数据仓库截然不同，企业数据仓库在信息内容与结构方面要尽可能拥有开放性与灵活性。数据集市有以下特征：为特定用途而设计数据集市设计的目的，是支持特定用户对数据子集的特定范围的查询。它以用户所要求的方式提供企业数据仓库的细节汇总。优化数据集市为了支持特定工具的访问而优化。根据工具、根据企业数据仓库提供的信息子集来设计数据集市，而不是让用户直接访问企业数据仓库中的大型数据库，这可以改善数据集市的性能。虚拟或物理数据集市数据集市可以是物理的实现，也可以是企业数据仓库表的各种视图。使用视图（虚拟数据集市）可以避免存储数据的多个副本，简化了数据管理。数据集

38、市，在设计得时候往往通过OLAP技术，利用数据仓库的数据根据用户需求建立的多维分析模型（多维立方体），模型以特定的方式存储，大大提高了前端查询访问的效率，用户能方便地实现灵活、动态、快速、多角度、多层次地分析企业数据。同时，也可以通过定制灵活的OLTP查询来了解明细数据。数据应用集市，数据经过加工和汇总，数据粒度要粗于数据仓库，为前端应用提供数据，相比数据仓库这里一般不会保留细节数据。以集成的方式展示查询、报表、分析的结果通过搭建灵活的、可扩展技术架构，在保持数据集市稳定性的同时，可以不断增加数据源，增加应用数据层，满足不断增加的业务分析应用需求。目前有很多业界灵活的报表工具，提供很多预先定义

39、的模版，快速开发，从而把时间更多的放在业务需求定义上。数据中心基础管理平台数据中心的基础，包括元数据、数据质量和数据生命周期管理，这些基础组件贯穿数据仓库整个生命周期，是数据仓库的基石，基于此之上的数据仓库平台的管理应用，使整个仓库系统更好的受控运行。元数据管理是数据中心建设的一个重要一环。数据中心建设涉及到方方面面：大量的数据源表、数据仓库表、业务需求、数据映射关系、ETL任务、ETL调度等等。一个可实施的、良好的元数据管理构架是数据中心成功的基础。完整的数据质量管理方案可以确保数据中心数据的准确性。数据质量是数据中心的生命，要保证数据中心的可用性必须保证数中心内的数据质量，建立数据质量问题

40、平台，使数据质量控制过程规则化、具体化。通过数据质量平台做到具体问题具体分析，并跟踪问题直至问题解决。数据中心逻辑架构与产品部署架构在该总体逻辑架构中，我们根据应用架构的设计，以IBM整体数据仓库平台方案满足商业银行的需求。其中，以DataStage为核心来实现数据ETL平台，实现数据分发，处理流转，质量提升，清洗转换等要求。Infomation Server平台作为企业级的ETL平台，专门用于企业级数据中心平台的应用，不仅具有强大的ETL功能，还包括了统一的Metadata元数据平台Metadata Server，数据质量提升的工具等。通过统一的元数据平台Metadata Server对商业

41、银行数据中心项目中的技术元数据和其他元数据进行管理。通过DataStage可以很好的集成商业银行现有的异构的数据源，进行数据的采集。在数据存储层和核心的数据中心平台上，我们建议采用IBM InfoSphere Warehouse数据中心平台构建基础架构，InfoSphere Warehouse数据中心平台中包含了DB2数据仓库引擎，和数据仓库管理开发工具，以及多维分析，数据挖掘等工具，可以满足商业银行在数据平台上的技术要求，并符合长期发展和应用扩展的要求。 利用InforSphere Warehouse，在将来通过该平台不断扩展EDW的功能，并且可以集成现有的ODS平台，实现统一数据管理。在应

42、用服务层，针对本次项目主要为报表应用和多维分析应用，我们建议基于WAS应用服务器平台，使用IBM Cognos作为BI分析展现和报表工具，对应用提供支撑， IBM Congnos BI分析工具，具备了完整了BI分析，报表功能，还具有绩效考核，财务分析等扩展能力。WAS应用服务器平台符合商业银行整体应用的规划和现有的环境，便于以后的扩展，满足大用户量的访问要求。以上是本次数据中心项目整体逻辑架构的产品映射图，对应了应用架构中各个层次的产品支撑。数据中心平台方案详细设计数据中心应用平台模型设计数据仓库建模业务建模业务建模阶段将对业务需求定义阶段客户化得到的业务需求进行建模，在对业务需求进行建模的时

43、候，不用关注数据访问和性能等设计方面的考虑。业务建模阶段的目标是，用理想的方式、从业务角度将数据仓库需要的信息结构化。这样做，可以确认业务需求被正确理解，并且在下一个阶段，数据仓库设计师得到可靠的、业务驱动的数据结构，大大减少近期、中期和远期维护数据仓库逻辑和物理结构的成本。因为模型具有很高的通用性，我们建议在业务建模阶段，要求相关参与人员应遵循IBM IFW的实施方法论原则。业务建模过程中，使用建模工具最终生成业务方案模型（Business Solution Model）。使用视图的概念来把需要的业务方案模版（Business Solution Template）涵盖进来，一个视图可作为一个

44、OLAP CUBE和Erwin模型的单位，在视图中，定义了所有的需要的维度和度量信息。出于范围定义的简单性，每个用户部门可能需要不同的视图定义。或者，每个业务方案模版都会定义自己的视图。模型映射根据数据源分析的结果利用工具进行从数据源到数据模型的Mapping，最终生成ETL Mapping，使数据模型符合实际业务技术需求。并在裁减过程中充分考虑今后的扩展性与稳定性。Mapping人员通常是参与数据源分析的人员，熟悉数据源的数据结构、数据质量等信息，同时也掌握了建模的知识。在Mapping过程中的几个重点：数据整合，(统)单一视图整合各个系统的数据，如核心业务系统的贷款分户帐与信贷管理系统中的

45、借据整合客户信息，核心业务系统的客户信息，信贷管理系统中的客户信息数据源分析结果作为M1 Mapping的输入Mapping按照数据源，多人协同 Mapping同时做ETL Mapping多个数据源，多个项目视图统一，多个目标视图Mapping Rule, 包含ETL Mapping，作为DataStage Job的输入标示出数据之间的业务关系根据实际业务需求，适当修改模型逻辑数据建模传统的应用系统大多是一些业务系统，从数据和应用的角度来看，它们具有以下一些特征：面向特定的应用由事务处理驱动实时性要求高数据检索量少主要处理当前数据数据按照处理流程进行组织与传统业务系统不同，目前正在建设的分析型

46、应用系统大多有以下特征：存储大量的历史数据和当前数据面向分析主题（如关系人、产品、机构等）数据来源广泛，可能会跨不同的业务系统。实时性要求不是特别高数据检索量大主要做一些综合分析处理数据需要按照分析主题进行组织因此，为了能够更方便快捷地从分析应用系统中抽取所需要的信息进行全面、综合、灵活多样的查询和分析，支持决策分析，就需要重新有效地组织原有业务系统中的数据，满足以下要求，这就是逻辑数据模型的引入。用图形的方式体现业务规则成为IT人员和业务人员沟通的工具独立于技术是集成当前数据的有效手段为未来数据的组织提供蓝图建立逻辑数据模型的意义逻辑数据模型（Logical Data Model）是一种图形

47、的展现方式，采用面向主题的方法有效组织来源多样的各种业务数据，同时能全面反映复杂的业务规则，支持大量的分析应用。逻辑数据模型使用统一的逻辑语言描述业务，是数据管理的分析工具和交流的有力手段；同时还能够很好地保证数据的一致性，是实现业务智能（Business Intelligence）的重要基础。数据方面因为分析型应用系统的数据来源非常多样化，作为源数据的业务系统都有自己的一些特点，同时它们的部分数据之间还存在或多或少的联系，所以建立逻辑数据模型的一个重要的任务就是“整合”，对数据进行统一有效的管理，效益主要体现在：整合了不同业务系统和业务平台的数据有效地避免了数据冗余保证了数据的一致性规范数据

48、的命名和使用是建立物理数据模型的重要基础应用方面从上述几点不难看出，逻辑数据模型搭建了一个灵活的数据组织框架，为不同人员（包括业务人员和IT人员）都提供了一个统一的数据平台，使大家都可以得到同样的数据信息，并据此开发相关的应用。建立“单一视图”是业务人员和开发人员的桥梁体现不同业务之间的关系，表达相应的业务规则。帮助业务用户对数据有一致的、统一的理解物理数据建模针对DB2数据库，考虑数据仓库的数据量、性能要求、安全要求等方面的因素，对数据库表结构、约束、索引等数据库物理特性进行设计和规划。物理设计原则物理模型物理化是基于模型工具导出的RDA 物理模型。制定统一的命名规范，标准字段、根据DB2/

49、DPF 特性 指定表实体的存储空间、分区键、主键、索引。物理化后提交的模型和DDL 都保存在RDA模型中。物理化方法物理化方法在逻辑模型的物理化时，不同的物理化方法得到的模型对数据库的性能也有较大的影响。其中主要体现在表的合并即超类、子类的合并，以及属性表以及主要实体的合并。如果超类属性的字段很少，此时建议把超类的属性，合并到每个子类上。称为ROLLDOWN。反过来，如果子类的属性很少，此时建议把子类的属性，合并到超类上。称为ROLLUP。为了提高数据装载和访问的性能，保持物理模型的简单性，在物理化SOR模型时我们将权衡使用如下3种方法：关系合并到父实体 子类实体归并到超类实体超类实体属性拆分

50、到子类实体命名规范首先，在物理化设计过程中，表的命名遵循模型的实体和属性的命名原则。然后，在基于物理模型进行完善和修改。标准字段处理标识键每个键值代表一个ETL处理过程，标识每个表的每条记录的生成处理流程ID。比如数据在从数据源经过DataStage处理到SSA的转换过程中都会记录一个处理标识。在ETL日志表内会记录每个键值的含义。每个表内要添加一个Physical Only的int类型的ETL_SEQ_ID的字段来记录此值。源系统标识 在物理模型中都有一个能够标识数据业务系统来源的int型字段：SRC_STM_ID。后期数据源的扩充，基于以上系统ID 往上递增。主外键由于主外键表示的是对数据

51、的一种完整性约束，保证数据的完整性，但同时也会在修改数据时要求DB2做一些额外的工作来保证这种约束，比如主键的唯一性检查，外键的存在性检查等，作为一个经验准则，为每一个物理表指定一个业务主键，由于模型中添加主键会影响很多关联关系的表，所以在模型物理化阶段中根据实际需要添加改主键，这些会在doc文档中写明。一般来说数据的完整性约束已经在我们的ETL程序内完成了，因此对于数据仓库这种特殊的应用，我们一般在主外键上遵循如下原则：逻辑实体的主键转化为物理表的主键，这时DB2会自动为此表的键值创建一个唯一性索引，此索引在与其它表Join时可以提高运算速度。分区键 DB2/DPF数据的分区有如下2个原则层

52、面：数据在不同数据库分区之间的划分：利用表的分区键（partition key）DB2自动完成。通过一个hash函数，DB2把每条记录依据其分区键的值映射到不同的数据库分区内。数据存储区域的划分：人为的指定把一部分数据放在一起，另一部分放在另外一块存储区域，这样在访问数据时DB2可以快速的定位数据的位置，从而提高数据访问性能。（这块物理架构设计中考虑）。当定义分区键时，我们不仅从数据存储分布上考虑，同时还要从业务处理能力上考虑。在这两者之间找到均衡点。有如下原则：数据均匀分布原则：为避免某个特定的分区数据量过大而成为整个系统的性能瓶颈，分区键的Cardinality最好要足够大，并且数据在不同

53、分区键值的分布是均匀的，因此表的主键或作为唯一索引的键是比较好的选择。数据同步分布原则：由于DB2的Share-Nothing特性，为最大限度的利用DB2的并行特性，避免Share-Nothing导致的不利因素（不同分区的数据关联时大量的网络数据传输），分区键最好也是常用于表之间关联的键。性能原则：用于计算分区的hash函数也需要计算量，为提高此函数的性能，分区键最好是运算速度较快的数据类型，比如整型，避免使用字符串、浮点、Decimal等数据类型。例如：比如对于IP表，会考虑选择IP_ID作为分区键。考虑因素：由于IP_ID的cardinality高，hash后数据会均匀的分布到每个分区上从

54、应用上看，和其他相关表的连接大多使用IP_id，这样会使大部分的join都是collate的，效率最高。分区键选择参考数据库建表分区原则，模型物理化时，需要考虑到实体的数据业务应用和数据均匀分布、长远数据量增加上，有下面几个标准：数据量比较小的表（一般小于10万行），物理化时建立在单节点的数据库表空间上。如：Cl数据量比较大的建立上多分区上。同时要注意以下几个方面：有单个主键的实体表，直接以主键作为分区键。对于联合主键实体表，选择关联查询次数最多的字段作为分区键。根据DPF 特性，只有在查询中包含分区键时，才能体现出DB2 性能。否则会影响到DB2处理性能。所以考虑到RDWM模型中的关系表，以

55、最多的查询的字段作为分区键。索引索引是DB2改善SQL效率的最主要工具，选择创建索引的时候可以基于如下原则：主键自动建立唯一索引，本模型中主键确定，索引将自动生成。对于快速排序操作，在频繁用于排序数据的列上创建索引要提高多列索引的连接性能，如果第一个键列有多项选择，则使用最常用“=”（等值连接）谓词指定的那一列，或使用如第一个键那样具有最多特异值的那些列。 要提高数据检索速度，可在唯一索引中用INCLUDE的方式增加其它字段。合适的列为： 根据对键的使用是正序还是逆序，可以当在 CREATE INDEX 语句中指定 是否使用ALLOW REVERSE SCANS 参数。该参数可逆向搜索索引值，

56、但是，执行按指定索引顺序的扫描比执行逆向扫描稍微更快一些。 要保证索引维护成本和空间： 要提高涉及到 IMMEDIATE 和 INCREMENTAL MQT 的 DELETE 和 UPDATE 操作的性能，对 MQT 的隐含唯一键创建唯一索引，它是 MQT 定义的 GROUP BY 子句中的列。 要帮助新插入的行根据索引进行群集并避免页分割，定义一个群集索引(MDC)。群集索引应显著减少重组表的需要。 当定义索引时可以使用 PCTFREE 关键字来指定页上应该留下多少可用空间，合理的设定PCTFREE可以保证IO的性能，同时减少数据页分裂的机会。要启用联机索引整理碎片，创建索引时使用 MINP

57、CTUSED 选项。MINPCTUSED 指定索引叶子页中最小使用空间量的阈值并启用联机索引整理碎片。如果这些删除实际上从索引页除去键，则这可以在键删除期间以性能损失为代价而减少重组的需要。除此之外，由于DB2维护索引需要占有空间和CPU，因此在创建索引的时只在必需的时候创建索引（只在证明索引能改善性能的时候再创建，否则不要创建）。创建MDC索引由于分表会增大管理和使用的复杂度，对于数据量不大的表，可以用MDC索引来提高Roll-in/Roll-out和查询的性能。在时间和代码维上创建MDC索引，可以使数据严格遵守相同时间、相同代码的数据放在一起，从而提高性能。由于MDC索引必须在创建的时候指

58、定，因此在做物理化时需要指定用于做MDC索引的列。表物理属性包含每个表的PCTFREE置为0、APPEND模式、LOCK SIZE等。数据源分析方案数据源分析数据源分析是数据中心平台建设的第一组任务之一，是一个对需要进入数据中心的业务数据库中数据结构的分析过程。通过数据源分析，我们可以对进入数据中心的业务数据有一个清楚的认识，这种认识可以简单划分为“表级别”和“字段级别”。表级别的数据源分析可以帮助我们了解表的业务含义、业务功能以及数据的特征，有利于确定数据源的范围；而字段级别的分析可以帮助我们了解数据本身的特征，如主键、数据类型等，从而掌握详尽的数据质量，对后期的接口设计、数据模型映射以及E

59、TL的开发都有着重要的指导和借鉴意义。IBM的数据仓库建设解决方案将将数据源分析分为两部分来进行，即数据源物理分析和数据源业务分析。对数据源物理特征进行的分析主要集中在字段级别，在分析中，要求对数据源中的数据结构获取详细信息，对数据变化进行准确统计，包括：字段的明确含义字段的特殊的代码意义数据类型、长度、是否可空、默认值、有效值等数据的唯一性数据如何变化更新频率数据质量和稀疏程度对数据源业务特征进行的分析主要集中在表级别，在分析中，要求对数据源的业务逻辑与业务概念进行准确定义，收集非常细节的业务含义与较高层次的关系信息，包括：数据表的明确业务含义和对应的业务功能模块，如卡、现金等。数据表的使用

60、情况说明，如未使用，代码表等。表中数据的产生方式，如直接更新、记录历史等。源系统内部数据业务关系，如参照关系，约束关系等。多个源系统间数据的业务逻辑关系。多个源系统间数据整合时的数据唯一视图的建立规则和数据准确获取标准。数据质量验证规则整理，如系统内表间关系数据质量规则以及跨系统表间关系数据质量规则，该规则用来后续数据清洗和数据检查的参考。按照以上方法进行的数据源分析示例如下：数据源分析协同工作模式通常，数据中心涵盖的数据源来源于多个业务系统，需要进入中心的数据表有少则几百张，这就导致数据源分析工作是一个复杂的大工作量任务。为了在保证质量的前提下尽快完成数据源的分析，IBM在进行数据源分析阶段