数据集成解决方案-2

数据集成解决方案PAGE18PAGE数据集成数据集成系统现状企事业内部有不少的应用系统，比如财务系统、人力资源系统、工程管理系统（项目管理、采购管理、库存管理）、管理数据统计系统和企业信息门户。这些系统一般都有不同供应商提供，他们之间的信息有重叠和不一致显现存在。因此很容易产生下列的问题：基础数据多头管理，系统间数据一致性差对于同样的问题，每个不同的系统都维护有自身的数据结构，例如在工程管理系统中存在供应商数据，而在物资系统中也存在供应商数据，这两个系统对同一个供应商可能存在不同的编号、不同的命名等等。这就导致了两个系统间没有数据标准，在工程管理系统中更新了供应商数据后，物资系统无法依据指定的规则进行同步更新，造成了企业主数据的混乱局面，难以满足快速支撑精确管理的需要，使得企业的运营效率和管理水平难以进一步提升。接口没有实现统一的接口平台由于没有统一的企业主数据，目前系统接口均采用点对点方式，技术实现方式多种多样，例如最多的方式是数据库直接存取，接口双方需要明确知道对方的底层数据结构，这导致了完成和维护这些接口是一项非常艰巨的任务，并且在不同的供应商之间难于明确自身的责任，出现问题之后相互推诿。企业内部信息难以完整统一和共享由于现在的应用系统是由不同的供应商提供，基础数据难以同步更新，各自产生的数据信息，都成了一个个的信息孤岛，彼此之间的数据难以共享。企业不容易获取汇总信息。数据集成需求分析接下来我们从业务和系统两个方面来分析数据集成的需求：业务需求统一用户视图的提供及展示企事业应用系统给用户提供各种服务，需要在各个应用系统上提供及展现统一用户视图信息，通过数据集成实现统一用户视图信息的共享，支撑多个层面快速准确地获取用户和产品信息，提升用户感知。比如在营销、销售、服务中，提供营销人员营销活动所需的市场统计数据和目标用户数据，以便进行精确化营销；提供销售人员单一用户视图信息及其统计数据的即席查询，以发现用户需求，增加销售机会；提供服务人员跨系统数据的支撑，以进行用户分等级服务、用户增值业务，订购信息快速查询和退定等工作。统一企业运营报表的提供和展示CRM、计费等生产系统分别按照本系统的自有数据向外提供运营报表，不同部门对数据的时间和业务概念理解不一致，造成不同系统的报表有差异，同时手工进行报表拼凑也会造成差异，于是产生了不同部门有差异，不同组织层级有差异，而且大量按需的对外报表提供对生产系统性能影响很大，不利于生产系统对其核心事务处理的稳定运行。因此通过数据集成，统一企业运营报表的数据源，形成统一的指标体系，并通过统一的企业数据应用门户，实现企业运营报表的统一提供和展示，实现多纬度的报表需求，以支撑精确化管理需要。支撑企业运营过程的统计、监控和考核全过程的营销支撑需要对市场计划、营销活动、销售活动等各项工作事前预期，事中监控，通过数据集成，基于从各生产系统搜集到市场营销与销售的相关信息，对市场营销与销售业绩完成情况进行统计，并通过用户发展、业务量、收入等关键绩效指标和实际完成状况的关联，完成对各部门、团队或渠道的KPI指标进行监控与考核。支撑企业运营过程所需跨系统数据的批量计算为了更好地支企事业工作的开展，提升用户管理能力，需要建立用户积分、信用度等用户评价体系；为了实现用户品牌维度，对相关量收指标进行统计；为了，发展优质用户，需要复杂、完善的渠道佣金计算支持；随着产品为中心向用户为中心的转型，越来越多运营过程所需的跨系统、大量细节数据的批量计算需求都需要统一的数据集成中心提供相关数据。数据集成中心作为企业运营数据共享平台，收敛企业各业务系统中的运营数据，按照企业数据模型进行数据整合，提供运营数据共享，支撑跨系统数据的应用，提升数据质量。系统需求实现数据统一数据集成中心在对企业数据的整合过程中能够实现以下三个统一：统一数据模型由数据集成中心承载企业数据模型（EDM），促进企业各域数据逻辑模型的统一。在企事业内新建或改造的系统，其数据模型应向数据集成中心所承载的企业数据模型靠拢。数据模型是各个系统及应用间交互的基础，通过数据模型的统一，减少系统及应用间复杂的转换，提高系统、应用、接口的效率。统一数据标准数据集成中心中建立标准的数据编码目录，源系统数据依据标准的数据编码目录，经过整合后进入数据集成中心存储，实现企业数据的标准化与统一存储。统一数据视图基于数据集成中心所存储的数据，支撑实现统一数据视图，使企业在用户、资源等视角获取到的信息是一致的，提升用户、以及企业内部的管理人员与分析人员对系统的感知。实现数据共享数据集成中心为企业各业务系统提供统一共享数据接口，减少系统间相互接口的重复性，降低接口的复杂程度，提高系统间接口效率与质量；为跨系统数据应用提供数据支撑。数据集成中心作为企业运营数据共享平台，是各业务部门和企业管理层获取统计数据的唯一来源。数据集成中心可将某个生产系统的数据以准实时地方式存储转发至其它对数据实时性要求不高的生产系统，以减少生产系统间的网状接口。数据集成中心以实时的查询服务或准实时批量的数据提供的方式将数据集成中心内整合或计算好的数据向外部系统提供，以配合外部系统支撑统一用户视图查询、用户服务流程等功能。实现数据应用数据集成中心利用自身系统的数据提供以下几类功能：查询应用 实现查询条件不固定的按需查询功能。用户可以根据关心的维度查询数据集成中心内整合好的360度业务全貌数据，如，为渠道经理提供完整用户视图信息的查询，为用户提供完整用户视图查询、用户账单查询等。固定报表应用固定报表是维度和指标固定的统计结果的展示，在数据集成中心内对于实时性要求高的报表采用即时生成的模式，而对于实时性要求不高的报表，基于性能影响和资源开销两方面的考虑，应采用后台通过作业的方式先自动生成，在需要时可以立即展现结果。报表展现应支持多种图表方式，如饼图、柱图、线图等；支持报表数据导出为其他文件类型，如EXCEL、CSV、XML、PDF、WEB存档文件等；支持报表精确打印控制。动态报表应用基于数据集成中心整合好的数据，可以利用报表工具，按关心的维度和指标对数据进行主题性的统计，动态报表应用中，维度和指标不固定，可在数据模型支持的范围内变换。在数据集成中心上可实现多种动态报表。计算应用数据集成中心可基于整合好的数据按照设定好的业务规则进行部分属性数据计算，计算结果并不在数据集成中心内直接更新，而是由数据集成中心返回到该属性数据的属主生产系统，由属主生产系统完成该属性数据的更新后，再通过数据抽取、加载过程进入数据集成中心之后更新。实现数据质量管控数据集成中心在数据收敛的过程中，能完成以下数据质量管控工作：1.数据质量校验根据规则对数据集成中心所存储的数据进行一致性、完整性、正确性的校验，形成数据校验结果并交付源业务系统进行修正。2.数据质量管控通过建立企业数据的质量标准、数据管控的组织、数据管控的流程，对数据质量进行统一管控，达到数据质量逐步完善。数据集成目标通过数据集成，数据集成中心应该能达到以下几个目标：建立规范统一的指标体系根据企业的业务实际情况，建立面向企业指标体系的数据接口，用于收集企业各系统间的指标数据，同时为企业各系统提供所需的指标数据，成为沟通企业现有系统和未来系统之间各种关键业务指标数据的信息桥梁。统一的数据采集接口建立统一的数据采集接口，根据企业实际业务需要，定义符合企业需要的数据采集指标，通过企业数据业务平台统一的进行数据采集，改变原有层层下达参数，再层层汇总、层层过滤，时效性和准确性亦难以保证的问题。统一的数据存储中心通过企业规范的指标体系，收集和整合相应指标数据，存储到数据集成中心。按照统一指标、统一统计口径和统一数据概念的要求，存储指标数据和建立数据存储中心，满足不同系统之间相互获取数据的要求，同时为数据的综合分析和历史回溯奠定数据基础。历史数据的回溯分析基于规范性与灵活性相结合的原则，通过对数据存储中心的历史数据进行提取和加工整理，采取分级用户具有分级权限，在权限范围内灵活使用数据，进行分析和查询，可以为管理决策者在生产管理和经营决策上提供科学有效的历史数据依据。建立数据应用接口企业在生产经营决策过程中，通常迫切需要了解企业外部的实际情况，所以需要打通企业与外部的数据壁垒，实现彼此之间数据共享。这种需求通过建立企业与外部之间特定的数据应用接口，一方面，从外部抽取企业需要的特定商业指标数据，另一方面，提供外部所需的企业指标数据。通过二者数据之间的充分对比分析，实现数据之间的数据共享，提高现有系统的数据使用率和有效地提高数据支撑能力，为管理层的经营决策提供坚实可靠的依据。建立统一的决策分析管理平台通过对采集的基础数据信息的提取和加工整理，本着规范化与灵活性相结合的原则，设定不同的使用权限（组织和人员），灵活使用数据，进行分析和查询。系统统一下发固定报表模板，同时用户可根据个性化需求灵活定制报表，提供决策支持。数据集成思路通过前面的需求分析，我们可以整理出我们的数据集成思路，从而设计合理的数据集成方案。数据集成系统对于企事业的长远发展来说，应该是处于企业应用系统与企业数据仓库系统之间的。企业的一系列数据中，一部分是实时性要求非常高的，必须要求能实时的更改存放在多处的同一份数据；而有一些数据则实时性的要求不高，不需要实时地进行修改而是定时进行相应的同步即可。ODS的思想结合ETL与ESB等相关技术，实现这一套数据集成系统是比较合适的。通用ODS架构分析ODS（OperationalDataStore），运营数据存储或者操作型数据存储，存储了运营系统（OLTP，联机事务处理系统）近实时的详细数据。ODS是企业数据架构中最为复杂的一种形态，它既要满足数据事务操作要求，又要满足数据分析要求。它是“一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求”，常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。ODS的引入是为了寻找能满足快速加载和数据整合的性能要求，并且减少面向分析的需求的变更和扩充对业务系统的影响的解决方案。这一解决方案是在业务系统和EDW中的按主题存储的历史数据存储层之间增加一个数据整合层（也叫做数据缓冲层）。数据整合层的作用主要体现在以下两个方面：数据结构和处理流程是以快速从业务系统中加载和整合数据为目的设计实现的，因此尽量减少复杂的数据转换，只对原始数据进行清理和整合，这样，可以满足快速加载和数据整合的性能要求。另一方面，当面向分析的业务需求变更和扩充需要对数据仓库中的历史数据进行主题重组或增加新的数据时，所需数据将会先从数据整合层中提取，只有数据整合层也不能满足其数据需求时，才会从业务系统中提取数据，这样就减少了分析需求变更和扩充对业务系统的影响，数据整合层起到了一个数据缓冲的作用，同时提高了数据仓库系统对于需求广度和深度扩展的适应性。我们认为，ODS（OperationalDataStore）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：在业务系统和数据仓库之间形成一个隔离层。一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。转移一部分业务系统细节查询的功能在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。完成数据仓库中不能完成的一些功能。一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。目前市场上没有成熟的MDM(MasterDataManagement)产品，并且在微软的技术路线中，数据库元数据的概念已经被废除，现在推荐的方式仍然是以合理的方式建立数据库表或者视图的方式来满足ODS数据结构的定义，最终的数据结构是否灵活好用依赖于详细的设计，其中需要考虑地问题包括如下几个方面：规范性在ODS系统中，对同一个概念的对象必须按企业领域的标准方式处理，比如，区别供应商必须按照他们的税务登记号，而不是名称。灵活性当业务需求发生变动时，ODS主数据结构应该能够快速的适应这种变化。比如：可以为一个员工建立基本的员工信息字段，当员工信息增加时就相应地增加员工表的字段；也可以在一开始就为员工信息表多创建一个XML字段用来保存今后可能产品的员工信息增长的情况。两种不同的设计方式必须根据实际的应用情境进行选择。关联性同一业务对象在不同的系统中将被关联到不同的业务对象，ODS必须建立完备的数据结构用于存储一个对象与其它对象发生的所有关联。例如，员工在人力资源系统中被关联到部门，而在物资系统中被关联到采购管理员角色，新的需求是取得某部门的采购管理员。ODS的数据结构设计必须能够满足新出现的类似需求。通用ESB架构分析基于SO思想的A企业服务总线（ESB），是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务协调运作，实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途:电信领域ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。电力领域ESB能够在全方位支持电力行业EMS的数据整合概念，是理想的SCADA系统数据交换平台。金融领域ESB能够在全方位支持银企间业务处理平台的流程整合概念，是理想的B2B交易支撑平台。电子政务ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（服务）和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。ESB专门用于异构环境，既可以帮助企业迁移到SOA，又能够让企业继续利用现有的已部署的软件投资。通过使用ESB，以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。更重要的是，充当“缓冲器”的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用程序可以同时使用同一服务，用不着在应用程序或者数据发生变化时，改动服务代码。进行数据的集成，一般按以下三个阶段来进行：把原有应用系统需要进行集成的业务功能先进行标准的封装，如采用webservice进行封装，然后以标准的结构文档，如XSD,确定接口输入输出的数据格式.部署ESB中间件产品，并进行ESB上相关功能调用的开发，把原有应用系统封装好的接口，接入到ESB中，形成一种服务。门户或外部的系统，通过调用ESB上的服务与后台应用系统进行交互，从而完成特定的功能。数据集成阶段划分通常一种比较理想的方式是建立一份统一的企业主数据（MasterData），它兼容现有的系统和可预见的系统的建设需求，并使之在不同的系统间共享。这个过程分为三个步骤：建立企业主数据结构，即ODS的基础数据结构；第二步，基于ETL平台，建立数据抽取任务，从现有的系统中抽取必要的数据（并清洗）填充ODS数据库，有需要的话也可将ODS数据推送到各个业务系统中；基于ESB平台，暴露ODS数据对外的访问接口，并不断的建设各个系统之间的接口。数据集成效果主数据整合，通过ODS（共享管控数据集成中心）、ESB（企业服务总线）基础平台的搭建，规范系统主数据，实现企事业内各系统、以及EDW间的数据交互和共享，保证数据一致性；统一系统接口，通过ESB与多个核心平台搭建接口，实现核心系统接口统一。主数据管理，提供对主数据变更、维护功能。业务数据抽取整合，并提供数据管理、查询、分析、统计等应用功能。使得企业数据仓库逐步改为从ODS取数。所有的统计分析需求按其涉及数据范围大小和复杂程度高低，分别由应用系统、ODS和数据仓库提供支撑，尽可能向ODS和数据仓库集中。数据集成方案ODS系统设计现阶段ODS系统设计如上图所示，我们设计的ODS系统中，主要有ETL模块和ODS模块2部分组成，ODS系统根据通过Trigger、应用、批处理、Queue等手段从各MSS应用系统中获得数据，并通过ETL应用对数据进行抽取、转换、清洗、并装载到ODS数据库中。而一般通过TriggerUpdates的方式来将一些ODS数据返回更新各MSS应用的数据库。ETL模块这里的ETL模块主要是数据抽取、转换和加载，这是数据由数据源系统向ODS加载的主要方法数据抽取从数据源系统抽取数据仓库系统所需的数据，数据抽取采用统一的接口，可以从数据库抽取数据，也可以从文件抽取。对于不同数据平台、源数据形式、性能要求的业务系统，以及不同数据量的源数据，可能采用的接口方式不同，为保证抽取效率，减少对生产运营的影响，对于大数据量的抽取，采取数据分割、缩短抽取周期的原则，对于直接的数据库抽取，采取协商接口表的方式，保障生产系统数据库的安全。数据转换数据转换是指对抽取的源数据根据数据仓库系统模型的要求，进行数据的转换、清洗、拆分、汇总等，保证来自不同系统、不同格式的数据和信息模型具有一致性和完整性，并按要求装入数据仓库。数据加载数据加载是将转换后的数据加载到数据仓库中，可以采用数据加载工具，也可以采用API编程进行数据加载。ODS数据库模块操作数据存储ODS（OperationDataStorage）是一个集成了来自不同数据库数据的环境。其目的是为终端用户提供一致的企业数据集成视图。它可以帮助用户轻松应对跨多个商业功能的操作挑战，是面向主题的、集成的、近实时的数据存储。设计ODS层的目的在于改善了对关键操作数据库的存取，获得收益、用户等主题的企业级完整视图，有利于更好地通观全局。近实时的数据存储提供了查询与服务能力，并以更高的性能生成操作报告。设计ODS的核心是实现焦点主题全局试图应用，如企业的用户管理系统，可以建立以用户为中心的ODS用户主题视图，向上层提供高效的服务。因此，在现有设计中，我们将配置2个服务器分别运行ETL应用和ODS数据库，由于ODS数据库即具有数据仓库的功能，也具有一定OLTP应用的特征，对性能要求较高，因此我们建议配置1个6CPU的PC服务器作为ODS数据库服务器，另一个4CPU的PC服务器作为ETL服务器。从高可靠性出发，这2个服务器将作HA高可靠性冗余。相关数据将放在SAN网路存储中，冗余后的逻辑大小为3TB。未来ODS系统设计对于未来的ODS系统设计，我们认为可以引入MDM的设计，但通过ODS来自动修改的数据库结构也应该仅针对新开发的应用，即根据新开发应用的需来对数据库的结构进行修改。而不应对一个正常运行的应用系统进行任何的改变。0DS系统架构ODS系统是介于DW和OLTP系统之间的系统。历史事实证明，只有将各个系统的数据综合在一起才能真正反映出企业管理需要的数据或者报表，而对这些数据的要求是近乎实时的。通过整合现有系统的数据和流程。使ODS系统作为所有应用系统交互的平台，通过ETL和ESB两种技术对现有数据进行整合：各个应用竹编，如人力资源、财务管理等将通过企业服务总线平台（ESB）进行交互，ESB也作为其它可能与应用系统交互的统一接口；另一方面，数据抽取传送平台（ETL）负责将各个子系统的数据抽取出来（拆分、合并、映射）装入到ODS系统中，那么ODS系统在具备了各个子系统的近实时数据之后，就可以作为独立数据源对外提供数据服务，它可以作为数据报表和分析的数据源，也可以作为其它子系统相互同步的数据源。这样做有两个好处：转移了本属于各系统的信息查询负载到ODS系统，使各系统的压力降低，提高了整体性能。OMS由于拥有了完整的主数据，它为面向主题的分析提供了必须的数据基础。ODS数据模型ODS终极目标是为了提供非战略性的中层决策支持，我们认为ODS的数据模型可以参考数据仓库（DW,DataWarehouse）的基础模型，即将数据分为事实数据和纬度数据。事实数据一般代表的是业务变动记录，在MSS中我们称为业务数据，而纬度数据则存放事实数据中业务发生的对象主体信息，纬度数据称为主数据。事实数据和纬度数据的关系是通过关键字来关联的，在数据库中它们都体现为数据表的形式。以下为ODS的数据模型图：图表SEQ图表\*ARABIC13ODS数据模型在上图中纬度是维持各系统数据的一致性描述，而事实表则是提供分析使用的基础数据。在确立了基本的数据模型之后，如何确定数据的采集的范围呢？首先从构建企业全局视图出发（即面向主题的分析），查出每个主题需要哪些数据，这些数据分别分布在哪些系统中，当这一切确定之后，那么整个ODS数据模型牵涉到的数据范围就基本确定了。接着需要通过ETL工具将各系统中的业务数据转换后装入到ODS数据库中，转换方式大致分为四种：迁移：一般性的数据拷贝方式，源和目标的数据属性和值完全相同。组合：例如将供应商所处的省份、市、街道组合为ODS中的地址字段。拆分：例如将员工姓名拆分为单独的姓和名字段。映射：例如将合同的“完成”状态映射为“OK”态。当数据从MSS子系统转换到ODS系统时，数据质量依赖于ETL平台，ETL平台提供完整的事务、容错、补偿、容错和日志功能用于控制数据转换的质量。0DS数据交互方式我们已经确定了ESB作为ODS的数据交互机制，它允许多个应用程序以去耦合或松散耦合的方式结合在一起。在一个软件“总线”上，应用程序的添加和删除对同在总线上的其他应用程序造成的影响非常小。也可以认为ESB实现了调度程序/路由器模式，因为它解决了消息在使用ESB的应用程序之间的路由选择问题。ESB是服务基础架构的核心，它支持在异构环境中以高度动态的方式对服务进行注册、发现和调度。ESB本身可看作是企业实现和拥有的架构模式。ODS从来不直接与各系统或数据仓库直接交互，无论系统访问ODS系统，还是ODS发送消息各系统，它们总是通过调用服务总线中的组件来完成数据交互的。并且，ESB不仅是为ODS提供数据服务，ESB是作企业应用集成环境（EAI）中核心的数据交互机制为所有的信息整合提供数据服务。下图为ESB的逻辑模型：对于ESB的设计原则，我们主要参照以下几点：强调性能，增加系统并发能力，避免出现任何由局部的堵塞造成整个ESB平台堵塞的情况。必要情况下要将长消息流用队列断开为多条可并行的消息流以增强系统并发能力。避免单点故障，使用双ESB，多执行组，多消息流配置，HA高可靠性集群等方式来杜绝单点故障，提高系统的总体可用性。提高可重用性。可重用性包括代码可重用性，以及在运行时的可重用服务。前者要求使用统一报文格式，统一编码规则开发可备重用的标准Template，后者要求使用开放的标准定义服务及发布服务。增强可维护性及灵活性。尽量避免新增的功能对原有代码的改动，改动尽量能做成由配置驱动，而不是涉及代码改动。ESB须提供日志（Audit）功能以备各种比对要求和延迟计算。系统必须能提供在流入及流出ESB的节点日志。基于ESB构建的ODS数据交互方式描述如下：各系统以消息订阅者的身份注册到ESB平台，监听进入ESB信道的各种消息，根据一定的规则选择对某些消息做出响应；同时每个子系统也可以消息发布者的身份向ESB发送特定的消息，期望得到其它子系统的相应。通过这种模式也可以看出，ESB实际上是一个面向服务的消息调度平台。ODS数据安全性控制从上文的系统架构设计可以看出，ODS作为数据集成中心，可以被各个系统通过不同的途径读取或者改写，最主要三种方式是：各系统直接读取ODS的数据结构；各系统通过ETL平台读取或者改写ODS系统数据；各系统通过ESB平台发出请求消息，导致ODS的数据被请求或者改写；对于这样一个庞大的系统的数据安全控制，我们认为最重要的是先创建一份安全审计的规则表，即通常所说的CRUD（C,Create；R，Read；U，Update；D,Delete）权限矩阵，下表为矩阵的模版：ODS实体属性计划建设系统物质系统财务系统…供应商编号R(ETL)CRU(DB)R(ESB)名称R(ETL)CRU(DB)R(ESB)上表演示了ODS系统中的关于供应商实体数据在不同的系统中发起的各种操作的情况下，所能执行的数据访问权限。具体的CRUD权限矩阵将根据实际的业务需求制定。数据管理由于用户的需求和场景是经常变化的，因此满足个性化的定制将变的非常重要。目前数据应用在个性户定制方面主要表现在：虽然定义了模型，但模型不完整，效果不好。这样用户在使用时，不能根据其需求动态的调整后端的业务规则和运行环境，不利于用户的使用。所以需要提供一个灵活的数据模型管理，以及业务规则管理，来应对系统的变化。数据模型管理提供可视化的数据模型编辑工具，支持以下几种数据模型抽取模式。主扩展模式通常用来将几个相似的对象的共有属性抽取出来，形成一个“公共属性表”。例如：一个员工的基本信息由角色信息、组织信息、岗位信息等部分组成。主从模式描述两个表之间的主从关系，从而形成的“一对多”关系。例如：一个项目对应多个计划阶段。多对多模式描述对象相互不分主次、地位，互为一对多的关系。例如：一种器材可以对应多个领料单，一个领料单也可以对应多种器材。流程、规则管理提供可视化的流程编辑工具、流程定义和流程监控功能。提供函数集提供常用规则方法，以及规则定义语言描述规则。提供基本规则：直接映射原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算。数学运算数据源的一个或多个字段进行数学运算得到的目标字段，比如：合同里的支付计划由多个时间段和支付比例组成，由此得出其总的合同支付时间和支付金额，这种规则一般对数值型字段而言。参照转换在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。这个关联数组使用Hash算法实现是比较合适也是最常见的，在整个ETL开始之前，它就装入内存，对性能提高的帮助非常大。字符串处理从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值，以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。空值判断对于空值的处理是数据仓库中一个常见问题，是将它作为脏数据还是作为特定一种维成员？这恐怕还要看应用的情况，也是需要进一步探求的。但是无论怎样，对于可能有NULL值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，目前我们的建议是将它转换成特定的值。日期转换在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、6位月份值等。日期运算基于日期，我们通常会计算日差、月差、时长等。一般数据库提供的日期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必须有一套自己的日期运算函数集。聚集运算对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为SQL标准中，包括sum，count，avg，min，max。既定取值这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值主数据管理我们的系统必须要能保证基础数据的数据模型、编码规范的稳定性。这样才能为其他各个系统提供准确统一的数据。但是即使在稳定的数据也有会发生变更的可能性，甚至会被要求删除。但是如果直接变更或是删除，会影响到各个业务系统的使用。所以必须采取一定的措施来避免这样的问题。主数据变更在与相关部门沟通协调后，如果主数据仍然需要变更。我们将把主数据更新成新的版本，并同时通知各个业务系统，同时将继续在一定时间内维持旧数据的版本。使各个系统有时间来变更和接受新的主数据。当变更完成后，旧的主数据版本将会被移除。如下所示：项目信息主数据（旧版本）项目信息主数据（旧版本）项目信息主数据（新版本）计划建设系统项目信息主数据（旧版本）项目信息主数据（旧版本）项目信息主数据（新版本）计划建设系统项目信息主数据（新版本）项目信息主数据（新版本）计划建设系统主数据删除在与相关部门沟通协调后，如果主数据仍然需要删除。系统将会通知引用该主数据的系统。直至所有引用该主数据系统全部不使用该主数据时，系统将对此主数据进行删除。项目信息主数据项目信息主数据计划建设系统项目信息主数据项目信息主数据计划建设系统计划建设系统计划建设系统报表功能数据仓库概念的提出也把数据处理划分为了操作型处理和分析型处理两种不同类型，从而建立起了DB-DW的两层体系结构。但是有很多情况，DB-DW的两层体系结构并不能涵盖企业所有的数据处理要求，比如有些实时性决策问题，它要求获取数据周期不能太长，而且也需要一定程度的汇总。这样的问题可以借助于DB-DW的中间层ODS（操作数据存储）来解决。它象DW一样是一种面向主题，集成的数据环境，又像操作型DB一样包含着全局一致的，细节的当前的数据。我们看下常用的几种系统应用集成需求：一级干线工程信息查询！（实时监控）重点供应商往来情况分析！（决策支持）小灵通设备折旧年限改为七年的折旧差异测算！（预测）建设单位管理费占工程支出的比例分析2006年7月DDN、分组交换、微波、PDH在网资产情况提供事实的全局信息进行实时监控与临时决策要满足上面所有的需求，不管是传统的OLTP系统还是已经集成的数据仓库，都是很难完成任务的。由于这些原因，ODS应运而生。ODS可以看作是围绕主题进行动态整合的一种应用型体系结构，它有如下一些特点：从OLTP系统获取数据提供几乎精确到每秒的企业整体应用状态数据一旦过期就将转入DW实时决策与预警提示使用者多为前端业务人员在企业领域中，我们可以通过下表的梳理方式来选择我们所要切入的分析主题报表：主数据集团统一单位编码、集团会计科目编号、集团用户、集团供应商在建工程：专业类别、建设性质、管理关系、项目属性资产：资产类别、资产归属、资产状态、折旧状态财务辅助系统：物资类别、网络元素、产品类别、各种费用明细分类等业务数据应收明细、应付明细、一级干线工程基础数据表、一级干线工程合同信息数据表、一级干线工程计划下达信息数据表、一级干线工程核算数据表财务辅助系统报销单明细数据：领料单，修理费，营销费，代办手续费，差旅费，会议费，综合费用多维汇总数据科目余额表、在建工程统计、资产统计报表关联交易汇总表、应收账款汇总表、应付账款汇总表、在建工程决算信息一览表、工程预、决偏离信息表、已决算工程项目费用构成情况表、固定资产详情表、折旧预测表功能特点先进的技术与支持多种数据库信息化建设过程中，业务需求是逐步发展的，这样就要求系统总体结构的设计有完善、先进、稳定、可靠的软件架构。采用基于XMLWeb服务（WebService）的.NET技术开发ODS系统，是项目成功的有利保证。提供灵活方便的自定义业务流程的功能。以图形化的形式绘制各类业务流程，并可在该业务发生变更时很方便地进行维护。对于简单的业务，可不需进行程序代码的变更，完全通过自定义的方式定义出该业务种类的各个环节以及其权限处理、权限控制和业务处理方法。面向用户角色的设计。系统设计方案在构想初期就从ODS系统管理所要求的层次：操作层和管理层全盘考虑，充分了解不同级别的人员所关心的问题，务求能够为用户解决在ODS系统应用中的实际问题。产品的高度灵活性、开放性和可扩展性市场唯一不变的法则就是永远在变。企业发展的可拓展性，作为企业的决策者，企业发展的可持续性、可拓展性已是一个不可忽略和怠慢的话题。作为ODS系统的一种管理理念，这种企业拓展性发展已被融入其中。ODS系统为了更好的方便企业对于拓展性的要求，并使企业决策者在考虑拓展企业时无需为大量的信息投资所困扰。集成与开放体现在两个方面：一是系统自身模块的集成；二是与外部其它系统的集成。科大讯飞的研发人员在开发ODS系统管理系统时就充分考虑到用户的这种需求，将系统设计成开放性的系统，预留数据库和系统接口，保证了与其它系统的无缝链接。ODS系统管理系统优良的可升级性能，使用户用最低的成本，满足了当前和未来的资源需求。服务器管理及监控系统为了能使用户对于公文处理和事务审批系统更好的使用，我们需要对应用服务器系统进行统一的管理监控。通过对应用服务器运行状况的监控管理，可以提高用户的体验水平，增强系统的可用性。系统管理及监控系统主要是为了达成此目的而建设。整个系统对服务器的监控管理，实时接收采集各种时间信息，对服务器运行状态进行评估，保证系统稳定运行。服务器监控管理功能1、服务器监控管理功能通过对Windows平台和Windows平台上应用系统的事件、健康情况、性能状况的监控，可以实现对管理范围内的重要事件信息的捕获、评估并及时呈现给系统管理员，让系统管理员可以及时做出反应，尽快解决各种潜在的隐患，不至于影响关键应用的正常运行。同时管理系统通过内置的职能知识库系统帮助系统管理员根据发生的事件尽快诊断出问题所在，以便对症下药，解决问题。还可以不断完善、丰富知识库内的内容，以提高IT管理的水平。2、系统采用精密的多层体系结构，支持负载平衡，可以以伸缩的方式满足大型企业的需求。中心管理站点可以接收从代理程序收集来的信息。通过合并器进行合并执行由处理规则指定的中央操作，如，运行一个脚本或批处理文件，或将检测到的情况通知操作员。合并器还向数据访问服务器(DAS)发送信息。3、系统可以通过统一的操作管理平台对所有的事件进行处理。4、管理员可以定义规则，可以通过预先设定好的操作对指定的时间进行处理反映。并可和微软知识库进行集成，直接得到错误事件的序列号，方便操作人员查询。5、当管理系统捕获、评估各种事件后，可以通过预先配置的手段及时报警，通知系统管理员。报警的手段可以是多种多样的，像呼机、手机、短信等，非常灵活。6、系统可以设置监控主要的性能阀值。可以自定义规则或添加新规则，对系统和应用程序性能趋势进行监控，以用于历史记录报告和能力规划。此外，还可以对本地阀值和集合阀值进行设置，以在系统或应用程序的性能发生变化，需要进行管理干预时做出适当的反应，发出警告并执行适当的操作。7、MicrosoftOperationsManager2005中，管理员创建的规则可使系统自动对入站消息流做出反应，也就是使用预定义的操作对特定的错误方案做出反应，或是将消息合并到更有意义或更明显的事件中。这些规则可使MicrosoftOperationsManager对事件做出智能反应并预见事件的发生模式，触发操作或管理警告。规则还能够将事件序列链接到“Microsoft知识库”文章中，不断向操作人员提供指导，指明可能导致错误的原因、允许对特定问题做出的反应，以及指向其他信息的链接。8、系统提供各类管理软件包，管理软件包由预配置的规则集合和知识库文章组成，用于为特定范围内的应用程序或服务提供规则。这些“管理软件包”由专家开发和提炼，除提供完整的现成解决方案外，还为高级管理员提供了一个坚实的基础，使他们可以自定义和扩展解决方案。管理软件包包括Windows2000、ActiveDirectory™服务、FileReplication服务(FRS)、DNS、WindowsInternetNameService(WINS)、InternetInformationServices(IIS)、DynamicHostConfigurationProtocol(DHCP)、RoutingandRemoteAccess、MicrosoftTransactionService(MTS)、MicrosoftMessageQueuing(也被称为MSMQ)MicrosoftDistributedTransactionCoordinator(MSDTC)、SystemsManagementServer、MicrosoftOperationsManager、TerminalServer、MicrosoftWindowsNT®4.0操作MicrosoftExchangeServer2000、MicrosoftSQLServer™2000和BackOffice应用程序套件(Exchange5.5、SQLServer7.0Microsoft、SiteServer3.0、MicrosoftProxyServer2.0和SNAServer4.0)等。通过这些专门定制的工具包可以对应用系统进行完善的监控，保证系统内部所有功能单元的可用性。9、使用本系统可以访问大量的预配置报告和图表。生成的报告允许管理员检查网络中系统和服务的状态，并基于性能和可用性数据对基础设施实施更改。可在系统中添加一些来自Microsoft或其他供应商“管理软件包”的其他报告，以进一步丰富管理员可用的报表资源。10、对于已生成的报告，MicrosoftOperationsManager2005可为其生成基于超文本标记语言(HTML)的快照。然后，这些快照可以导出到Web服务器，以供Web浏览器及MicrosoftOperationsManager2000、Microsoft管理控制台(MMC)和Web控制台访问。服务器监控管理模块管理包选择设计Microsoft针对不同的产品和功能模块提供多个预定义的系统管理的解决方案，称为管理包模块。现成的管理包模块可直接用于系统监控、管理特定用途，如活动目录、DNS、WINS服务以及MicrosoftSMS2003Server应用环境。管理包模块提供如下功能：特定的处理规则组，计算机组和处理规则，如过滤器、警报、性能采样和阈值原则。预定义的计算机属性、提供者、脚本和知识库，以及公共视图和默认通告组。设定MOM如何收集、处理、响应信息。按照本项目的系统运行管理需求，管理包的选择如下：活动目录管理包组策略管理包FRS管理包DNS管理包DHCP管理包（选择使用）WINS管理包IIS管理包WindowsOS管理包WindowsSharePointService管理包SMS2003管理包MOM2005管理包SQL2005管理包RMS管理包ISA2006管理包服务器监控管理模块报表设计在服务器监控管理模块中报表是一项很重要的功能，它对于帮助管理人员管理维护整个系统具有重要的作用。MOM根据MOM服务器中所存储的信息使用MicrosoftAccess生成报告，之后可将这些报告发布至Web服务器并且可使用MOMWeb控制台浏览。MOMReporting通过MicrosoftAccess运行报告及访问MOM数据库，Access与数据库之间利用ODBC而不是MOM数据服务器进行通讯。为了获取储存在MOM数据库中的信息，MOMReporting利用MicrosoftAccess生成报告，Access利用经Windows操作系统认证的ODBC连接从MicrosoftSQL

Server数据库获取数据。多项MOMReporting可连接至单一MOM数据库并利用其数据生成报告，此项功能有助于不同的管理员监视MOM的不同方面，例如：一个管理员可生成性能及容量的报告，而另一个管理员可生成有关操作的报告。单项MOMReporting也可连接至多个MOM数据库并根据其数据生成报告。对于一台计算机的多配置组生成报告此项功能十分有用。MOMReporting可一次从单个数据库生成报告。 报告服务器策略运行MOM报告服务器需要下列软件：MicrosoftAccess2000及以后的版本-至少启动一次Access供MOM安装程序检测MicrosoftAccessSnap-shotviewer-与Access一起安装MicrosoftOfficeGraphMicrosoftDataAccessComponent2.6及以后的版本Printer–用于存储HTML格式的报告如需频繁生成报告，请勿将MOMReporting安装在MOM数据库服务器上，否则将导致由于生成报告所需的CPU和内存占用影响MOM数据库的性能；将MOMReporting安装在单独的计算机上，报告生成次数的增加仅与网络延迟有关，而不会影响到MOM服务器的性能。在本期工程中建议将中MOMReporting将安装在MOM/网管服务器上，为了能在本地运行报告，Access报告引擎也被安装于该服务器上。如上所述，运行MOMReporting需要占用CPU和内存，因此建议不要在正常办公时间运行报表生成程序，应在非正常工作时间生成报表以避免与日常备份工作冲突。建议：在每天凌晨两点至六点生成日报表；在周六或周日白天生成周报表或月报表；报告发布生成的报表，将被发布至web服务器，要完成此项操作需将MOMWeb控制台安装在DCAM服务器上。存储HTML格式报表的缺省位置为：x:\ProgramFiles\MicrosoftOperationsManager2000\Event\Reports。安装过程中，会在MOM服务器生成一个名为Reporting的虚拟目录。此虚拟目录使用Windows认证，缺省权限为只读(ReadOnly)。由于MOM报告中部分数据的保密性，需要采取如下所述的安全加强措施：取消网络共享：缺省情况下，安装过程中会生成一个名为Reports的网络共享。此共享可被删除而不会影响MOM的功能。设置NTFS许可：报告目录缺省的ACLs设置赋予本地Users组只读权限。建议作如下改变：1、取消对本地Users组的访问权限2、添加并赋予本地OnePointReporting组的只读权限系统技术特点为实现安徽电信ODS系统管理系统的业务处理、资源共享、信息交流，采用了面向对象、消息协作、动态工作流和组件等先进技术，架构层次清晰，紧密结合行业特点，注重易用性、个性化，与同类产品相比，本系统在先进性、安全性、开放性、高效性、扩展性、灵活性、易用性、规范性、实用性等方面均达到较高的水准，具有以下突出优势：先进性.NET平台支持业内各种高级应用、接口技术和标准，使系统平台具有良好的开放性和互集成性。同时，作为主流应用平台之一，.NET也是业内的事实工业标准，是其他技术、系统、应用支持的主要对象之一，可以确保系统在未来相当长的时间内完全适应审计信息化的发展。.NET平台支持业内各种高级应用、接口技术和标准，使系统平台具有良好的开放性和互集成性。同时，作为主流应用平台之一，.NET也是业内的事实工业标准，是其他技术、系统、应用支持的主要对象之一，可以确保系统在未来相当长的时间内完全适应业务发展需要。基于XML的WebService技术，具有跨平台的可互操作性，支持各专业之间信息交换。开放性和标准化本系统采用各种技术，包括系统平台、数据库，都完全符合各种国际标准和国家电子政务标准化指南要求，如XML、WebService等。高效性本系统在技术选型、功能、架构设计过程中，一直以“实用”、“高效”为衡量基准。例如，工作流引擎/业务模式、ASP.NET机制、数据压缩存储与传输、应用系统Cache机制等提高系统运行效率。灵活性与扩展性本系统中所有流程处理过程所采用的“工作流/业务”模式，基于角色的组织架构管理与应用，在审计业务发生变化时，可以通过简单的定制，使系统快速的适应变化。随着业务优化进一步加深，部门之间都存在信息共享、交换和互动。系统采用ASP.NET技术架构、先进的MVC模式、工作流/业务模式、完全的XML与WebService应用，可以方便地在各个层次上实现系统的扩展，保证前期投资的有效和后期投入的接续，最大限度的保证其继承性和经济性。较高的性价比，降低总成本通过采用.NET技术进行系统开发，可以最大程度地重用了系统资源，避免了重复投资。例如，对服务器端系统软件环境的要求就是：在Windows2003Server系统上免费升级Mircosoft.NETFramework即可，无需其他第三方平台软件。因采用B/S系统架构，则无需配置用户端软件，这样将大大节省安装、维护、二次开发等总体拥有成本（TCO），总体费用将降低20％以上。在系统管理与维护方面，通过对系统功能、用户角色及其权限进行个性化的定制，操作简单方便，使得系统能充分满足业务管理的实际需求，而且系统安全性高。系统平台方案硬件平台设计对于硬件设计，我们在设计中主要遵循以下一些原则，并辅以对应的设计：高性能设计在设计中，我们将不同功能的服务器在物理上分开，从而保证应用不互相影响性能；此外，对于性能压力较大的ODS服务器我们配置了6CPU的高端PC服务器，从而有效保证了ODS数据库服务器的性能，以满足接近实时的数据抽取及分析等工作。而ESB系统更注重在业务的实现，对性能要求没有ODS高，因此我们将配置2-4CPU的服务器作为ESB系统各运行模块的服务器平台。高可靠性对于ODS和ESB系统来说，高可靠性稍有不同，ODS是用于后端分析的，而不是联机在线系统，因此可靠性要求没有其它那些在线系统高，而ESB系统是各系统之间的桥梁，一旦ESB投入运营，则ESB系统的可靠性就很重要了。在本次设计中，我们对2个系统都采用了高可靠性的设计。其中ODS系统的3个服务器ETL和ODS数据库服务器相互作冗余。而ESB系统的前端应用服务器采用了2个BizTalk服务器，实现ESB的均衡负载及高可靠性，而后端的SQL数据库服务器则被另外一个备份服务器所备份。因此，在这2个系统中，都没有单点的故障，具有高可靠性。此外，对于BizTalk服务器采用均衡负载的设计可以保证当任意一个服务器发生故障是，业务不会受到任何的影响和中断，这种设计要优于HA高可靠性集群。其他系统采用高可靠性集群的原因是因为数据库的单一性和一致性，只能采用HA高可靠性集群来实现系统的高可靠性。此外，SAN存储设计中，我们采用了双SAN交换机和磁盘阵列，这些设计可以保证存储物单点故障。高可用性及可服务性在整个硬件设计中，我们采用了SAN网络存储的设计，采用SAN网络存储的设计，这种设计使存储硬件和服务器在物理上分离，未来服务器或存储设备上的任何硬件改动都不会影响其它设备的正常工作。而这些设备又都支持热插拔，这也大大提高了系统的高可服务性。而从架构设计中，在ESB系统采用了2个并行的BizTalk服务器，主要是利用了其横向扩展的特点，当任何一个服务器需要服务时，只需要将其拿走，而业务会转移到另一个服务器上，不会受到影响，同样当需要增加BizTalk服务器时，也只要在业务进行时将其加入，这都体现了系统的高可服务性。可扩展性在硬件设计中，我们利用了应用服务器适合横向扩展、数据库服务器适合纵向扩展的特点，对所有的数据库服务器的设计配置都高于相应的应用服务器，这样的话，即使未来业务需求超过本次需求的话，也不需要更换任何服务器。而BizTalk服务器因为可以横向扩展，所以将来业务量超过本次需求时，即使不够的话也只需要添加新的服务器，和现有的服务器共同分担业务压力。通用性、易用性及经济性由于我们的设计是基于.net平台和windowsserver2003基础上的，这就最大程度地保证了系统的通用性和易用性，而这些平台运行在PC服务器上，设备成本和运行成本远低于其它的操作系统计服务器，性价比极高。而且微软公司拥有全球最大的用户群，这可以保证未来技术能力的持续。下图为网络拓朴图ETL服务器服务器作用主要负责数据的抽取(Extract)，转换(Transform)和装载(Load),将分布在各业务系统的数据按照数据建模的要求对源数据进行筛选整合,并将整合后的数据裁载到数据库服务器中。计算测算依据 每个应用系统与ETL的连接操作次数大约为120次/秒，峰值大约为300次/秒。这些操作次数会直接影响到ETL的整个操作过程。 ETL服务主要会涉及到以下操作：从应用系统（目前一共6个主要系统）中获取源数据；将获取到的数据进行抽取(Extract)，转换(Transform)和装载(Load)；最后将处理好的数据存放到运营数据库中。衡量指标指标描述考核目的TPC-C单位为tpmc它的定义是每分钟内系统处理的事务个数。能够并行执行多种具有一定复杂度的事务，强调服务器在一定时间限制范围内的事务处理能力。计算结果计算因素数据值(峰值)数据值(均值)单次消耗tpmc个数描述应用系统2100操作/秒720操作/秒0.5ETL读取数据MSS系统的数据ETL2100操作/秒720操作/秒1对源数据进行筛选整合主数据库2100操作/秒720操作/秒0.5将整合后的数据载入到数据库服务器中合计：2100*0.5*60+2100*1*60+2100*0.5*60=252000tpmc 由于在通常情况下需要有30%的冗余，以保证系统的稳定运行，所以最终的计算结果应为：252000/70%=360000tpmc。选择结果由于需要和多个应用服务器进行交互，这里可以选择三台做为ETL服务器，每个ETL服务器与负责2个以上的应用系统，即每台要求的tcmp值为120000。HPDL380G5可以满足这个要求，同时性价比也是最好的。^

HardwareVendorSystemtpmCPrice/tpmCSystemAvailabilityHP

HPProLiantDL380G5QC

138,979

2.12

US$03/26/07

HP

HPProLiantBL25p/2.6GHz/DC

110,615

3.34

US$05/04/06

HP

HPProLiantML370G5SAS3.0GHz/4MBDC

169,360

2.93

US$11/22/06

运营数据库服务器作用用于存储经过ETL的数据。向各个系统提供数据实时查询、采集、同步应用。向分析数据库提供数据，同步周期为1天。计算测算依据由于系统的数据被ETL处理后，会直接被存放于运营数据库。所以运营数据库的操作直接受到MSS数据的影响。因此可以测算出每个ETL与运营数据库的连接操作次数大约为240次/秒，峰值大约为700次/秒。这些操作次数会直接影响到ETL的整个操作过程。 运营数据库主要会涉及到以下操作：接受ETL处理后的数据（间接从MSS系统（目前一共6个主要系统）中获取源数据）；向各个应用系统（大约15个左右）提供数据实时查询、采集、同步应用；向分析数据库提供数据；BizTalk进行数据操作。衡量指标指标描述考核目的TPC-C单位为tpmc它的定义是每分钟内系统处理的事务个数。能够并行执行多种具有一定复杂度的事务，强调服务器在一定时间限制范围内的事务处理能力。计算结果计算因素数据值(峰值)数据值(均值)单次消耗tpmc个数描述应用系统2100操作/秒1260操作/秒1.5进行数据实时查询、采集、同步应用ETL2100操作/秒1260操作/秒0.5将整合后的数据载入到数据库服务器中分析数据库2100操作/秒1260操作/秒0.5将运营数据同步至分析数据库BizTalk1000操作/秒400操作/秒0.5数据的操作合计：2100*1.5*60+2100*0.5*60+2100*0.5*60+1000*0.5*60=345000tpmc由于通常情况下需要有30%的冗余，以保证系统的稳定运行，所以最终的结果应为：345000/70%=492900tpmc。4.选择结果为了保证数据库系统的高可用性，需要使用两台数据库服务器做群集。每个需要492900tpmc值。HPRx8640具有50万的tpmc值，所以可以选择这个服务器。50万tpmc（12*1.4GhzCPU/36G内存/2*146G硬盘/2*HBA卡）HPRx8640分析数据库服务器作用与运营数据库间同步周期为1天；向EDW输出数据；面向前台的查询统计报表类应用。计算测算依据分析主要是每天同步运营数据库中的数据，然后将这些数据根据前台报表的需求生成报表，输出到用户端。同时也可以将数据输出到EDW。分析数据库会牵涉到以下操作：从运营数据库中同步数据；为前台生成报表；向EDW输出数据。衡量指标指标描述考核目的TPC-C单位为tpmc它的定义是每分钟内系统处理的事务个数。能够并行执行多种具有一定复杂度的事务，强调服务器在一定时间限制范围内的事务处理能力。计算结果计算因素数据值(峰值)数据值(均值)单次消耗tpmc个数描述应用系统300操作/秒50操作/秒5ETL读取数据MSS系统的数据运营数据库2100操作/秒1260操作/秒0.5从运营数据库中同步数据EDW500操作/秒200操作/秒5向EDW输出数据合计：300*5*60+2100*0.5*60+500*5*60=303000tpmc由于通常情况下需要有30%的冗余，以保证系统的稳定运行，所以最终的结果应为：303000/70%=432900tpmc。.选择结果分析数据库所要的tpmc值为432900，可以采用和运营服务器同样的配置。HPRx8640具有50万的tpmc值，所以可以选择这个服务器。50万tpmc（12*1.4GhzCPU/36G内存/2*146G硬盘/2*HBA卡）HPRx8640存储容量运营数据库主要存储从各个系统中提取的主数据，以及主业务单等。源数据项计算依据容量(G)单位人力资源员工、组织、岗位、角色等相关信息0.1日财务系统会计科目及其相关主数据现金流量项目及其相关主数据资产及其相关主数据关联交易类型及其相关主数据成本中心及其相关主数据预算中心及其相关主数据网络元素及其相关主数据用户类型及其相关主数据产品类型及其相关主数据作业类型及其相关主数据……0.4日计划建设系统工程项目及其相关主数据专业类别及其相关主数据供应商及其相关主数据……0.4日物资管理系统物资主数据及其相关主数据库存地点及其相关主数据……0.5日综合审批系统合同及其相关主数据……0.3日固定资产系统资产及其相关主数据……0.3日存储内容计算依据容量(G)源数据每日数据量*24*30（两年的估算时间）1440历史数据各个系统中已有的数据400ETL中转表源数据*10%144中间表源数据*25%360聚合事实数据源数据*50%720聚合维度数据2多维立方数据聚合事实数据*30%432数据挖掘数据100系统自身占用100冗余空间400小计