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

银行数据中心应用平台项目方案建议书目 录第1章项目概述61.1项目背景61.2项目目标81.3项目需求81.3.1数据中心81.3.2金融数据模型101.3.3数据分析及业务应用展现11第2章解决方案概述132.1数据中心应用平台132.2解决方案体系架构14第3章系统规划方案153.1总体规划153.1.1数据中心应用平台规划蓝图153.1.2商业银行数据中心实施路线图163.2分步实施应用系统，快速实现业务价值193.2.1支持CRM建设的360客户视图193.2.2基于经济资本的绩效考核213.2.3风险管理项目群233.2.4流动性分析26第4章技术解决方案284.1数据中心整体架构设计284.1.1系统设计原则294.1.2总体逻辑架构304.1.3数据中心逻辑架构与产品部署架构354.2数据中心平台方案详细设计374.2.1数据中心应用平台模型设计374.2.2数据源分析方案484.2.3数据流程设计(Data Centric View)524.2.4ETL架构设计574.2.5元数据管理674.2.6数据质量管理744.2.7数据生命周期管理794.2.8数据备份与恢复804.3综合报表平台技术方案824.3.1综合报表系统整体功能概述824.3.2普通报表的实现844.3.3OLAP分析应用的实现854.3.4即席查询平台应用的实现874.3.5集成到统一展现平台884.3.6移动BI894.3.7其它技术实现934.3.8统一展现944.3.9基于门户技术制定统一展现规范并实现报表的集成954.3.10制定统一展现规范964.3.11需求分析的流程和方法974.3.12整体测试方案974.4物理架构设计1004.4.1数据仓库配置方法(BCU)1004.4.2数据量估算1054.4.3服务器选型1074.4.4物理部署架构1074.4.5数据中心系统扩展建议109第5章产品解决方案1115.1软件配置列表1115.2产品介绍1115.2.1InfoSphere Warehouse产品1115.2.2ETL 集成工具IBM Information Server1295.2.3BI分析和报表工具Cognos151第6章项目实施方案1976.1项目进度计划1976.1.1项目一期进度计划1976.1.2项目阶段的工作内容及提交成果1986.2项目培训1986.3项目组织构架2006.3.1项目组织架构2016.4项目沟通计划2036.4.1每周项目例会2036.4.2项目进展汇报（会）2036.4.3问题处理流程2046.5质量管理计划2056.5.1目的2056.5.2范围2056.5.3质量保证组织2066.5.4质量控制过程2066.6风险管理计划和控制207第7章体解决方案的优势和特点2097.1.1丰富的实施经验2097.1.2高性能2137.1.3可扩展性2157.1.4开放性2187.1.5系统可靠性2197.1.6数据安全220第1章 项目概述1.1 项目背景目前，商业银行已经建立了可以覆盖全省的网络中心，1个营业部33个机构网点主要分布在德阳市、成都市、广汉市、什邡市、绵竹市、罗江县、中江县。并且，随着业务的发展，行内已拥有28个业务系统，目前有28个业务系统：信贷系统、核心系统（改造中）、财务系统、中间业务、大额支付、小额支付、银联前置、微贷系统、网上银行系统、ATM&POS&CC、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像、财税库银、身份核查、柜面通、城商行清算中心、电子回单柜系统、同城票据交换、银医联名卡系统、理财业务系统、渠道平台。 业务系统现状 核心系统目前正在改造，综合报表系统（包含1104报表、人行支付报表、反洗钱报表、行内监管报表）待建。 信息技术部针对目前应用系统对业务系统的数据使用情况出台了一套数据使用标准、规范，目前还没有进入到具体实施阶段。 数据使用现状目前行内所使用的各种应用和来源数据之间交叉成网状。 众多业务系统的建立使我行的业务在准确性、实时性上得到了极大的提高，同时也降低了业务人员的办公出错概率。虽然，电子化系统能极大的提高业务效率，但是，随着电子化系统的不断增多，其存在的缺点也逐渐的暴露出来： 数据孤岛，使得各业务系统之间数据共享困难。 不同业务系统的相同指标数据有可能不一致，使得系统之间的衔接困难，不能满足后续应用系统的快速构建的需要。 大量数据冗余。 为满足多个应用系统，需要同时对多个源系统进行频繁数据采集，且每个应用系统都会向源系统采数，效率不高，对源系统的压力较大。 不能满足后续应用系统快速构建的需要。 每个系统的开发商不同，其数据模型和标准也不同，数据的可用程度降低。 这些缺点，降低了行内数据的数据抽取、数据转换、数据整合、数据加载、数据归档、数据监控调度等，影响了相关部门对数据的管理分析。1.2 项目目标数据中心应用平台项目的目标是： 解决目前我行各业务系统数据间存在的数据孤岛、数据冗余、数据标准化的问题。 整合所有的业务系统（不仅包括我行现有的系统，还需要考虑到我行以后将要建设的系统）源数据 准确完整地分析我行现有的数据及其流向，为各个业务部门的管理分析提供统一而且完整的数据支持（如数据抽取、数据转换、数据整合、数据加载、数据归档、数据监控调度等） 为今后各个面向主题的分析型应用系统的开发建设提供数据基础和技术基础。 通过实现统一数据视图和数据的服务和共享，提高商业银行企业管理电子化水平。 符合银监会银行监管统计数据质量管理良好标准的相关要求，并配合人行金融统计标准化试点工作的建设。1.3 项目需求项目要完成以下功能需求：1.3.1 数据中心能够方便完成数据处理、数据存储、数据使用、数据备份、恢复等工作的全程管理。提供自动化处理管理机制，能够管理任务调度和查询日志。 数据源整合数据中心应整合的源系统数据有（但不限于）信贷系统、核心系统、财务系统、中间业务、大额支付、小额支付、银联前置、微贷系统、网上银行系统、ATM&POS前置、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像、财税库银、身份核查、柜面通、城商行清算中心、电子回单柜系统、同城票据交换、银医联名卡系统、理财业务系统、渠道平台。能基于数据中心管理业务系统产生的新的数据。针对缺失的数据1、 能提供手工补录功能。2、 能够分析缺失数据的源头并针对数据源提出合理的改造方案。 数据抽取采用先进的ETL工具，将不同数据平台、不同源数据形式、不同性能要求的源数据数据抽取到数据中心系统中。在数据抽取时需要重点考虑数据抽取的效率，以及对现有业务系统性能及安全的影响。数据采集过程应该是自动化的，在每天业务系统日结完成后立即自动化进行数据采集，不需手动出发。避免抽取过程中源系统发生业务而导致抽取数据差异问题。 数据转换对从不同数据源采集到的数据，根据数据模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性，为应用平台提供高质量的数据服务。项目前期确定数据转换的粒度和规则。 数据加载采用高效的加载性能数据加载工具，将处理加工后的数据载入数据中心。 历史数据归档数据中心的建设应充分考虑行内至少20年的历史数据的存储及在线查询。 统一监控调度数据中心做为全行的数据交换中心，是一个非常庞大的系统，其投产后的运转情况均是自动化的，那么必然需要一套合理的、健全的、成熟的、统一的监控调度策略，以保证整个系统安全、稳定、简单的运行。1.3.2 金融数据模型l 建立高度抽象、实用的数据中心模型：数据中心项目对数据模型要求较高，数据模型的合理与否将关系到项目的成败，因此必须选择先进合理的建模理念，紧密契合已有业务系统，深刻了解银行业务和核心系统，建立高度抽象、实用的数据中心模型。l 建立适合商业银行的指标库体系。l 数据中心模型的建立应充分考虑下列应用（但不限于）对数据的使用： 综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表） 行长决策系统（领导驾驶舱） 财务管理系统 管理会计系统 绩效管理系统 非现场审计系统 操作型客户信息系统（OCRM） 分析型客户关系管理系统（ACRM） 银行风险管理系统1.3.3 数据分析及业务应用展现通过先进的展现工具及多样化的展现方式，向用户提供灵活而强大的查询、统计、分析功能，并按要求生成报表。在数据中心基础上需要建立的业务应用包括： 综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表） 行长决策系统（领导驾驶舱）（要求支持移动应用） 元数据管理建立有效的元数据管理平台，保证系统与业务的运作保持同步并且根据市场和业务需求的变化随时作出调整，一旦业务需求发生改变，用户可以通过对元数据的维护使系统的运行作出快速的响应。 数据质量管理建立有效的、可视化的数据质量管理平台，能够通过建立检验规则，对源数据质量进行持续监测，并自动生成数据质量管理报告；能够实现可视化的数据追溯展示，清晰展示数据指标与源数据之间的逻辑关系。第2章 解决方案概述2.1 数据中心应用平台我们建议商业银行以业界通用的数据仓库理论来建设数据中心应用平台项目，数据仓库之父HWInmon是这样定义数据仓库的：数据仓库是一个面向主题的、集成的、不可更新的且随时间不断变化的数据集合。数据仓库是基于大规模数据库的决策支持系统环境的核心。它具有以下特征： 海量数据 （TB 级）：包括来自于不同数据源的不同粒度的信息 面向主题：面向业务分析人员、管理决策者关注的主题（或者说分析目标） 集成性：将多个数据源异构数据按统一的结构和规则进行数据抽取、转换、清洗、装载 时序性：数据仓库中的时间期限要远远长于操作型系统中的时间期限，比如一些应用数据保留510年。数据仓库中的数据是一系列某一时刻生成的复杂的快照。 持久性：除了记录变化时间的之外，一般不对业务数据做修改。而独立的ODS或者数据集市是为满足已定义的用户组或业务领域对于特定业务信息的需求而创建的。它们比数据仓库更小且更关注在数据中构建复杂的业务规则来支持功能强大的分析。我们建议的数据中心应用平台是由ODS，数据仓库和数据集市统一构成，建立在企业级的数据模型之上的。ODS是数据仓库的数据准备区域，重点完成数据的整合与转换，数据仓库完成数据的内容整合与统一，保留数据变化的历史，并按照业务需求进行汇总等加工运算。数据集市就是企业级数据仓库的一个子集，数据集市的数据来源数据仓库，但是数据粒度上看，都是汇总数据，它主要是面向某个特定的分析主题2.2 解决方案体系架构根据对数据仓库的建设经验，在充分理解商业银行的项目需求的基础上，我们制定出符合商业银行实际的整体解决方案，包括以下四个部分：(一) 系统规划方案：规划商业银行未来几年内数据中心应用平台系统建设，包含应用规划、技术规划、实施规划等内容(二) 技术解决方案：从技术实现角度说明商业银行数据中心应用平台系统的解决方案，包括总体逻辑架构、物理架构、方案详细设计等内容(三) 产品解决方案：对实现技术解决方案中所采用的软硬件产品配置进行说明(四) 实施方案：介绍在项目实施中的方法论，在本次项目实施中的组织架构、时间计划等内容第3章 系统规划方案3.1 总体规划3.1.1 数据中心应用平台规划蓝图数据中心系统建设是一项循序渐进，迭代上升的系统工程；需要协调不同业务线价值释放及不同业务应用的优先级。一个完整的数据中心建设应包括规划设计、平台建设以及应用建设等几个部分。数据中心建设的内容和优先级可以参考下图： 数据中心建设从长远看，要达到如下的目标： 建立统一的数据、业务视图，完成基于数据仓库的企业信息整合，建立完善的基础数据平台，为数据分析和数据分发奠定基础。 建立综合报表系统，解决业务上急需的各种业务报表。 建立主题分析应用，比如资产负债分析、利润分析、客户关系管理、风险分析等。 逐步实现对银行日常操作流程的支持，分析系统成为业务流程的不可或缺的一部分，实现业务系统和分析应用之间的闭环。3.1.2 商业银行数据中心实施路线图数据中心规划实际上是一个确定应用优先级的过程，业务需求是确定优先级的标准。数据中心建设历程建议划分成为几个阶段，根据实际情况可以适当调整。各个阶段中的应用建议迭代周期不要超过8个月，这样最有利于项目实施过程中的质量控制、风险控制，而且在短的时间内不断的取得应用成效。根据商业银行的项目需求，结合我们对商业银行的理解，建议的项目实施路线如下：3.1.2.1 项目一期建设内容 需求调研、规划、建模阶段 以当前数据源系统和报表集市为主要调研对象，详细分析加载到数据中心平台的数据源信息、对数据的加工处理、数据中心平台之上实现的应用功能 根据需求调研结果，给出数据中心平台的架构设计 完成数据源分析，结合数据源分析结果，对IBM的BDM模型进行客户化，完成商业银行数据中心应用平台建模工作 根据商业银行IT和业务的现状及战略规划，针对数据中心应用平台系统及基于该平台的业务应用的长期建设给出详细规划 项目实施阶段（在需求调研与规划阶段评审结束后进入该实施阶段） 数据中心应用平台建设 数据仓库及ODS，数据集市搭建 元数据管理平台 数据质量管理平台 企业统一调度平台 综合报表平台建立 搭建统一技术架构的报表平台，实现T+1报表的展现 由于核心系统正在改造过程中，因此综合报表系统部分可以先完成需要迁移的报表的设计和开发； 逐步完成1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表向综合报表平台上的迁移。 针对需要迁移的报表对源系统（核心系统除外）进行整合。 视数据源状况逐步完善目前28个业务系统的数据整合。 按主题完成面向报表应用的集市区数据的分析与加工。 统一数据展现门户 综合报表展现都按照统一的展现规范集成到该门户中 实现统一登录、统一认证、统一权限管理 实现页面个性化定制，不同角色的用户可以自行根据自己的喜好、习惯及关注的内容定制不同的展现页面 3.1.2.2 项目二期建设内容项目二期主要是应用的迁移和丰富过程。在项目一期数据中心应用平台上线后，本期项目的主要目标就是快速完成旧有的应用迁移和扩展 建设适合商业银行的KPI体系 ，梳理、分析商业银行的关键绩效指标，建设完整的KPI体系 综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表） 领导驾驶舱。 经营分析决策支持系统经营决策分析 绩效考核 数据归档平台3.1.2.3 项目三期建设内容本阶段为建议内容，视具体需求而定，项目三期深化数据平台的应用效果，并在数据积累达到足够成熟度的情况下，建设如下基于数据平台的应用系统： 资产负债管理 产品创新平台 实现高层次的客户洞察分析 深化决策支持系统应用 3.2 分步实施应用系统，快速实现业务价值数据中心的业务价值最终是通过应用实施来体现的。我们建议在本期项目中，依托先进的金融数据模型进行数据内容整合，提升数据的内容价值，为后续高阶应用进行数据积累，我们如下建议的基于经济资本的绩效考核、风险管理项目群、流动性分析等解决方案，都属于前瞻性需求，规划在数据中心应用平台的二期或三期进行实施。3.2.1 支持CRM建设的360客户视图3.2.1.1 360客户视图的概念360客户视图本身是一个平台层面的概念，其核心是把客户自然属性信息、客户的账户信息、交易信息、偏好等信息整合到一个统一的平台中，并且在此平台上建立一系列的操作型和分析型的应用，帮助银行提升客户服务质量，制定合适的产品策略等。360客户视图的需求是随着银行加强个性化服务而提出的。随着中国金融市场的快速发展和竞争加剧，中小银行在目标客户选择和营销服务战略上面临着新的决策，如何建立自身的竞争优势，确立市场地位成为关键。而这一任务的重心和基石就是如何分析客户特性并与自身特点相结合，进行针对性服务和营销，从而成功建立细分优势，真正形成以客户为中心的银行。随着近年来客户关系管理的成熟，现在普遍认为360客户视图是CRM应用建设前必需的一个过程。国内银行目前正处于从传统的以账户为中心模式向以客户为中心的业务模式转变的过程中，对于中小银行来说，这个过程需要更快地完成，才能发挥自己的灵活的优势，建立忠诚的客户群体；但是，许多银行对CRM解决方案进行了巨额投入，但很多未能提供预期回报，重要原因在于传统CRM虽然在支持某个既定渠道或销售功能（例如呼叫中心或销售队伍）方面表现出色，但它并非是为满足全行客户管理的复杂性需求设计的；因此，CRM计划不得不设法克服数据同步、多渠道集成和可扩展性等问题，许多银行被迫进行昂贵的修改和扩展。客户关系管理应该包含操作型和分析型两个部分，同时360客户视图也分为操作型和分析型两种。在客户关系管理过程中，销售、市场和客服人员可以在分析型和操作型360客户视图上进行合作，完成销售、客户分析和销售策略的制定。如下图所示：客服人员和销售可以通过操作型的360客户视图迅速完成客户信息、偏好、历史交易的查询，同时操作型的360客户视图具备数据写入的功能，可以支撑业务人员完成销售流程。市场部可以根据客服和销售人员的信息在数据中心应用平台中的分析型的360客户视图中进行客户细分，从而制定市场活动或者销售策略，反馈给服务和销售人员。3.2.2 基于经济资本的绩效考核绩效考核是银行经营管理重要的风向仪和导向器。银行可以根据企业资信等因素对各项业务、产品分别设定风险系数或权重，对各项资产进行风险计量，并测算各分支行的经济资本占用额，核算经济资本增加值，从而计算经济资本回报率。然后，将经济资本回报率与其业务费用、工资奖励进行挂钩考核。同时，设定目标经济资本回报率，对实际回报率较低的机构减少经济资本配置，促使其调整资产业务结构。经营业绩考核系统实际上是贯穿银行实行价值管理的两个核心机制，一个是以经济资本为核心的风险和效益约束机制，另一个是以经济增加值为核心的绩效评价和激励机制。3.2.2.1 新的绩效考核渐行渐近绩效考核不仅是银行对一定阶段经营管理状况和战略执行的检验和价值判断，同时其制度设计本身也反映了银行在特定时期的经营发展理念。我国商业银行正在从追求规模最大化的“跑马圈地”向平衡风险与利润的“价值最大化”的经营模式转变，因此，其绩效考核体制总体上也呈现出从过去的以利润最大化为核心的盈利能力考核，逐步转变为以价值管理为核心的综合效益考核，即从管理利润提升到管理价值。以管理利润为指向的绩效考核，核心任务是规模的扩张或既定规模下的利润最大化，从投入/产出角度分析，主要实现对产出水平的结果考核；以管理价值为指向的绩效考核，核心任务是在合理运用资本的基础上，通过调整各部门、各业务、产品、客户等内部结构的投入/产出关系，实现整体的价值最大化。这种绩效考核方法更关注与银行的资本结构的合理配置，提高银行的利润率。 以经济资本为核心的绩效考核起点较高，建设的难度较大，需要专业的实施团队参与，表现在以下几个方面：a) 经济资本的计量复杂。现在国内普遍采用系数法计算，也就是Basel II中的基本法，这种方法的关键在于需要制定大量的系数，系数的准确性要求很高，我们建议采用进一步细化系数类别的方法，从区域、行业、产品、客户等不同维度细化经济资本系数。b) 经济增加值计算的准确性。经济增加值的计算是盈利减去经济资本的最低回报率，最低资本回报率一般采用市场的拆借利率或者长期国债利率等，这种方法比实际值低，有待进一步提高。我们建议在绩效考核的实施过程中，逐步建立适合本行的最低资本回报率的预算办法，使经济增加值的计算更准确。c) 过于偏重财务指标。基于管理价值的绩效考核统一也需要关注非财务指标，比如客户服务质量、员工发展、内部管理等KPI，这样更统一把企业的长期战略和员工的绩效关联，减少短视的行为，确保企业的持续发展。d) 与长期战略联系不紧。以下就如何使得绩效考核与长期战略相结合给予详细的描述。3.2.3 风险管理项目群3.2.3.1 风险管理整体解决方案商业银行遵循巴塞尔新资本协议满足最低资本要求的第一步即是实行定量风险计算和管理。商业银行不仅通过定量风险管理来满足监管机构的要求，获得更低的资本金要求，也通过控制自身风险在提高资金运营效率的同时减少风险损失。基于其多年在数学和分析优化方面的积累，结合其在银行领域的客户经验和行业知识，提出了端到端的Basel II 银行全面风险管理解决方案。上述架构包含一下几个关键模块：1. 数据分析、Basel II差距分析模块。2. 数据整合模块。进行数据的整合、元数据定义、数据质量管理、清洗、转换、装载。3. 数据平台。采用数据仓库技术建设风险平台。4. 计算引擎。5. 数据集市。为外部风险报表和应用提供数据。6. 展现模块。包括和风险相关的报表和分析型应用。针对我国中小银行风险管理案面临的挑战，我们的解决方案使用了如下措施应对：其中，风险计量模块的架构如下所示：上述计量模块具有如下特点：l 此模块中，使用了仿真技术在一定程度上弥补了国内严重的数据差距问题。l 通过业务建模和规则录入的方式，把业务条件的变化通过建模的方式提供给风险引擎，从而使得风险引擎可以根据外部条件的变化选择合适的算法完成风险的计量通过流程建模的形式分析操作风险。 通过对建模后的流程的执行进行仿真，结合专家知识、活动与风险因子的关系等，识别出来高风险的活动和风险因子的管理关系。3.2.4 流动性分析3.2.4.1 流动性分析的功能流动性分析是资产负债管理领域中非常重要的一个应用。商业银行的流动性意味着商业银行满足存款人提取现金和借款人合理贷款需求的能力，保持流动性是商业银行的生命之本。如银行不能保持一定的流动性，即使从技术上讲，该银行仍然有清偿能力，也会被强制关闭。传统的流动性分析是采用资产和负债的比例管理的方法，给资产和负债规定一系列的比例，通过对比例的值的限定，使得银行不能过度使用自己的资金，从而达到一个合理的规模。例如下述比例指标：资产流动性比例指标 本外币合并：流动性资产期末余额/流动性负债期末余额25% 外汇：流动性资产期末余额/流动性负债期末余额60% 中长期贷款的比例指标 人民币：余期一年期以上（不含一年期）的中长期贷款期末余额/余期一年期以上（不含一年期）的存款期末余额120% 外汇：余期一年期以上（不含一年期）的中长期贷款期末余额/外汇贷款期末余额60% 存贷款比例指标（分别本、外币两类按月考核） 人民币：各项贷款期末余额/各项存款期末余额75% 外汇：各项贷款期末余额/各项存款期末余额85% 国际商业借款比例指标（仅对外汇进行按季考核） （自借国际商业借款+境外发行债券）期末余额/资本净额100%可以看出，上述方法可以确保银行的流动性风险在可控的范围内，但是计财人员无法得到准确缺口的值，所以，在建设完成数据中心后，我们建议采用基于现金流的方法进行流动性的分析。第4章 技术解决方案4.1 数据中心整体架构设计数据中心应用平台的数据沉淀和分析功能的开发伴随着银行的成长甚至转型，所以平台需要具备足够的稳定性，以应对源系统和外部分析需求的不断变化。因为源系统改造或者重建，而导致数据仓库重建往往会引起数据仓库项目的失败。从整体上数据仓库的架构具备足够的稳定性，能够适应数据源的不断变化。数据中心的设计应当充分考虑数据质量的问题，准确的、业务人员可信的分析结果建立在准确的数据基础之上，数据仓库应该有良好的机制确保数据的准确性。能够尽早发现数据质量问题，定位数据质量问题，在数据仓库的范围内尽可能提高数据的质量。在架构和技术层面，数据仓库和外围业务系统应保持松耦合的关系，确保数据仓库的数据运行不会对关键业务系统的性能和稳定性有影响，最重要的就是体现在数据仓库如何从源系统抽取数据，既要保证对源系统的影响最小，同时也可适应源系统的数据源的变化，这就要求数据抽取这一层的设计具备足够的灵活性、稳定性和源系统的无关性。 随着数据量的增加，数据仓库应该提供有效的数据生命周期管理策略，和高性价比的水平扩展和垂直扩展能力，确保数据仓库的效率和成本的可控。大量数据仓库的失败是因为董事会不愿意承担因数据量的增长导致巨额的平台扩展成本 。支撑数据中心的数据源和应用非常丰富，随着数据中心的发展，会有不同机构的数据进入数据中心或者需要在数据中心上部署不同厂商的应用，所以数据中心平台应该采用开放的技术 4.1.1 系统设计原则优秀的系统设计需要满足很多要求，例如开放性、扩展性、安全性等等。基于IBM的数据仓库实施方法以及IBM的软硬件产品架构，我们的系统设计符合以下原则： 开放性与先进性：基于开放式标准，遵循国际标准，提供开放的数据接口，可以进行数据的转入和传出，实现系统间互连。采用先进成熟的设备和技术，确保系统的技术先进性，保证投资的有效性和延续性； 灵活性与可维护性：系统应易于扩展、升级和移植，并具备支持业务处理的灵活的参数化配置，业务功能的重组与更新的灵活性，新的业务应用可灵活增加，不影响系统原有业务流程。具有灵活的、可进化的数据体系结构，允许任何数据被有序引入，并与原有的数据保持一致和集成； 可扩展性与可伸缩性：具有开放的、可扩展的系统结构，允许系统与其它应用系统集成，新的功能模块可以被迅速增加或定制出来。具有平滑分布和升级、灵活的可伸缩能力，允许将不同的计算任务分布到不同的机器上去，而不妨碍其它部分的运行； 完整性：对整个系统进行统一规划和设计，确保统计应用、数据中心系统和第三方工具紧密集成，共同构成一个达到目标的系统，并且在数据、应用、服务、风格、操作方面，都能够做到一致性和完整性； 安全性与可靠性：提供良好的数据安全可靠性策略，采用多种安全可靠的技术手段，保证系统及数据的安全与可靠； 可用性和容错能力：系统具有安全运行的管理措施，即使在系统遭到非人为破坏，也能够在最短的时间内恢复使用； 准确性与实时性：保证系统数据处理的准确性，提供多种数据审查手段，数据的传输要及时、准确、可靠和安全； 易用性：系统设计面向最终用户，必须保证易操作、易理解、易控制；系统所出现的问题能够及时预报并迅速解决。4.1.2 总体逻辑架构在该总体逻辑架构中，我们根据应用架构的设计，结合IBM整体数据仓库平台方案来满足商业银行的需求。4.1.2.1 源系统层收集和存贮操作数据以对业务现状进行分析。 数据源指存储于各系统中的数据及外部数据，包括：核心系统以及信贷系统、中间业务、国际结算等业务系统。4.1.2.2 ETL层提取/Extract, 转换/Transform 和 装载/Load (ETL) ，ETL层解决跨系统的数据收集与整合。 抽取是指识别最佳的数据源，并从中获得所需的数据。它是将数据导入数据中心的第一步。抽取意味着读取并理解源数据，并复制数据中心所需要的部分。转换泛指使数据中心数据适合于终端使用的过程。这一过程包括那些将源数据格式变为目标数据库格式的模块。一般而言，转换包括映射、清洗、汇总、重排和排序等步骤。从源系统到数据仓库之间的ETL 将需要完成对源数据的清洗和整合，最终在数据仓库中形成企业范围内的统一的、一致的数据集； ETL还包括数据仓库到数据集市的分发。从数据仓库到各数据集市之间的ETL 过程主要是根据不同主题数据集市分析的需要，从数据仓库中提取数据经过转换生成主题特定的数据集。这一部分的处理往往也是最为复杂的。 企业级数据整合策略，或者称之为我们熟悉的ETL，不过这里的ETL是经过扩展的，数据处理的过程和手段更为丰富，整个数据流程的处理更有策略性 数据抽取和转换，后面会介绍到，我们采用信息集成总线的思想来处理数据抽取，这样数据集成收取采用模块化的方式设计，同时又能支持源数据的多样性和异构性，集成总线内最主要的功能CDC用来做实时的数据抽取，联邦可加速数据集成开发的效率和易用性，同时可便捷的实施数据质量相应的管理应用。4.1.2.3 数据仓库层中央数据仓库存储输入的数据和结果数据，数据仓库做为所有分析功能的单一数据源。 数据仓库的数据存储要保持稳定性、灵活性、扩展性。一般的，数据仓库会采用成熟的数据仓库模型进行构建。 数据仓库中的数据按照数据模型分主题进行组织和存放，包括当期的和较长时间的历史数据。数据仓库的核心是企业级数据模型的规划和设计，是所有应用的基础。 数据仓库，数据的核心存储区域，以面向主题的方式，细粒度的保存原子数据，即屏蔽数据源的多样性和变化，又可方便的为BI应用提供数据支持4.1.2.4 ODS（Operational Data Store）操作型数据存储 通过ODS提供单一的主数据管理，比如客户主信息管理、产品主信息管理等等。另外，通过ODS可以完成实时数据仓库要求。对于高价值客户的一些信息，可以通过复制的方式，实时或者近实时地复制到ODS系统中。或者通过ODS完成为其它的系统提供数据源的任务。 ODS，可操作数据存储区域，身兼二职，一方面保持与源系统的业务数据同步以满足一些实时性应用的数据需求，另外作为一个与源系统近似的数据加工区为仓库提供数据加工服务4.1.2.5 数据集市层数据集市的数据为最终的前端分析、报告提供支持 数据集市的数据是面向最终应用的，比如CRM、绩效、反洗钱等等。数据集市的数据基于数据仓库之上进行汇总加工而成。 数据集市设计用途是要满足特定的目的，同时具有查询、分析和报表功能。这与企业数据仓库截然不同，企业数据仓库在信息内容与结构方面要尽可能拥有开放性与灵活性。数据集市有以下特征： 为特定用途而设计数据集市设计的目的，是支持特定用户对数据子集的特定范围的查询。它以用户所要求的方式提供企业数据仓库的细节汇总。 优化数据集市为了支持特定工具的访问而优化。根据工具、根据企业数据仓库提供的信息子集来设计数据集市，而不是让用户直接访问企业数据仓库中的大型数据库，这可以改善数据集市的性能。 虚拟或物理数据集市数据集市可以是物理的实现，也可以是企业数据仓库表的各种视图。使用视图（虚拟数据集市）可以避免存储数据的多个副本，简化了数据管理。 数据集市，在设计得时候往往通过OLAP技术，利用数据仓库的数据根据用户需求建立的多维分析模型（多维立方体），模型以特定的方式存储，大大提高了前端查询访问的效率，用户能方便地实现灵活、动态、快速、多角度、多层次地分析企业数据。同时，也可以通过定制灵活的OLTP查询来了解明细数据。 数据应用集市，数据经过加工和汇总，数据粒度要粗于数据仓库，为前端应用提供数据，相比数据仓库这里一般不会保留细节数据。以集成的方式展示查询、报表、分析的结果 通过搭建灵活的、可扩展技术架构，在保持数据集市稳定性的同时，可以不断增加数据源，增加应用数据层，满足不断增加的业务分析应用需求。 目前有很多业界灵活的报表工具，提供很多预先定义的模版，快速开发，从而把时间更多的放在业务需求定义上。4.1.2.6 数据中心基础管理平台 数据中心的基础，包括元数据、数据质量和数据生命周期管理，这些基础组件贯穿数据仓库整个生命周期，是数据仓库的基石，基于此之上的数据仓库平台的管理应用，使整个仓库系统更好的受控运行。 元数据管理是数据中心建设的一个重要一环。数据中心建设涉及到方方面面：大量的数据源表、数据仓库表、业务需求、数据映射关系、ETL任务、ETL调度等等。一个可实施的、良好的元数据管理构架是数据中心成功的基础。 完整的数据质量管理方案可以确保数据中心数据的准确性。数据质量是数据中心的生命，要保证数据中心的可用性必须保证数中心内的数据质量，建立数据质量问题平台，使数据质量控制过程规则化、具体化。通过数据质量平台做到具体问题具体分析，并跟踪问题直至问题解决。4.1.3 数据中心逻辑架构与产品部署架构在该总体逻辑架构中，我们根据应用架构的设计，以IBM整体数据仓库平台方案满足商业银行的需求。其中，以DataStage为核心来实现数据ETL平台，实现数据分发，处理流转，质量提升，清洗转换等要求。Infomation Server平台作为企业级的ETL平台，专门用于企业级数据中心平台的应用，不仅具有强大的ETL功能，还包括了统一的Metadata元数据平台Metadata Server，数据质量提升的工具等。通过统一的元数据平台Metadata Server对商业银行数据中心项目中的技术元数据和其他元数据进行管理。通过DataStage可以很好的集成商业银行现有的异构的数据源，进行数据的采集。在数据存储层和核心的数据中心平台上，我们建议采用IBM InfoSphere Warehouse数据中心平台构建基础架构，InfoSphere Warehouse数据中心平台中包含了DB2数据仓库引擎，和数据仓库管理开发工具，以及多维分析，数据挖掘等工具，可以满足商业银行在数据平台上的技术要求，并符合长期发展和应用扩展的要求。 利用InforSphere Warehouse，在将来通过该平台不断扩展EDW的功能，并且可以集成现有的ODS平台，实现统一数据管理。在应用服务层，针对本次项目主要为报表应用和多维分析应用，我们建议基于WAS应用服务器平台，使用IBM Cognos作为BI分析展现和报表工具，对应用提供支撑， IBM Congnos BI分析工具，具备了完整了B