中国移动省级增值业务综合运营平台技术规范V1.0.0.doc

中国移动通信企业标准QB-Y-061-2010中国移动省级增值业务综合运营平台技术规范The Technical Specification of Value-added Service General Operation Platform版本号：1.0.02010-12-7实施2010-12-7发布中国移动通信集团公司 发布目录1.范围12.规范性引用文件13.术语、定义和缩略语14.总体说明34.1.建设背景34.2.建设目标44.2.1.业务目标44.2.2.技术目标44.3.建设原则55.系统架构55.1.逻辑架构55.2.功能架构65.3.技术架构95.4.系统边界105.4.1.与一级VGOP的边界115.4.2.与二三类业务平台的边界125.4.3.与省级经营分析系统的边界125.4.4.与省级CRM/BOSS的边界125.4.5.与省级BOMC的边界136.关键技术136.1.与数据集市数据库合设136.1.1.逻辑架构136.1.2.合设方案146.2.能力集成246.2.1.界面集成256.2.2.流程集成296.2.3.服务集成316.2.4.数据集成336.3.运营管理346.3.1.逻辑架构346.3.2.数据处理机制366.3.3.技术要求376.3.4.技术指标386.4.营销服务支撑396.4.1.逻辑架构396.4.2.数据处理机制406.4.3.技术要求416.4.4.技术指标457.典型系统流程457.1.营销服务支撑流程458.系统接口478.1.总体视图478.1.1.两级VGOP接口视图478.1.2.省级VGOP接口视图488.2.接口技术原则488.2.1.接口技术分类488.2.2.接口技术通用要求498.3.两级VGOP间的接口类498.4.省级VGOP与二三类业务平台间的接口类508.5.省级VGOP与省级经营分析系统间的接口518.6.省级VGOP与省级CRM/BOSS间的接口类518.7.省级VGOP与省级BOMC之间的接口类529.系统技术要求529.1.部署要求529.2.业务连续性要求539.3.数据一致性管理569.4.运维要求589.4.1.安全性589.4.2.可管理性599.4.3.可维护性599.4.4.易用性599.5.网管要求609.5.1.性能信息609.5.2.故障信息609.5.3.配置管理数据609.6.系统平台指标619.6.1.主机系统619.6.2.门户性能619.6.3.存储和备份619.6.4.共享数据存储周期6210.编制历史62前言本规范主要用于指导省级增值业务综合运营平台的工程建设。本规范主要包括以下几方面内容：总体说明、系统架构、关键技术、典型业务流程、系统接口、系统技术要求。本标准是中国移动NG2-BASS（v3.0）系列标准之一。该系列标准的结构、名称或预计的名称如下：序号标准编号标准名称1QB-Y-052-2010中国移动省级NG2-BASS(v3.0)业务规范2QB-Y-053-2010中国移动省级NG2-BASS(v3.0)技术规范总册3QB-Y-054-2010中国移动省级NG2-BASS(v3.0)技术规范数据集市分册4QB-Y-055-2010中国移动省级NG2-BASS(v3.0)技术规范逻辑模型分册5QB-Y-056-2010中国移动省级NG2-BASS(v3.0)技术规范外部接口分册6QB-Y-057-2010中国移动省级NG2-BASS(v3.0)技术规范元数据管理分册7QB-Y-058-2010中国移动省级NG2-BASS(v3.0)技术规范数据质量管理子系统分册8QB-Y-059-2010中国移动省级NG2-BASS(v3.0)技术规范多OP能力交互分册9QB-Y-060-2010中国移动省级增值业务综合运营平台业务规范10QB-Y-061-2010中国移动省级增值业务综合运营平台技术规范11QB-Y-062-2010中国移动省级增值业务综合运营平台技术规范-数据管理分册12QB-Y-063-2010中国移动省级增值业务综合运营平台接口规范本标准由中移技2010269号印发。本标准由中国移动通信集团公司业务支撑系统部提出，集团公司技术部归口。本规范起草单位：中国移动通信集团公司业务支撑系统部、数据部、研究院。本规范主要起草人：姜恒、张帆、杜菲、史达、徐晗、武俊、朱振宇、宋航、孟锐1. 范围本标准规定了省级增值业务综合运营平台（以下简称省级VGOP）的系统架构、关键技术、典型系统流程、系统接口和系统技术要求，供中国移动内部和厂商共同使用；适用于省级增值业务综合运营平台的建设。2. 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。1增值业务综合运营平台技术规范省级平台分册(正式稿v1.2)中国移动通信集团公司2增值业务综合运营平台接口规范省级平台分册(正式稿v1.2)中国移动通信集团公司3增值业务综合运营平台业务规范省级平台分册V1.0.0中国移动通信集团公司4QB-Y-003-2009增值业务综合运营平台技术规范一级平台分册(正式稿v1.2)中国移动通信集团公司5QB-Y-053-2010中国移动省级NG1-BASS（v3.0）技术规范总册中国移动通信集团公司6集团客户业务综合运营平台技术规范(v1.0)中国移动通信集团公司7集团客户业务综合运营平台业务规范(v1.0)中国移动通信集团公司3. 术语、定义和缩略语下列术语、定义适用于本标准：字母名词解释F服务集成服务集成是通过对外部系统的业务逻辑服务进行抽象、封装、组合、调用，从而实现对外部系统应用能力的集成G工作台工作台是系统使用者进行业务运营所需的各种功能操作和信息获取的系统界面J界面集成界面集成是通过集成外部系统的用户界面，建立一个跨系统、跨应用、统一、集成的业务操作与管理工作台 J接触渠道客户通过热线、服务厅或者其他方式接触运营商，进行业务办理或业务咨询等业务操作的渠道L流程集成流程集成是通过集中的业务流程管理引擎，来管理各类跨系统的业务流程，统一调度外部系统中的服务，实现跨系统的长流程N能力能力是指由资源提供，用以实现业务接入、信息交换或业务运营的功能抽象S数据集成数据集成是通过获取外部系统的业务数据或分析数据，实现系统内功能需求、应用需求和展现需求的数据支撑，完成数据在系统中的集成、运算及结果展现Y业务业务是一种由电信运营商或由合作伙伴或由二者共同提供的服务，可对客户产生价值。业务被包装成产品后向客户销售Y业务能力是指能够完成某种业务活动的功能和技术特性，有时多种业务能力有机结合才能顺利完成某项业务活动Y业务平台业务平台是指为了实现某种业务能力而建设的系统Z执行渠道客户通过接触渠道对运营商提出服务请求后，负责跟进客户并为客户提供服务的渠道下列缩略语适用于本标准：缩写英文描述中文描述VGOPValue-added Service General Operation Platform增值业务综合运营平台BASSBusiness Analysis Support System经营分析系统BOMCBusiness Operation Management Center业务支撑网管理系统BOSSBusiness Operation Support System业务运营支撑系统CRMCustomer Relationship Management客户关系管理ESOPEnterprise Service Operation Platform集团客户业务综合运营平台ETLExtraction, Transformation,Loading抽取、转换和加载（数据获取过程）FTPFile Transfer Protocol文件传输协议HTTPHypertext Transfer Protocol超文本传输协议IMEIInternational Mobile Equipment Identity国际移动设备身份码KPIKey Performance Indicator关键绩效指标OLAPOn-line Analysis Process在线分析处理URLUniform / Universal Resource Locator统一资源定位符WAPWireless Application Protocol无线应用协议XMLExtensible Markup Language可扩展标记语言4. 总体说明4.1. 建设背景省级VGOP建设的需求驱动源于企业运营模式转变的内在驱动和市场竞争的外在驱动。企业内部运营模式转变的驱动主要源于剥离业务平台共性的运营功能，减少重复建设，整合分散的关键数据，实现跨业务平台的综合运营的要求；市场竞争的外在驱动源于业务竞争模式从以业务为中心过渡到以客户为中心，多业务平台适度整合的要求。省级VGOP建设的规划驱动源于企业的“移动信息专家”转型战略，在该战略的指引下，中国移动通过总结已有的业务平台的建设和运营经验和对未来业务实现模式与运营模式的前瞻性研究，通过综合运营平台带来的架构调整推动增值业务平台的规范化建设，从流程，功能，数据，接口四个方面全方位推动增值业务从孤立走向整合，实现业务系统运营的规范化和水平化，加强增值业务以客户为中心的竞争力，沉淀业务综合运营的“软实力”。需求驱动是从短期增值业务实现目标出发，关注业务需求的具体实现，本期体现在本规范提出的两大核心能力：业务运营能力、业务管理能力。规划驱动是从中国移动战略转型的长期目标出发，关注国际上最新的增值业务体系架构研究，并通过对增值业务实际运营情况的持续调研和深入总结，实现业务综合运营模式和支撑手段的不断提升。两种驱动模式的关注点各有不同，通过需求驱动、规划驱动的双重驱动实现优势互补，确保系统在保持稳定、高效支撑的前提下，实现增值业务运营能力的有序提高和健康发展，提升增值业务在公司整体发展的贡献度，快速高效地满足灵活多变的客户需求。为了更好的指导省公司进行省级VGOP建设，本规范中根据12个试点省公司VGOP成功建设经验，遵循业务支撑网融合支撑的演进思路，统筹规划省级VGOP与传统支撑系统的功能定位，以保证系统长期、持续、健康发展。4.2. 建设目标4.2.1. 业务目标省级VGOP的业务目标包括以下两个方面：1. 提升业务管理能力l 加强一类业务和二三类业务的接入和管理；l 通过两级VGOP互动，提升业务管理能力。2. 提升业务运营能力l 增强与各类业务平台的互动，并向各类业务平台开放省级VGOP的能力，支持业务平台提升业务运营能力；l 提供对自有增值业务的闭环营销服务支撑；l 沉淀运营知识，实现运营经验共享。4.2.2. 技术目标省级VGOP的建设，需要遵循开放性、稳定性、灵活性的要求，实现系统基础架构与基本业务功能要求，其技术目标主要体现在以下三个方面：1. 构建统一接入操作门户，优化系统交互能力，提升客户感知度l 从综合运营与管理的视角出发，基于Portal、iFrame等技术，为业务与管理人员提供满足“统一工作界面、基于角色展现”要求的统一操作门户；l 以用户体验为中心，优化系统交互能力，在充分整合功能和信息的基础上，建立一致性、规范性和兼容性良好的界面框架和展示风格，实现系统美观、易用和操作人性化。2. 支持多样的跨系统集成能力l 支持将外部系统中的功能，通过界面集成、流程集成、服务集成、数据集成的方式进行集成，形成省级VGOP所需要的业务支撑能力，达到及时响应、快速部署、灵活展现的目的；l 在业务能力整合的基础上，提供基于统一工作流引擎的、面向业务流程的、可视化的业务流程管理机制。3. 向外部系统开放省级VGOP的能力，实现外部系统对省级VGOP能力的集成。4.3. 建设原则在满足业务部门需求的基础上，充分整合、利用业务支撑网现有支撑资源，避免重复投资造成浪费。基于低成本、高效能的系统运营目标，省级VGOP的建设原则如下：1. 与省级经营分析系统数据集市合设数据库。2. 集成外部系统提供的能力，形成省级VGOP所需要的业务支撑能力l 外部系统已有的、能完全满足省级VGOP需要的功能，可通过界面集成、流程集成、服务集成、数据集成的集成方式进行功能集成；l 外部系统已有的、但不能完全满足省级VGOP需要的功能，首先考虑外部系统进行功能改造，再由省级VGOP来进行功能集成；若外部系统无法或不适合进行功能改造，则由省级VGOP自行开发相应功能来满足自身的需要；l 外部系统没有省级VGOP需要的功能，可以在省级VGOP中开发新功能。3. 构建一站式工作台l 在省级VGOP中构建一站式工作台，通过优化、提升系统交互能力，实现对系统各类用户、特别是生产一线人员的业务支撑能力。5. 系统架构5.1. 逻辑架构省级VGOP逻辑架构包括管理门户、运营管理、数据与系统集成三个功能域，系统逻辑架构如图5-1：图 51省级VGOP逻辑架构图【管理门户】以Web方式展现平台使用者的工作界面和工作环境，提供用户个性化页面，实现对外部系统的界面集成，以及集中鉴权、单点登录、跨系统业务操作和业务管理等功能。【运营管理】实现增值业务及时、专业、精准的运营管理功能，包括业务监控、业务稽核、业务优化、营销服务支撑、工作支撑、客户画像、专项分析等功能。【数据与系统集成】实现数据与系统的集成管理功能，包括集成管理、维护管理、对外服务支撑、数据管理等功能。5.2. 功能架构省级VGOP功能架构如图5-2：图 52省级VGOP功能架构【管理门户功能域】工作台管理：面向管理人员、产品管理人员以及市场运营人员等省级VGOP各类使用人员角色，通过整合现有功能和流程，为其量身定做的“一站式”工作台，提供业务监控、业务稽核、业务优化、营销服务支撑等操作功能与工作流程管理功能，从而提升操作易用性与便捷性。【运营管理功能域】1. 业务运营l 营销服务支撑：增值业务营销服务支撑是在省级VOGP中，集成经营分析系统营销管理模块的功能，基于营销流程引擎，使用对增值业务的分析和挖掘成果，借助在客户细分、产品聚类、渠道适配、效果评估等方面的信息支撑优势，与省级CRM、业务平台等系统建立互动，形成增值业务营销服务工作的业务闭环和支撑合力，助力企业实现向客户提供增值业务的精确营销和精准服务，增强增值业务运营支撑的可操作性，进而提升增值业务的营销服务质量，增强客户对增值业务的满意度和粘着度。l 工作支撑：面向所有省级VGOP中需要涉及到的业务应用提供基础的工作任务管理的创建、处理、更新流程。任务管理功能即可作为一个独立的模块存在，也可穿插在其他业务功能中进行，例如业务监控、稽核预警等内容。2. 业务管理l 业务监控：省级VGOP应能够实现从其他业务平台采集各种关键性能数据，完成数据采集后，能够根据预先制定的监控策略，实现运行事件及关键性能关联分析和组合处理功能。同时，支持统一的告警数据管理，支持多角度、多层次的监视业务的运行情况。l 业务稽核：业务稽核是为了能够全面了解和掌握业务的发展状况，保证业务能够健康、稳定地发展，对业务用户的真实性和业务指标波动情况进行检查的一种手段，并为加强业务操作规范化管理等工作提供依据。l 业务优化：业务优化是业务上线后的后续跟踪和业务质量提升的过程。业务优化以业务数据分析和评测为手段，发现业务在产品、功能、营销策略等方面存在的问题，从而增强业务的实用性和便利性，提高业务质量和客户体验。3. 基础支撑l 客户画像：客户画像是根据增值业务运营管理的需求，对省级经营分析系统提供的客户统一视图的数据进行分拣与组合，并结合来自于各业务平台的业务明细数据，形成面向增值业务管理特色的客户画像信息。l 专项分析：以增值业务运营为核心目标，对增值业务在使用和运营等各环节中的特征信息进行分析，比如终端、渠道等，扩展目标数据，建立和集成分析的模型和能力，逐步提升增值业务的分析质量。【数据与系统集成功能域】1. 维护管理：提供对省级VGOP使用人员的工号、权限以及系统本身的维护管理功能。2. 对外服务支撑：作为增值业务运营支撑的核心系统，省级VGOP将自身的能力开放给其他业务平台或者系统集成使用。3. 集成管理：主要利用省级VGOP的技术集成能力（包括：界面集成、流程集成、服务集成、数据集成）进行与周边系统的统一集成管理。4. 数据管理：提供基础数据支撑能力，包括数据采集、分发、处理以及数据质量和元数据管理功能。5.3. 技术架构省级VGOP技术架构分为接入层、应用层、服务层和数据层四个层次，系统技术架构如图5-3：图 53省级VGOP技术架构图【接入层】接入层由适配子层和展示子层构成。其中适配子层为省级VGOP使用者提供多样化的接入方式，展示子层由展现逻辑构成，对内容及展现形式进行管理。展示子层接收请求，既可通过调用交互应用提供的功能，将返回结果按照展现逻辑加工成相应的内容（包括页面、文本菜单等），也可采用界面集成方式，通过聚合外部系统提供的界面展现组件按照展现逻辑加工成相应的内容（包括页面、文本菜单等）。【应用层】应用通过调用服务并根据预定义的流程或策略进行逻辑控制，形成特定的功能。应用分为两种，一种是有界面交互的应用，如指标监控报表等；另外一种是不提供界面的后台应用，如数据分析等。省级VGOP可通过流程集成方式集成外部系统子流程或服务，实现跨系统、长流程的交互或后台应用，如营销服务支撑。【服务层】服务是完成特定任务的独立、基础功能，具有高内聚、可重用的特征。服务可以通过新开发来实现，也可以通过服务集成方式来实现。服务可供应用层和外部系统调用。服务层包括但不限于：l 监控类服务：完成从相关系统采集必要的业务运行事件、KPI等数据后，统一处理，集中展现的功能，如飞信到达用户数监控服务。l 稽核类服务：完成对客户使用业务行为特征数据进行整理、抽样挖掘、信息比对等操作的功能，如12580当日高查询客户数稽核服务。l 优化类服务：完成建立相应的业务优化模型，进行深入分析，发现业务质量的薄弱环节及存在问题的功能，如业务模型优化配置服务。【数据层】数据层由数据和数据访问子层组成。数据是指VGOP需要的相关数据，数据的存储可以是关系型数据库、非关系型数据库、文件系统等。数据访问子层对数据的访问进行封装实现业务数据的共享。数据集成通过多种技术实现手段实现逻辑上或者物理上的数据获取。服务既可通过数据访问子层来获取所需数据，也可调用数据集成功能从外部系统获取所需数据。5.4. 系统边界省级VGOP需要完成与一级VGOP、二三类业务平台、省级经营分析系统、省级CRM/BOSS、省级BOMC的交互。图 54省级VGOP边界5.4.1. 与一级VGOP的边界省级VGOP与一级VGOP之间的边界主要包括：1. 省级VGOP向一级VGOP提供的数据：a) 一类业务的客服数据，包括业务办理、业务咨询、业务查询、业务投诉/建议等客服数据；b) 二三类业务的监控指标数据；c) 来自省级经营分析系统和二三类业务平台的维表数据；d) 互动任务反馈数据：省公司针对集团公司下发工作内容的解释和处理结果。2. 省级VGOP从一级VGOP获取的数据：a) 一类业务的监控指标数据、用户行为数据、业务优化数据、订购关系数据、质量管控数据（包括数据定义标准、数据结构标准和数据内容标准，具体参见数据管理分册）、稽核指标和明细数据；b) 一级VGOP的维表数据；c) 互动任务下发数据：集团公司针对省公司一类业务的异常或问题，下发给省公司需要省公司解释和处理的工作内容。5.4.2. 与二三类业务平台的边界省级VGOP与二三业务平台之间的边界主要包括：1. 省级VGOP向二三类业务平台提供的数据：a) 客户画像数据（定制终端IMEI数据）；b) 来自省级CRM/BOSS的客户状态数据；c) 营销执行数据；d) 来自省级经营分析系统和一级VGOP的维表数据。2. 省级VGOP从二三类业务平台获取的数据：a) 二三类业务的监控指标数据、用户行为数据；b) 营销反馈数据；c) 二三类业务平台的维表数据。5.4.3. 与省级经营分析系统的边界省级VGOP与省级经营分析系统之间的边界主要包括：1. 省级VGOP向省级经营分析系统提供的数据：a) 一类业务的用户行为数据、订购关系数据；b) 二三类业务的用户行为数据、订购关系数据；c) 客户画像数据（增值业务的业务画像和喜好画像）；d) 来自一级VGOP和二三类业务平台的维表数据。2. 省级VGOP从省级经营分析系统获取的数据：a) 历史分析数据；b) 客户画像数据（基础画像）；c) 一类业务的客服数据；d) 二三类业务的客服数据；e) 省级经营分析系统的维表数据。5.4.4. 与省级CRM/BOSS的边界省级VGOP与省级CRM/BOSS之间的边界主要包括：1. 省级VGOP向省级CRM/BOSS提供的数据：a) 营销执行数据。2. 省级VGOP从省级CRM/BOSS获取的数据：a) 二三类业务的订购关系数据；b) 用户状态数据；c) 营销反馈数据。5.4.5. 与省级BOMC的边界省级VGOP与省级BOMC之间的边界主要包括：1. 省级VGOP向省级BOMC提供的数据：a) 系统指标数据；b) 业务指标数据。6. 关键技术6.1. 与数据集市数据库合设本着“低成本、高效能”建设和运营省级VGOP的原则，为尽可能利用现有省级经营分析系统在数据库方面的能力，本期建设要求省级VGOP与省级经营分析系统增值业务数据集市（以下简称数据集市）共用数据库。本规范提出部分融合和完全融合两种数据库合设建设方案，各省公司可根据具体情况选择相应的建设方案执行。6.1.1. 逻辑架构本规范提出省级VGOP数据库与省级经营分析系统增值业务数据集市进行合设，以实现与省级经营分析系统的数据共享，以及元数据、数据质量和数据安全的共同管理。合设过程仅在数据层面进行，对省级VGOP及省级经营分析系统的上层应用完全透明。省级VGOP中的分析应用仍通过省级VGOP管理门户统一提供给最终使用者。省级VGOP数据库与省级经营分析系统增值业务数据集市合设逻辑架构如图6-1所示：图 61与数据集市数据库合设逻辑架构图数据库合设后，省级VGOP数据库从一级VGOP、二三类业务平台直接获取数据，并将该部分数据回传给省级经营分析系统数据仓库。省级CRM/BOSS、BOMC及MISC等支撑系统的数据仍然传给省级经营分析系统数据仓库，省级VGOP数据库从省级经营分析系统数据仓库获取相关数据，实现数据互通。6.1.2. 合设方案6.1.2.1. 部分融合方案部分融合方案是在省级经营分析系统增值业务数据集市的基础上构建省级VGOP数据库。合设完成之后，省级VGOP数据库和增值业务数据集市数据库共同存在。省级VGOP应用层基于新建的VGOP数据库进行建设并通过省级VGOP管理门户加以展现；原有省级经营分析系统应用层保持不变，并向省级VGOP应用层提供功能调用。方案逻辑架构图如图6-2所示：图 62部分融合方案逻辑架构图6.1.2.1.1. DB2数据库技术实现DB2数据库包括一个或者多个数据库分区(Partition)。每个分区本质上是一个小型的数据库，拥有自己的数据、日志、锁以及其它的组成数据库的基本要素。所以，DB2多分区数据库也称为基于非共享（Share Nothing）或海量并行处理（MPP）构架的数据库。利用DB2数据库分区技术，在省级经营分析系统增值业务数据集市中为VGOP数据库建立单独的数据库分区组。省级VGOP特有的数据存放于该分区组所管理的数据库表空间。省级VGOP数据库和增值业务数据集市所共有的数据存放于增值业务数据集市所在分区组管理的数据库表空间。该方案既保证VGOP特有数据具有相对的独立性，同时又可保证省级VGOP数据库可以共享增值业务数据集市的数据。该方案基于DB2数据库的逻辑架构如图6-3所示：图 63部分融合方案DB2数据库结构图对于已经建立省级VGOP数据库的省份，可在进行必要的软硬件升级后，将已有软硬件系统与现有经营分析系统增值业务数据集市进行整合；对于尚未建立省级VGOP数据库的省份，可通过对增值业务数据集市扩容的方式实现合设。6.1.2.1.2. ORACLE数据库技术实现将省级VGOP数据库和省级经营分析系统增值业务数据集市数据库部署到一个多节点RAC数据库中的不同Schema下，分开存储，各自管理。在融合过程中，需要考虑的主要问题有：1、 省级VGOP应用和增值业务数据集市应用运行在同一数据库上，需要评估增加的负载对性能的影响。2、 需要进行应用隔离，以防止某一个应用耗尽所有资源。3、 需要按照不同应用的优先级对资源进行合理分配。针对上述要求，该方案基于ORACLE数据库的Schema划分如图6-3所示：图 64部分融合方案Oracle Schema划分图在该方案中，省级VGOP和增值业务数据集市的数据及应用部署在不同的Schema中，采用分开存储、各自管理的模式。同时可通过ORCALE 10g中的Resource Manager功能对各个Schema的CPU使用率进行控制，防止某些应用过度抢占CPU资源。如果所使用版本为Oracle Exadata，可采用I/O Resource Manager功能对不同Schema间的I/O操作进行控制。利用ORACLE本身的权限管理功能可以实现对各Schema间数据访问权限的严格控制，如果需要更细粒度的控制，可选用Database Vault功能。图 65部分融合方案Oracle物理架构图上图给出该方案基于ORACLE数据库建设的参考物理架构图，说明如下：1. 省级经营分析系统数据集市数据库中包含VGOP、增值业务数据集市等多个Schema。2. VGOP应用指定运行在服务器1上，数据集市应用指定运行在其余的服务器上。 3. 采用Service的方式进行负载和故障隔离，配置VGOP Service：a. 主：服务器1b. 备：RAC中的其它服务器（服务器2服务期N）4. 保证VGOP应用只运行在服务器1上，而增值业务数据集市和其它经分应用运行在其余服务器上。 VGOP应用在正常情况下，不会占用这些服务器的资源。在ORACLE 10g中，可通过instance group和parallel group参数，限制并行进程跨Service访问。5. 该方式提供高可用性并提升查询性能：a. 当服务器1 宕机，其它服务器（如服务器2到N）会自动接管服务器1上的请求。b. 每个应用的访问限制在对应的数据库服务器上，不会连接到其他数据库服务器上（除非宕机），这样可以保证每个应用访问的数据固定存在于相应的数据库服务器内存中，避免节点间数据交互，减少inter-connect。由于新增了VGOP数据，访问量相应加大，可根据具体情况对原有省级经营分析系统数据集市数据库服务器进行扩容或利旧。6.1.2.1.3. TERADATA数据库技术实现在省级经营分析系统数据集市的TERADATA数据仓库中，构建VGOP数据库。利用TERADATA特有的PI（主索引）技术，通过Hash算法将数据均匀的分布到Teradata数据仓库的所有节点，保证数据插入和查询的高性能。该方案使VGOP数据库具有相对的独立性，同时又能共享增值业务数据集市的数据，而无需整合增值业务数据集市的数据模型和应用。该方案TERADATA数据库结构如图6-6所示：图 66部分融合方案TERADATA数据库结构图6.1.2.2. 完全融合方案完全融合方案是将省级VGOP数据库与省级经营分析系统增值业务数据集市数据库进行合并。合设完成之后，仅存在一个数据库。融合后的数据库同时支撑省级VGOP应用和省级增值业务数据集市应用。该方案逻辑架构图如图6-7所示：图 67完全融合方案逻辑架构图6.1.2.2.1. DB2数据库技术实现该方案不是在省级经营分析系统增值业务数据集市数据库中为省级VGOP数据库新建分区组和表空间，而是通过扩充增值业务数据集市分区的方式来支撑完全融合之后的增值业务数据库。VGOP数据库的计算能力完全利用增值业务数据集市的计算能力。该方案DB2数据库结构如图6-8：图 68完全融合方案DB2数据库结构图依据完全融合方案，已建及未建VGOP数据库的省份均可通过对增值业务数据集市扩容的方式实现合设。6.1.2.2.2. ORACLE数据库技术实现将省级VGOP数据库与省级经营分析系统增值业务数据集市数据库整合到一个多节点RAC数据库中，采用同一个Schema。对于已经构建VGOP数据库的省份，现有的VGOP数据库与增值业务数据集市在分析应用功能上可能存在重叠，则底层数据也可能存在较大重叠。融合过程中，必须考虑对重复数据进行融合，即必须对两部分的数据模型进行融合，使得未来的应用架构在统一的数据模型基础之上。这样既减少了不必要的数据存储和重复装载，也提高了数据一致性，同时在更加丰富的数据之上，可以构造更加完整的数据视图。针对以上的要求，该方案基于ORACLE数据库的参考物理结构如图6-9所示：图 69完全融合方案Oracle物理架构图合设完成后，新的VGOP数据库(增值业务数据集市)中包含原VGOP数据库中的数据和原增值业务数据集市中的数据，并采用统一的数据模型。新数据库采用RAC的方式保证高可用性和负载均衡。底层存储建议采用ASM（自动存储管理）方式，以提升I/O性能，减少管理工作量。由于合设后数据库的数据量和访问量均增大，所以可根据具体情况对服务器进行扩容或利旧。同时，由于应用和数据增多并且不同应用对性能有不同的要求，所以还可考虑采用Oracle 10g中的Resource Manager对不同优先级的应用进行合理的资源分配，以保证原有应用尽可能少的受到影响。下图给出采用Resource Manager对资源进行规划的参考示例：图 610部分融合方案Oracle资源分配图通过资源分配，将所有用户划分到三个不同的资源组。每个组有对应的优先级和资源分配计划。不同的资源组可以限制不同应用对数据库实例上的资源的使用率，避免个别应用耗尽所有资源，有预见性地保护系统。如对并发操作的最大数量、给定优先级分组的最大并行程度等进行限制。在完全融合方案中，也可采用Resource Manager对资源进行合理分配。6.1.2.2.3. TERADATA数据库技术实现将省级VGOP数据库和省级经营分析系统增值业务数据集市数据库融合为统一的TERADATA数据库。该方案仍将用到TERADATA特有的PI（主索引）技术，通过Hash算法将数据均匀的分布到TERADATA数据库的所有节点，保证数据插入和查询的高性能。通过数据库访问权限控制来查询统一基础数据模型。该方案TERADATA数据库结构如图6-11所示：图 611完全融合方案TERADATA数据库结构图6.2. 能力集成能力集成是通过构建系统集成架构，将现有分散在外部系统中的功能点进行流程串接和应用集成，形成省级VGOP所需要的业务支撑能力。能力集成方式包括：界面集成、流程集成、服务集成、数据集成。图 612能力集成逻辑架构图l 界面集成：是通过集成外部系统的用户界面，建立一个跨系统、跨应用、统一、集成的业务操作与管理工作台。l 流程集成：是通过集中的业务流程管理引擎，来管理各类跨系统的业务流程，统一调度外部系统中的服务，实现跨系统的长流程。l 服务集成：是通过对外部系统的业务逻辑服务进行抽象、封装、组合、调用，从而实现对外部系统应用能力的集成。l 数据集成：是通过获取外部系统的业务数据或分析数据，实现系统内功能需求、应用需求和展现需求的数据支撑，完成数据在系统中的集成、运算及结果展现。6.2.1. 界面集成6.2.1.1. 逻辑架构界面集成是对不同界面展现组件的集成。通过合理的规划和设计，界面集成可以重用已有企业系统的内外部资源，并聚合成符合一定标准的界面，从而提高开发部署效率、迅速满足客户和业务的需求。被集成的外部系统的界面，可按照管理门户/工作台的业务使用习惯和技术框架要求来进行改造和展现。图 613界面集成逻辑架构图界面集成的主要方式如下：1. iFrame页面嵌套外部系统已有UI页面并且页面跳转流程清晰，页面没有业务逻辑不需要的元素，同时不需要额外的参数传递的,可以使用iFrame将其变为Portlet。iFrame页面嵌套需遵循W3C的标准，形成基于HTML的<iframe>标签。2. Web 裁剪器（Web Clipping）外部系统的UI需要调整但业务逻辑相对完整，可以通过Web Clipping的方式将其裁剪转换为Portlet。当一些页面无法直接嵌入到Portlet（元素、风格等不匹配）时，可以采用Web Clipping等页面转换方式，将页面中的部分内容嵌入到Portlet中。3. URL链接管理门户/工作台通过URL链接的方式，将用户请求定向到外部系统页面地址。URL链接是最低程度的集成，适用于固定栏目链接、页面直接跳转等。4. WS