智慧银行综合报表平台技术方案

1、智慧银行综合报表平台技术方案 TIME yyyy年M月 2021年1月目 录 TOC o 1-3 h z HYPERLINK l _Toc62145136 第1章项目概述 PAGEREF _Toc62145136 h 5 HYPERLINK l _Toc62145137 1.1项目背景 PAGEREF _Toc62145137 h 5 HYPERLINK l _Toc62145138 1.2项目目标 PAGEREF _Toc62145138 h 6 HYPERLINK l _Toc62145139 1.3项目需求 PAGEREF _Toc62145139 h 7 HYPERLINK l _To

2、c62145140 1.3.1金融数据模型 PAGEREF _Toc62145140 h 7 HYPERLINK l _Toc62145141 1.3.2数据分析及业务应用展现 PAGEREF _Toc62145141 h 7 HYPERLINK l _Toc62145142 第2章技术解决方案 PAGEREF _Toc62145142 h 9 HYPERLINK l _Toc62145143 2.1数据中心整体架构设计 PAGEREF _Toc62145143 h 9 HYPERLINK l _Toc62145144 2.1.1系统设计原则 PAGEREF _Toc62145144 h 9

3、HYPERLINK l _Toc62145145 2.1.2总体逻辑架构 PAGEREF _Toc62145145 h 11 HYPERLINK l _Toc62145146 2.1.3数据中心逻辑架构与产品部署架构 PAGEREF _Toc62145146 h 15 HYPERLINK l _Toc62145147 2.2综合报表平台技术方案 PAGEREF _Toc62145147 h 16 HYPERLINK l _Toc62145148 2.2.1综合报表系统整体功能概述 PAGEREF _Toc62145148 h 16 HYPERLINK l _Toc62145149 2.2.2普

4、通报表的实现 PAGEREF _Toc62145149 h 17 HYPERLINK l _Toc62145150 2.2.3OLAP分析应用的实现 PAGEREF _Toc62145150 h 18 HYPERLINK l _Toc62145151 2.2.4即席查询平台应用的实现 PAGEREF _Toc62145151 h 19 HYPERLINK l _Toc62145152 2.2.5集成到统一展现平台 PAGEREF _Toc62145152 h 20 HYPERLINK l _Toc62145153 2.2.6移动BI PAGEREF _Toc62145153 h 21 HYPE

5、RLINK l _Toc62145154 2.2.7其它技术实现 PAGEREF _Toc62145154 h 24 HYPERLINK l _Toc62145155 2.2.8统一展现 PAGEREF _Toc62145155 h 25 HYPERLINK l _Toc62145156 2.2.9基于门户技术制定统一展现规范并实现报表的集成 PAGEREF _Toc62145156 h 26 HYPERLINK l _Toc62145157 2.2.10制定统一展现规范 PAGEREF _Toc62145157 h 26 HYPERLINK l _Toc62145158 2.2.11需求分析

6、的流程和方法 PAGEREF _Toc62145158 h 27 HYPERLINK l _Toc62145159 2.2.12整体测试方案 PAGEREF _Toc62145159 h 27 HYPERLINK l _Toc62145160 2.3物理架构设计 PAGEREF _Toc62145160 h 29 HYPERLINK l _Toc62145161 2.3.1数据仓库配置方法(BCU) PAGEREF _Toc62145161 h 29 HYPERLINK l _Toc62145162 2.3.2数据量估算 PAGEREF _Toc62145162 h 32 HYPERLINK

7、l _Toc62145163 2.3.3服务器选型 PAGEREF _Toc62145163 h 34 HYPERLINK l _Toc62145164 2.3.4物理部署架构 PAGEREF _Toc62145164 h 34 HYPERLINK l _Toc62145165 2.3.5数据中心系统扩展建议 PAGEREF _Toc62145165 h 35 HYPERLINK l _Toc62145166 第3章产品解决方案 PAGEREF _Toc62145166 h 37 HYPERLINK l _Toc62145167 3.1软件配置列表 PAGEREF _Toc62145167 h

8、 37 HYPERLINK l _Toc62145168 3.2产品介绍 PAGEREF _Toc62145168 h 37 HYPERLINK l _Toc62145169 3.2.1InfoSphere Warehouse产品 PAGEREF _Toc62145169 h 37 HYPERLINK l _Toc62145170 3.2.2ETL 集成工具IBM Information Server PAGEREF _Toc62145170 h 49 HYPERLINK l _Toc62145171 3.2.3BI分析和报表工具Cognos PAGEREF _Toc62145171 h 67

9、 HYPERLINK l _Toc62145172 第4章项目实施方案 PAGEREF _Toc62145172 h 105 HYPERLINK l _Toc62145173 4.1项目进度计划 PAGEREF _Toc62145173 h 105 HYPERLINK l _Toc62145174 4.1.1项目一期进度计划 PAGEREF _Toc62145174 h 105 HYPERLINK l _Toc62145175 4.1.2项目阶段的工作内容及提交成果 PAGEREF _Toc62145175 h 106 HYPERLINK l _Toc62145176 4.2项目培训 PAGE

10、REF _Toc62145176 h 106 HYPERLINK l _Toc62145177 4.3项目组织构架 PAGEREF _Toc62145177 h 107 HYPERLINK l _Toc62145178 4.3.1项目组织架构 PAGEREF _Toc62145178 h 107 HYPERLINK l _Toc62145179 4.4项目沟通计划 PAGEREF _Toc62145179 h 110 HYPERLINK l _Toc62145180 4.4.1每周项目例会 PAGEREF _Toc62145180 h 110 HYPERLINK l _Toc62145181

11、4.4.2项目进展汇报（会） PAGEREF _Toc62145181 h 110 HYPERLINK l _Toc62145182 4.4.3问题处理流程 PAGEREF _Toc62145182 h 111 HYPERLINK l _Toc62145183 4.5质量管理计划 PAGEREF _Toc62145183 h 112 HYPERLINK l _Toc62145184 4.5.1目的 PAGEREF _Toc62145184 h 112 HYPERLINK l _Toc62145185 4.5.2范围 PAGEREF _Toc62145185 h 112 HYPERLINK l

12、_Toc62145186 4.5.3质量保证组织 PAGEREF _Toc62145186 h 112 HYPERLINK l _Toc62145187 4.5.4质量控制过程 PAGEREF _Toc62145187 h 112 HYPERLINK l _Toc62145188 4.6风险管理计划和控制 PAGEREF _Toc62145188 h 113 HYPERLINK l _Toc62145189 第5章整体解决方案的优势和特点 PAGEREF _Toc62145189 h 115 HYPERLINK l _Toc62145190 5.1.1丰富的实施经验 PAGEREF _Toc6

13、2145190 h 115 HYPERLINK l _Toc62145191 5.1.2高性能 PAGEREF _Toc62145191 h 118 HYPERLINK l _Toc62145192 5.1.3可扩展性 PAGEREF _Toc62145192 h 120 HYPERLINK l _Toc62145193 5.1.4开放性 PAGEREF _Toc62145193 h 121 HYPERLINK l _Toc62145194 5.1.5系统可靠性 PAGEREF _Toc62145194 h 122 HYPERLINK l _Toc62145195 5.1.6数据安全 PAGE

14、REF _Toc62145195 h 123 HYPERLINK l _Toc62145196 第6章成功案例 PAGEREF _Toc62145196 h 125 HYPERLINK l _Toc62145197 6.1国内银行成功案例列表 PAGEREF _Toc62145197 h 125 HYPERLINK l _Toc62145198 6.2近期实施的案例列表 PAGEREF _Toc62145198 h 126 HYPERLINK l _Toc62145199 6.3实施案例介绍 PAGEREF _Toc62145199 h 127 HYPERLINK l _Toc62145200

15、 6.3.1浙商银行企业数据仓库项目 PAGEREF _Toc62145200 h 127 HYPERLINK l _Toc62145201 6.3.2齐鲁银行企业级数据仓库 PAGEREF _Toc62145201 h 129 HYPERLINK l _Toc62145202 6.3.3龙江银行数据仓库项目 PAGEREF _Toc62145202 h 129 HYPERLINK l _Toc62145203 6.3.4上海银行企业信息架构咨询项目 PAGEREF _Toc62145203 h 130 HYPERLINK l _Toc62145204 附录1 交付品清单 PAGEREF _T

16、oc62145204 h 131 HYPERLINK l _Toc62145205 附录2 培训建议书 PAGEREF _Toc62145205 h 132 HYPERLINK l _Toc62145206 附录3 建议的硬件配置 PAGEREF _Toc62145206 h 134项目概述项目背景目前，银行已经建立了可以覆盖全省的网络中心，1个营业部33个机构网点主要分布在德阳市、成都市、广汉市、什邡市、绵竹市、罗江县、中江县。并且，随着业务的发展，行内已拥有28个业务系统，目前有28个业务系统：信贷系统、核心系统（改造中）、财务系统、中间业务、大额支付、小额支付、银联前置、微贷系统、网上银

17、行系统、ATM&POS&CC、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像、财税库银、身份核查、柜面通、城商行清算中心、电子回单柜系统、同城票据交换、银医联名卡系统、理财业务系统、渠道平台。 业务系统现状核心系统目前正在改造，综合报表系统（包含1104报表、人行支付报表、反洗钱报表、行内监管报表）待建。信息技术部针对目前应用系统对业务系统的数据使用情况出台了一套数据使用标准、规范，目前还没有进入到具体实施阶段。 数据使用现状目前行内所使用的各种应用和来源数据之间交叉成网状。 众多业务系统的建立使我行的业务在准确性、实时性上得到

18、了极大的提高，同时也降低了业务人员的办公出错概率。虽然，电子化系统能极大的提高业务效率，但是，随着电子化系统的不断增多，其存在的缺点也逐渐的暴露出来：数据孤岛，使得各业务系统之间数据共享困难。不同业务系统的相同指标数据有可能不一致，使得系统之间的衔接困难，不能满足后续应用系统的快速构建的需要。大量数据冗余。为满足多个应用系统，需要同时对多个源系统进行频繁数据采集，且每个应用系统都会向源系统采数，效率不高，对源系统的压力较大。不能满足后续应用系统快速构建的需要。 每个系统的开发商不同，其数据模型和标准也不同，数据的可用程度降低。 这些缺点，降低了行内数据的数据抽取、数据转换、数据整合、数据加载、

19、数据归档、数据监控调度等，影响了相关部门对数据的管理分析。项目目标数据中心应用平台项目的目标是：解决目前我行各业务系统数据间存在的数据孤岛、数据冗余、数据标准化的问题。整合所有的业务系统（不仅包括我行现有的系统，还需要考虑到我行以后将要建设的系统）源数据准确完整地分析我行现有的数据及其流向，为各个业务部门的管理分析提供统一而且完整的数据支持（如数据抽取、数据转换、数据整合、数据加载、数据归档、数据监控调度等）为今后各个面向主题的分析型应用系统的开发建设提供数据基础和技术基础。通过实现统一数据视图和数据的服务和共享，提高银行企业管理电子化水平。符合银监会银行监管统计数据质量管理良好标准的相关要求

20、，并配合人行金融统计标准化试点工作的建设。项目需求项目要完成以下功能需求：金融数据模型建立高度抽象、实用的数据中心模型：数据中心项目对数据模型要求较高，数据模型的合理与否将关系到项目的成败，因此必须选择先进合理的建模理念，紧密契合已有业务系统，深刻了解银行业务和核心系统，建立高度抽象、实用的数据中心模型。建立适合银行的指标库体系。数据中心模型的建立应充分考虑下列应用（但不限于）对数据的使用：综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内报表）行长决策系统（领导驾驶舱）财务管

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

22、时作出调整，一旦业务需求发生改变，用户可以通过对元数据的维护使系统的运行作出快速的响应。数据质量管理建立有效的、可视化的数据质量管理平台，能够通过建立检验规则，对源数据质量进行持续监测，并自动生成数据质量管理报告；能够实现可视化的数据追溯展示，清晰展示数据指标与源数据之间的逻辑关系。技术解决方案数据中心整体架构设计数据中心应用平台的数据沉淀和分析功能的开发伴随着银行的成长甚至转型，所以平台需要具备足够的稳定性，以应对源系统和外部分析需求的不断变化。因为源系统改造或者重建，而导致数据仓库重建往往会引起数据仓库项目的失败。从整体上数据仓库的架构具备足够的稳定性，能够适应数据源的不断变化。数据中心的

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

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

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

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

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

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

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

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

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

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

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

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

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

36、次项目主要为报表应用和多维分析应用，我们建议基于WAS应用服务器平台，使用IBM Cognos作为BI分析展现和报表工具，对应用提供支撑， IBM Congnos BI分析工具，具备了完整了BI分析，报表功能，还具有绩效考核，财务分析等扩展能力。WAS应用服务器平台符合银行整体应用的规划和现有的环境，便于以后的扩展，满足大用户量的访问要求。以上是本次数据中心项目整体逻辑架构的产品映射图，对应了应用架构中各个层次的产品支撑。综合报表平台技术方案我们采用Cognos产品作为综合报表系统的核心技术。如数据仓库整体架构图所示，业务系统数据在进入数据仓库系统后，已经经过了数据质量、整合等处理，所以综合报

37、表平台是在数据仓库平台的基础上进行面向报表的数据再加工工作，在数据二次加工得基础上完成报表的生成、展现等。综合报表系统整体功能概述报表定制：支持Excel模板的报表格式定制。支持各种类型的复杂报表，包括不规则报表、不平衡报表、不对称报表、汇总报表、清单报表等各种格式。满足各种复杂格式的内部管理报表的需求；报表发布和分发：提供统一的报表发布、分发功能；报表打印：支持所见即所得的报表打印，支持套打；数据获取：支持从表内取数和从表间取数；支持报表数据二次计算、支持Excel公式；扩展指标：在报表中，能基于已有的指标定义新的计算指标；数据校验：实现表内及表间的数据勾稽关系、平衡校验功能，保证报表数据的

38、准确性；数据汇总：提供报表数据的逐级汇总、支持多种汇总关系；数据审核：支持对报表数据进行审核，多层次的数据确认和数据质量的保证；权限机制：多级别（按组织机构级别、按业务范围）的用户权限控制，不同的权限能够使用不同的功能、数据和报表。强大的语义层功能：动态地从各种数据源中读取其元数据。通过自动的分布式刷新，向所有用户发布共享库的变化，并同步化他们对数据库的视图；满足业务人员自助式的、零编程的、快速的定制查询；灵活的排序、过滤、分组、计算等功能；自助式查询：满足业务人员灵活的、自助式的业务分析、信息发布；查询复用：支持查询模板的复用，即可以基于已有的查询，构建新的查询；支持查询审核：由审核人员对查

39、询的执行效率和安全性进行审批，避免不恰当的查询导致系统资源耗尽甚至崩溃；支持关联跳转分析：从某个报表/查询上选择一个单元格，据此为条件跳转到另一个相关联的报表/查询；丰富的图表功能：包括直方图、饼图、趋势图、点图、区域图等；多种信息输出：表格、图形输出到Excel、HTML、Text所见及所得；普通报表的实现我们将通过COGNOS 中的Report Studio的模块完成企业报表的功能。COGNOS中报表可以连接关系型数据库，也可以连接COGNOS Cube.通过连接Cube能够高效的实现各种统计汇总型报表，通过连接关系型数据库，能够实现明细查询报表。同时支持报表之间的交叉穿透钻取。COGNO

40、S在报表灵活性和报表开发易用性等方面具有突出的优势，其报表通过编写代码自动生成，也可以通过图形界面下的鼠标拖拽操作来直观的完成的，无须编写任何脚本或者代码，即可实现复杂格式的报表（特别是不平衡报表），如下图所示：根据银行需求，我们将采用T+1的方式，在每晚数据仓库日终批处理结束后，再采用批量的方式自动生成银行的T+1报表。OLAP分析应用的实现本次项目，我们将根据需求，交付OLAP主题分析。在COGNOS解决方案中，OLAP分析应用由COGNOS Analysis模块来提供。它能够实现在海量数据、海量并发用户访问情况下依然能够保持秒级的响应速度，并具有远远超越其他前端应用解决方案的界面易用性，

41、用户在纯Web方式下，无须安装任何插件，即可实现鼠标拖拽式的OLAP操作。COGNOS 提供丰富的图表展现，支持图表混合和联动，用户可以直接在图形上进行数据钻取操作。COGNOS OLAP解决方案提供对全景数据视图的支持，通过穿透钻取（Drill-through）功能，COGNOS用户可以从OLAP分析穿透到细节数据报表中，或者在多个OLAP主题之间跨越，实现多视角、多层次的数据探查。在系统中通过OLAP 分析，可以对各种口径（如机构、科目、时间、客户等）进行收入、费用等各种指标数据的归集与分析。用户可以在纯浏览器中通过鼠标拖拽等方式，方便得进行上钻，下钻，切片，旋转等操作，对相关数据进行多角

42、度，多层次，多指标的探查，为战略决策提供支持。 即席查询平台应用的实现我们采用COGNOS Reporting的Query Studio模块来实现即席查询功能。COGNOS具有灵活易用的条件定义界面，并能将查询结果转存为PDF、Excel等多种文件或进行直接打印输出；允许设定报表的查询优先级和用户的查询优先级，优先级高的查询优先处理，保证关键查询的结果生成速度。支持数据的分页显示，支持包括全部数据查询，采样数据查询，以及模拟数据查询多极查询模式。在综合报表平台中，通过COGNOS数据查询功能，用户可以灵活的查询数据的中明细信息，包括财务基本情况，可以进行自助式的查询，自己挑选想看的字段和想要进

43、行的过滤，自己将查询结果进行加工计算、图形展示等处理。集成到统一展现平台门户系统可以将后台分散的应用和信息在用户界面层次上整合到一起，提供统一的安全性认证方式，虽然整个系统从后台上看仍然是分离的模块分别处理各自的任务，实现各自的功能，但是从用户角度来看，门户提供了整体的应用环境，集成了功能与信息，使用户得到一个统一的入口。Cognos技术方案中内置了门户系统，一个系统简洁轻量、便于定制，能方便的内嵌多种形式的第三方应用，并提供开放式的内容管理的门户。Cognos技术方案的门户系统能与安全性系统或第三方安全性系统紧密结合，并承载大并发用户数的访问。同时Cognos门户采用Portlet技术，可以

44、和任意的门户系统实现双向的集成。在本次项目中，我们将根据银行要求，将展现集成到统一展现平台中。移动BI我们可以借助IBM Cognos Mobile技术实现领导驾驶舱和综合报表平台报表的移动展现，IBM Cognos Mobile的特点如下：增强的用户界面:不同设备和应用，相同的风格和功能:加强操作交互 钻取、提示、导航新的流行的交互操作方式一次开发，在不同的应用中使用新的交互式可快速响应的静态报表类型.快速的交互式的仪表盘可以保存为MHT 应用，允许离线使用可调度和分发给广泛的各种类型的用户IBM提供了一个名为IBM Cognos Mobile的IPAD应用程序组件，用于在IPAD上查看报表

45、，可查看的报表包括Report Studio创建的各类报表，在App Store上搜索“IBM Cognos Mobile”，并选择下载安装IBM Cognos Mobile欢迎界面，含用户登陆和注销功能我的Ipad上的报表，列出报表查看历史，可迅速导航到常查看的报表，也可对其管理获取更多报表，登陆到 IBM Cognos Connection查看服务器上的报表，系统自动将查看过的报表保存到本地三种方式可刷新离线报表数据IPad连接Cognos Connection网络，并通过“重新运行报表”选项从服务器上重新生成MHT文件将Active Report生成mht文档保存，通过Itunes将mh

46、t文档导入Ipad将Active Report生成mht文档保存，并通过作为邮件附件导入IPad查看报表时可对报表中的重点关注部份作批注，并将当前查看的报表以图片的形式用邮件发送出去其它技术实现我们的技术方案中，根据需求，还可以提供仪表盘展现、以及Cognos报表和仪表盘在手机等移动设备上的展现。详细信息，请参见： HYPERLINK l _BI分析和报表工具Cognos BI分析和报表工具Cognos。另外在在实际的数据源系统中，可能存在部分特殊的报表需求，但无法从数据源采集到的数据、信息，这部分信息存储在业务人员自己的Excel等文件中，数据中心平台提供数据补充采集功能：补充采集的数据，可

47、以通过手工单条录入，也可以通过一定的数据格式，例如：Excel，批量导入数据中心；对于补录的数据，业务人员提供数据的格式和样本数据用于需求分析数据补录受操作权限和数据权限的控制，业务人员只能补充录入自己业务管辖范围内的业务数据补录数据的内容，格式，需求和报表展现样式需要通过专门的审批流程批准，按照标准的模板形成统一的补录需求，再批准后由统一报表平台统一处理统一展现IBM规划的统一展现平台可以具备以下基础功能：个性化界面风格定制门户系统中提供门户管理员对界面风格的定制工具，实时调整某一风格中的重点元素，同时应定制一定数据量的风格组件，普通用户选择不同的页面风格，或调整portlet的布局。门户系

48、统将提供个性化定制功能，系统允许每个用户能够拥有一个或多个个性化BI页面，并可从BI主页上导航到每个BI页面。每个BI页面可以有自己的页面风格和页面布局的选项。页面风格中，用户可以定义字体、颜色、间距及其他直观元素。组件的管理和维护门户系统的组件主要是portlet，门户系统还提供portlet的管理界面，完成新建portlet的部署、配置、应用、权限管理等功能。门户提供开放式的技术平台，作为BI的管理、报表展示、权限管理的接入服务基础平台。虚拟门户管理门户系统提供系统设置界面，使系统管理员通过一定的设置，使用不同界面风格和技术操作，简单地安装门户服务器即可提供支持许多虚拟门户，充分复用现有投

49、资的软硬件资源，同时有可以有相对独立的门户展示空间，包含IT支撑基础平台。单点登陆功能调整和规范门户的单点登录功能，使之成为IT的基础平台，并实现BI的各功能模块和门户之间的单点登录。性能监控和站点分析门户系统提供访问量、资源使用及各种应用组件的监控工具，提供详细的运行日志，方便系统管理员对系统进行维护，系统管理员将通过监控和日志对门户应用组件做适当的调整。基于门户技术制定统一展现规范并实现报表的集成银行统一报表平台将充分利用目前门户和UE技术来打造统一的展现平台：在Portal上开发功能树模块，作为可定制的栏目，由管理员或用户放置到指定的水平门户、垂直门户或工作平台上专门为BI业务建设单独的

50、门户站点，提供以BI业务为中心的子门户，提供独立的门户和业务管理员，通过门户的远程Portlet共享技术，授权其他子门户访问，并将BI系统中不同的展示模块授权给有需要的用户，并可以添加到个人工作平台上定制行领导专门的页面，并部署有关BI页面模块充分利用现有的用户管理和安全平台，包含用户管理、授权、单点登录、用户验证平台。进一步调整现有的门户平台架构，制定门户平台建设规范通过IBM用户体验方法论，建设符合银行特点和特色的展现风格、交互风格等交互界面制定统一展现规范IBM UE(User Experience)方法论：基于IBM UE的统一用户界面规范用户在服务过程中的用户体验至关重要。根据马斯洛

51、需求层次理论，人的需求是多层次的，功能满足只是用户的最基本需求，用户体验则是满足功能基础上的更高层次的需求。当前，大部分门户网站虽然都能够在功能上满足用户需求，但用户体验都有待于提高。这里的用户体验包括用户个性化的服务，是否能够方便的找到自己熟悉的服务，在访问过程中的是否有各种相关信息的支持等等。用户体验可以通过下列优化方式，提升用户体验：项目中引入专业的用户体验分析和设计，对用户体验的策略、品牌、信息架构、视觉策略进行分析和设计。个性化的用户体验，充分考虑不同细分用户的体验需求。个性化的体验，不同用户可以根据自己的喜好，定制自己的个性化需求，当用户重新登录时，用户看到熟悉的服务，熟悉的页面。

52、还提供多窗口服务，良好导航，门户及业务服务整合，良好的互动，简单易用的操作流程等。需求分析的流程和方法项目组采取以下流程和方法进行需求分析：整体测试方案项目组将在单元测试和系统集成测试阶段综合采用回归测试和压力测试两种方式进行测试。回归测试在程序代码发生变化后，重新进行测试以确认修改没有引入新的错误或者导致其他代码产生错误，根据软件开发的基线作为基准，维护测试用例库。删除过时的测试用例：删除不再适合基线的用例库，如某功能被删除改进不受控制的测试用例：有一些测试用例对输入或运行状态十分敏感，这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。删除冗

53、余的测试用例：删除针对一组相同的输入和输出进行测试的测试用例。增添新的测试用例：对于新增加的功能模块或者以前未测试的程序段，开发新的测试用例选择回归测试包若测试用例较少，可选择所有的测试用例作为回归测试包进行重复测试若测试用例非常多，则可基于风险选择测试包运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例可最大限度的测试到系统存在的严重缺陷若测试用例非常多，也可基于操作剖面选择测试包优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障回归测试方案压力测试推荐采用LoadRunner模拟多用户并

54、发进行压力测试，模拟上千用户实施并发负载及实时性能监测的方式来确认和查找问题，可分析及监视场景如下：内存相关处理器相关网络吞吐量及带宽磁盘相关Web应用相关数据库相关网络延迟物理架构设计数据仓库配置方法(BCU)多分区数据库技术IBM INFOSPHERE WAREHOUSE的多分区数据库技术，使得IBM DB2在联机分析系统的应用中处于领先的地位，为数据仓库的建设提供了最强有力的技术保障。IBM INFOSPHERE WAREHOUSE的多分区数据库技术采用独特的非共享体系架构（Share Nothing），一个物理数据库被分成多个分区，每个分区可以看成是一个逻辑的数据库分区。每个数据库分区

55、运行在各自的节点上，同时各个分区拥有自己独立的资源，如CPU，内存，磁盘，引擎，核心进程，锁机制等，有一个被称为“协调节点”的数据库分区负责协调所有逻辑数据库分区之间的通信工作，所有数据库分区对协调节点传递的应用进行并发处理，然后通过快速通信机制（FCM）将处理结果返回。这样的架构下，IBM INFOSPHERE WAREHOUSE能够将一个超大规模的数据访问拆分为若干个小的处理单元并行处理，最大限度的发挥硬件资源的作用，提高数据库处理的响应时间，而整个多分区数据库系统对于用户来说又是透明的，从用户和应用的角度来看是一个单一的数据库系统。如下图所示：平衡配置单元（BCU）有了上述介绍的多分区数

56、据库技术，结合多年数据仓库项目中积累的经验，IBM向客户推荐采用平衡配置单元(Balanced Configuration Unit - BCU)这一系统架构。IBM 数据仓库平衡配置单元（BCU）是一个基于IBM DB2、IBM pServer、IBM Totalstorage的能够给予客户最大的性能和最大的可扩展性的一套完整的数据仓库平台解决方案，该方案以多分区数据库技术作为基础，以平衡作为数据仓库平台的创建原则，以大量的最佳实践作为前提，以多伦多实验室为支持中心，力争能够有效的减少客户在规划、实施、集成等方面的风险和复杂度，为数据仓库的成功提供最基础的平台保障。BCU的架构图如下：在上图

57、中，每个BCU是一个物理节点，该节点既可以是一个单独的pServer，也可以是一个Lpar；即支持UNIX平台，又支持LINUX平台，在规划、部署和实施方面具有很大的灵活性。每个数据仓库平台的BCU数量不是固定的，是可以根据用户的数据量、处理复杂度来定制的，既可以是一个BCU构成一个数据仓库，又可以是多个BCU共同构成一个数据仓库。但是为了体现“平衡”这个原则，要求构成数据仓库平台的每个BCU的配置必须是一致的，包括CPU，内存，磁盘，光纤卡、网卡等。每个BCU内可以配置若干个逻辑数据库分区，每个数据库分区叫做一个BPU。通常我们CPU和BPU的比率是1：1，如果CPU负载过大，可以考虑增大比

58、率，如2：1。数据仓库中的数据通过特定的HASH算法均匀的分布到每个BPU上，然后针对每个查询，数据仓库都会调度所有的BPU进行并行计算，以最快的速度返回结果。按照这样一个设计思路（BCU）建设的数据仓库平台是实施IBM BI解决方案的一个重要的组成部分，具有如下的优势：可信赖的实施的方法是经过IBM实验室和国内外多家大客户测试通过的。系统的性能是经过IBM实验室和国内外多家大客户验证通过的。实施过程是严谨的和快速的。平台基于稳定的IBM Pserver、IBM DB2和IBM Storage而搭建，因此系统的稳定可以得到保障。仅在中国就有包括电信、移动、银行等几十家企业已经或正在实施基于BC

59、U的数据仓库，其中不乏超过100TB级别以上的客户。因此是低风险的。高可用性的BCU方案推荐的硬件采用IBM P系列服务器和IBM 的存储，该服务器和存储设备在硬件配置上已经实现了最大程度的“冗余”处理，在物理层面上避免了单点故障。基于IBM BCU的数据仓库同样支持HACMP，能够在系统出现异常或者硬件故障的时候进行自动的切换接管，而在正常情况下，数据仓库平台又可以提供双工工作。低成本的快速、高效的实施大大缩短项目的周期，从而带来快速的投资回报。扩容是基于已知的配置单元进行的，因此是成本可预知并可控制的。均衡的性能按照HASH算法，数据均匀的分布在预先指定的数据库分区。每个分区具有独立的，相

60、同的CPU、内存和磁盘配置。最大的灵活性可以根据不同的应用将BPU建立不同的逻辑组，组之间无依赖关系。可以根据应用的实际运行状况动态的调整逻辑组之间的BPU配置，从而实现硬件资源的动态分配。平台的高可扩展性BCU理论基础上创建的数据仓库平台系统具有很强的可扩展性，这个可扩展性主要体现在系统容量的增减和系统资源的配置调整方面。众所周知，数据仓库作为一个企业的核心数据平台，需要保持大量的历史数据，少则5年，多则10年。随着时间的推移，数据仓库的数据量会不断的增长，对硬件空间和硬件处理能力的要求也不断的增加。无论从发展的角度、成本的角度考虑，还是从最佳实践的角度来考虑，规划一个能够满足3-5年的初始