数据集成
1. 数据集成系统现状
企事业内部有不少的应用系统，比如财务系统、人力资源系统、工程管理系统（项目管理、采购管理、库存管理）、管理数据统计系统和企业信息门户。这些系统一般都有不同供应商提供，他们之间的信息有重叠和不一致显现存在。因此很容易产生下列的问题：
1.1 基础数据多头管理，系统间数据一致性差
对于同样的问题，每个不同的系统都维护有自身的数据结构，例如在工程管理系统中存在供应商数据，而在物资系统中也存在供应商数据，这两个系统对同一个供应商可能存在不同的编号、不同的命名等等。这就导致了两个系统间没有数据标准，在工程管理系统中更新了供应商数据后，物资系统无法依据指定的规则进行同步更新，造成了企业主数据的混乱局面，难以满足快速支撑精确管理的需要，使得企业的运营效率和管理水平难以进一步提升。
1.2 接口没有实现统一的接口平台
由于没有统一的企业主数据，目前系统接口均采用点对点方式，技术实现方式多种多样，例如最多的方式是数据库直接存取，接口双方需要明确知道对方的底层数据结构，这导致了完成和维护这些接口是一项非常艰巨的任务，并且在不同的供应商之间难于明确自身的责任，出现问题之后相互推诿。
1.3 企业内部信息难以完整统一和共享
由于现在的应用系统是由不同的供应商提供，基础数据难以同步更新，各自产生的数据信息，都成了一个个的信息孤岛，彼此之间的数据难以共享。企业不容易获取汇总信息。
2. 数据集成需求分析
接下来我们从业务和系统两个方面来分析数据集成的需求：
2.1 业务需求
2.1.1 统一用户视图的提供及展示
企事业应用系统给用户提供各种服务，需要在各个应用系统上提供及展现统一用户视图信息，通过数据集成实现统一用户视图信息的共享，支撑多个层面快速准确地获取用户和产品信息，提升用户感知。
比如在营销、销售、服务中，提供营销人员营销活动所需的市场统计数据和目标用户数据，以便进行精确化营销；提供销售人员单一用户视图信息及其统计数据的即席查询，以发现用户需求，增加
销售机会；提供服务人员跨系统数据的支撑，以进行用户分等级服务、用户增值业务，订购信息快速查询和退定等工作。
2.1.2 统一企业运营报表的提供和展示
CRM、计费等生产系统分别按照本系统的自有数据向外提供运营报表，不同部门对数据的时间和业务概念理解不一致，造成不同系统的报表有差异，同时手工进行报表拼凑也会造成差异，于是产生了不同部门有差异，不同组织层级有差异，而且大量按需的对外报表提供对生产系统性能影响很大，不利于生产系统对其核心事务处理的稳定运行。因此通过数据集成，统一企业运营报表的数据源，形成统一的指标体系，并通过统一的企业数据应用门户，实现企业运营报表的统一提供和展示，实现多纬度的报表需求，以支撑精确化管理需要。
2.1.3 支撑企业运营过程的统计、监控和考核
全过程的营销支撑需要对市场计划、营销活动、销售活动等各项工作事前预期，事中监控，通过数据集成，基于从各生产系统搜集到市场营销与销售的相关信息，对市场营销与销售业绩完成情况进行统计，并通过用户发展、业务量、收入等关键绩效指标和实际完成状况的关联，完成对各部门、团队或渠道的KPI指标进行监控与考核。
2.1.4 支撑企业运营过程所需跨系统数据的批量计算
为了更好地支企事业工作的开展，提升用户管理能力，需要建立用户积分、信用度等用户评价体系；为了实现用户品牌维度，对相关量收指标进行统计；为了，发展优质用户，需要复杂、完善的渠道佣金计算支持；随着产品为中心向用户为中心的转型，越来越多运营过程所需的跨系统、大量细节数据的批量计算需求都需要统一的数据集成中心提供相关数据。
数据集成中心作为企业运营数据共享平台，收敛企业各业务系统中的运营数据，按照企业数据模型进行数据整合，提供运营数据共享，支撑跨系统数据的应用，提升数据质量。
2.2 系统需求
2.2.1 实现数据统一
数据集成中心在对企业数据的整合过程中能够实现以下三个统一：
1.统一数据模型
由数据集成中心承载企业数据模型（EDM），促进企业各域数据逻辑模型的统一。在企事业内新建或改造的系统，其数据模型应向数据集成中心所承载的企业数据模型靠拢。数据模型是各个系统及应用间交互的基础，通过数据模型的统一，减少系统及应用间复杂的转换，提高系统、应用、接口的效率。
2.统一数据标准
数据集成中心中建立标准的数据编码目录，源系统数据依据标准的数据编码目录，经过整合后进入数据集成中心存储，实现企业数据的标准化与统一存储。
3.统一数据视图
基于数据集成中心所存储的数据，支撑实现统一数据视图，使企业在用户、资源等视角获取到的信息是一致的，提升用户、以及企业内部的管理人员与分析人员对系统的感知。
2.2.2 实现数据共享
数据集成中心为企业各业务系统提供统一共享数据接口，减少系统间相互接口的重复性，降低接口的复杂程度，提高系统间接口效率与质量；为跨系统数据应用提供数据支撑。数据集成中心作为企业运营数据共享平台，是各业务部门和企业管理层获取统计数据的唯一来源。
数据集成中心可将某个生产系统的数据以准实时地方式存储转发至其它对数据实时性要求不高的生产系统，以减少生产系统间的网状接口。
数据集成中心以实时的查询服务或准实时批量的数据提供的方式将数据集成中心内整合或计算好的数据向外部系统提供，以配合外部系统支撑统一用户视图查询、用户服务流程等功能。
2.2.3 实现数据应用
数据集成中心利用自身系统的数据提供以下几类功能：
1.查询应用
实现查询条件不固定的按需查询功能。用户可以根据关心的维度查询数据集成中心内整合好的360度业务全貌数据，如，为渠道经理提供完整用户视图信息的查询，为用户提供完整用户视图查询、用户账单查询等。
2.固定报表应用
固定报表是维度和指标固定的统计结果的展示，在数据集成中心内对于实时性要求高的报表采用即时生成的模式，而对于实时性要求不高的报表，基于性能影响和资源开销两方面的考虑，应采用后台通过作业的方式先自动生成，在需要时可以立即展现结果。
报表展现应支持多种图表方式，如饼图、柱图、线图等；支持报表数据导出为其他文件类型，如EXCEL、CSV、XML、PDF、WEB存档文件等；支持报表精确打印控制。
3.动态报表应用
基于数据集成中心整合好的数据，可以利用报表工具，按关心的维度和指标对数据进行主题性的统计，动态报表应用中，维度和指标不固定，可在数据模型支持的范围内变换。在数据集成中心上可实现多种动态报表。
4.计算应用
数据集成中心可基于整合好的数据按照设定好的业务规则进行部分属性数据计算，计算结果并不在数据集成中心内直接更新，而是由数据集成中心返回到该属性数据的属主生产系统，由属主生产系统完成该属性数据的更新后，再通过数据抽取、加载过程进入数据集成中心之后更新。
2.2.4 实现数据质量管控
数据集成中心在数据收敛的过程中，能完成以下数据质量管控工作：
1.数据质量校验
根据规则对数据集成中心所存储的数据进行一致性、完整性、正确性的校验，形成数据校验结果并交付源业务系统进行修正。
2.数据质量管控
通过建立企业数据的质量标准、数据管控的组织、数据管控的流程，对数据质量进行统一管控，达到数据质量逐步完善。
3. 数据集成目标
通过数据集成，数据集成中心应该能达到以下几个目标：
3.1 建立规范统一的指标体系
根据企业的业务实际情况，建立面向企业指标体系的数据接口，用于收集企业各系统间的指标数据，同时为企业各系统提供所需的指标数据，成为沟通企业现有系统和未来系统之间各种关键业务指标数据的信息桥梁。
3.2 统一的数据采集接口
建立统一的数据采集接口，根据企业实际业务需要，定义符合企业需要的数据采集指标，通过企业数据业务平台统一的进行数据采集，改变原有层层下达参数，再层层汇总、层层过滤，时效性和准确性亦难以保证的问题。
3.3 统一的数据存储中心
通过企业规范的指标体系，收集和整合相应指标数据，存储到数据集成中心。按照统一指标、统一统计口径和统一数据概念的要求，存储指标数据和建立数据存储中心，满足不同系统之间相互获取数据的要求，同时为数据的综合分析和历史回溯奠定数据基础。
3.4 历史数据的回溯分析
基于规范性与灵活性相结合的原则，通过对数据存储中心的历史数据进行提取和加工整理，采取
分级用户具有分级权限，在权限范围内灵活使用数据，进行分析和查询，可以为管理决策者在生产管理和经营决策上提供科学有效的历史数据依据。
3.5 建立数据应用接口
企业在生产经营决策过程中，通常迫切需要了解企业外部的实际情况，所以需要打通企业与外部的数据壁垒，实现彼此之间数据共享。
这种需求通过建立企业与外部之间特定的数据应用接口，一方面，从外部抽取企业需要的特定商业指标数据，另一方面，提供外部所需的企业指标数据。通过二者数据之间的充分对比分析，实现数据之间的数据共享，提高现有系统的数据使用率和有效地提高数据支撑能力，为管理层的经营决策提供坚实可靠的依据。
3.6 建立统一的决策分析管理平台
通过对采集的基础数据信息的提取和加工整理，本着规范化与灵活性相结合的原则，设定不同的使用权限（组织和人员），灵活使用数据，进行分析和查询。系统统一下发固定报表模板，同时用户可根据个性化需求灵活定制报表，提供决策支持。
4. 数据集成思路
通过前面的需求分析，我们可以整理出我们的数据集成思路，从而设计合理的数据集成方案。数据集成系统对于企事业的长远发展来说，应该是处于企业应用系统与企业数据仓库系统之间的。企业的一系列数据中，一部分是实时性要求非常高的，必须要求能实时的更改存放在多处的同一份数据；而有一些数据则实时性的要求不高，不需要实时地进行修改而是定时进行相应的同步即可。ODS的思想结合ETL与ESB等相关技术，实现这一套数据集成系统是比较合适的。
4.1 通用ODS架构分析
ODS（Operational Data Store），运营数据存储或者操作型数据存储，存储了运营系统（OLTP，联机事务处理系统）近实时的详细数据。ODS是企业数据架构中最为复杂的一种形态，它既要满足数据事务操作要求，又要满足数据分析要求。它是“一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求”，常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。ODS的引入是为了寻找能满足快速加载和数据整合的性能要求，并且减少面向分析的需求的变更和扩充对业务系统的影响的解决方案。这一解决方案是在业务系统和EDW中的按主题存储的历史数据存储层之间增加一个数据整合层（也叫做数据缓冲层）。数据整合层的作用主要体现在以下两个方面：
●数据结构和处理流程是以快速从业务系统中加载和整合数据为目的设计实现的，因此尽量减
少复杂的数据转换，只对原始数据进行清理和整合，这样，可以满足快速加载和数据整合的性能要求。
●另一方面，当面向分析的业务需求变更和扩充需要对数据仓库中的历史数据进行主题重组或
增加新的数据时，所需数据将会先从数据整合层中提取，只有数据整合层也不能满足其数据需求时，才会从业务系统中提取数据，这样就减少了分析需求变更和扩充对业务系统的影响，数据整合层起到了一个数据缓冲的作用，同时提高了数据仓库系统对于需求广度和深度扩展的适应性。
我们认为，ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。
一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：
1）在业务系统和数据仓库之间形成一个隔离层。
一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS 用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。
2）转移一部分业务系统细节查询的功能
在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。
3）完成数据仓库中不能完成的一些功能。
一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。
PC PC PC
在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。
目前市场上没有成熟的MDM(Master Data Management)产品，并且在微软的技术路线中，数据库元数据的概念已经被废除，现在推荐的方式仍然是以合理的方式建立数据库表或者视图的方式来满足ODS数据结构的定义，最终的数据结构是否灵活好用依赖于详细的设计，其中需要考虑地问题包括如下几个方面：
规范性
在ODS系统中，对同一个概念的对象必须按企业领域的标准方式处理，比如，区别供应商必须按
照他们的税务登记号，而不是名称。
●灵活性
当业务需求发生变动时，ODS主数据结构应该能够快速的适应这种变化。比如：可以为一个员工建立基本的员工信息字段，当员工信息增加时就相应地增加员工表的字段；也可以在一开始就为员工信息表多创建一个XML字段用来保存今后可能产品的员工信息增长的情况。两种不同的设计方式必须根据实际的应用情境进行选择。
●关联性
同一业务对象在不同的系统中将被关联到不同的业务对象，ODS必须建立完备的数据结构用于存储一个对象与其它对象发生的所有关联。例如，员工在人力资源系统中被关联到部门，而在物资系统中被关联到采购管理员角色，新的需求是取得某部门的采购管理员。ODS的数据结构设计必须能够满足新出现的类似需求。
4.2 通用ESB架构分析
基于SO思想的A企业服务总线（ESB），是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务协调运作，实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途: 电信领域
ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。
电力领域
ESB能够在全方位支持电力行业EMS的数据整合概念，是理想的SCADA系统数据交换平台。
金融领域
ESB能够在全方位支持银企间业务处理平台的流程整合概念，是理想的B2B交易支撑平台。
电子政务
ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。
ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（服务）和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。ESB专门用于异构环境，既可以帮助企业迁移到SOA，又能够让企业继续利用现有的已部署的软件投资。
通过使用ESB，以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。更重要的是，充当“缓冲器”的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用程序可以同时使用同一服务，用不着在应用程序或者数据发生变化时，改动服务代码。
进行数据的集成，一般按以下三个阶段来进行：
1.把原有应用系统需要进行集成的业务功能先进行标准的封装，如采用web service 进行
封装，然后以标准的结构文档，如XSD,确定接口输入输出的数据格式.
2.部署ESB中间件产品，并进行ESB上相关功能调用的开发，把原有应用系统封装好的接口，
接入到ESB中，形成一种服务。
3.门户或外部的系统，通过调用ESB上的服务与后台应用系统进行交互，从而完成特定的功
能。
4.3 数据集成阶段划分
通常一种比较理想的方式是建立一份统一的企业主数据（Master Data），它兼容现有的系统和可预见的系统的建设需求，并使之在不同的系统间共享。这个过程分为三个步骤：
第一，建立企业主数据结构，即ODS的基础数据结构；
第二，第二步，基于ETL平台，建立数据抽取任务，从现有的系统中抽取必要的数据（并清洗）填充ODS数据库，有需要的话也可将ODS数据推送到各个业务系统中；
第三，基于ESB平台，暴露ODS数据对外的访问接口，并不断的建设各个系统之间的接口。
4.4 数据集成效果
●主数据整合，通过ODS（共享管控数据集成中心）、ESB（企业服务总线）基础平台的
搭建，规范系统主数据，实现企事业内各系统、以及EDW间的数据交互和共享，保证
数据一致性；
●统一系统接口，通过ESB与多个核心平台搭建接口，实现核心系统接口统一。
●主数据管理，提供对主数据变更、维护功能。
●业务数据抽取整合，并提供数据管理、查询、分析、统计等应用功能。使得企业数据仓
库逐步改为从ODS取数。所有的统计分析需求按其涉及数据范围大小和复杂程度高低，
分别由应用系统、ODS和数据仓库提供支撑，尽可能向ODS和数据仓库集中。
5. 数据集成方案
5.1 ODS系统设计
5.1.1 现阶段ODS系统设计
如上图所示，我们设计的ODS系统中，主要有ETL模块和ODS模块2部分组成，ODS系统根据通过Trigger、应用、批处理、Queue等手段从各MSS应用系统中获得数据，并通过ETL应用对数据进行抽取、转换、清洗、并装载到ODS数据库中。而一般通过Trigger Updates的方式来将一些ODS数据返回更新各MSS应用的数据库。
ETL模块
这里的ETL模块主要是数据抽取、转换和加载，这是数据由数据源系统向ODS加载的主要方法
●数据抽取
从数据源系统抽取数据仓库系统所需的数据，数据抽取采用统一的接口，可以从数据库抽取数据，也可以从文件抽取。对于不同数据平台、源数据形式、性能要求的业务系统，以及不同数据量的源数据，可能采用的接口方式不同，为保证抽取效率，减少对生产运营的影响，对于大数据量的抽取，采取数据分割、缩短抽取周期的原则，对于直接的数据库抽取，采取协商接口表的方式，保障生产系统数据库的安全。
●数据转换
数据转换是指对抽取的源数据根据数据仓库系统模型的要求，进行数据的转换、清洗、拆分、汇
总等，保证来自不同系统、不同格式的数据和信息模型具有一致性和完整性，并按要求装入数据仓库。
数据加载
数据加载是将转换后的数据加载到数据仓库中，可以采用数据加载工具，也可以采用API编程进行数据加载。
ODS数据库模块
操作数据存储ODS（Operation Data Storage）是一个集成了来自不同数据库数据的环境。其目的是为终端用户提供一致的企业数据集成视图。它可以帮助用户轻松应对跨多个商业功能的操作挑战，是面向主题的、集成的、近实时的数据存储。
设计ODS层的目的在于改善了对关键操作数据库的存取，获得收益、用户等主题的企业级完整视图，有利于更好地通观全局。近实时的数据存储提供了查询与服务能力，并以更高的性能生成操作报告。设计ODS的核心是实现焦点主题全局试图应用，如企业的用户管理系统，可以建立以用户为中心的ODS用户主题视图，向上层提供高效的服务。
因此，在现有设计中，我们将配置2个服务器分别运行ETL应用和ODS数据库，由于ODS数据库即具有数据仓库的功能，也具有一定OLTP应用的特征，对性能要求较高，因此我们建议配置1个6CPU的PC服务器作为ODS数据库服务器，另一个4CPU的PC服务器作为ETL服务器。从高可靠性出发，这2个服务器将作HA高可靠性冗余。相关数据将放在SAN网路存储中，冗余后的逻辑大小为3TB。
5.1.2 未来ODS系统设计
对于未来的ODS系统设计，我们认为可以引入MDM的设计，但通过ODS来自动修改的数据库结构也应该仅针对新开发的应用，即根据新开发应用的需来对数据库的结构进行修改。而不应对一个正常运行的应用系统进行任何的改变。
5.2 0DS系统架构
ODS系统是介于DW和OLTP系统之间的系统。历史事实证明，只有将各个系统的数据综合在一起才能真正反映出企业管理需要的数据或者报表，而对这些数据的要求是近乎实时的。通过整合现有系统的数据和流程。使ODS系统作为所有应用系统交互的平台，通过ETL和ESB两种技术对现有数据进行整合：
各个应用竹编，如人力资源、财务管理等将通过企业服务总线平台（ESB）进行交互，ESB也作为其它可能与应用系统交互的统一接口；另一方面，数据抽取传送平台（ETL）负责将各个子系统的数据抽取出来（拆分、合并、映射）装入到ODS系统中，那么ODS系统在具备了各个子系统的近实时数据之后，就可以作为独立数据源对外提供数据服务，它可以作为数据报表和分析的数据源，也可以作为其它子系统相互同步的数据源。
这样做有两个好处：
转移了本属于各系统的信息查询负载到ODS系统，使各系统的压力降低，提高了整体性能。
●OMS由于拥有了完整的主数据，它为面向主题的分析提供了必须的数据基础。
5.3 ODS 数据模型
ODS终极目标是为了提供非战略性的中层决策支持，我们认为ODS的数据模型可以参考数据仓库（DW, Data Warehouse）的基础模型，即将数据分为事实数据和纬度数据。事实数据一般代表的是业务变动记录，在MSS中我们称为业务数据，而纬度数据则存放事实数据中业务发生的对象主体信息，纬度数据称为主数据。事实数据和纬度数据的关系是通过关键字来关联的，在数据库中它们都体现为数据表的形式。以下为ODS的数据模型图：
图表1ODS 数据模型
在上图中纬度是维持各系统数据的一致性描述，而事实表则是提供分析使用的基础数据。
在确立了基本的数据模型之后，如何确定数据的采集的范围呢？首先从构建企业全局视图出发（即面向主题的分析），查出每个主题需要哪些数据，这些数据分别分布在哪些系统中，当这一切确定之后，那么整个ODS数据模型牵涉到的数据范围就基本确定了。接着需要通过ETL工具将各系统中的业务数据转换后装入到ODS数据库中，转换方式大致分为四种：
●迁移：一般性的数据拷贝方式，源和目标的数据属性和值完全相同。
●组合：例如将供应商所处的省份、市、街道组合为ODS中的地址字段。
●拆分：例如将员工姓名拆分为单独的姓和名字段。
●映射：例如将合同的“完成”状态映射为“OK”态。
当数据从MSS子系统转换到ODS系统时，数据质量依赖于ETL平台，ETL平台提供完整的事务、容错、补偿、容错和日志功能用于控制数据转换的质量。
5.4 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实际上是一个面向服务的消息调度平台。
5.5 ODS 数据安全性控制
从上文的系统架构设计可以看出，ODS作为数据集成中心，可以被各个系统通过不同的途径读取或者改写，最主要三种方式是：
●各系统直接读取ODS的数据结构；
●各系统通过ETL平台读取或者改写ODS系统数据；
●各系统通过ESB平台发出请求消息，导致ODS的数据被请求或者改写；
对于这样一个庞大的系统的数据安全控制，我们认为最重要的是先创建一份安全审计的规则表，即通常所说的CRUD（C, Create；R，Read；U，Update；D, Delete）权限矩阵，下表为矩阵的模版：
上表演示了ODS系统中的关于供应商实体数据在不同的系统中发起的各种操作的情况下，所能执行的数据访问权限。具体的CRUD权限矩阵将根据实际的业务需求制定。
5.6 数据管理
由于用户的需求和场景是经常变化的，因此满足个性化的定制将变的非常重要。目前数据应用在个性户定制方面主要表现在：虽然定义了模型，但模型不完整，效果不好。这样用户在使用时，不能根据其需求动态的调整后端的业务规则和运行环境，不利于用户的使用。所以需要提供一个灵活的数据模型管理，以及业务规则管理，来应对系统的变化。
●数据模型管理
提供可视化的数据模型编辑工具，支持以下几种数据模型抽取模式。
1、主扩展模式
通常用来将几个相似的对象的共有属性抽取出来，形成一个“公共属性表”。例如：一个员工的基本信息由角色信息、组织信息、岗位信息等部分组成。
2、主从模式
描述两个表之间的主从关系，从而形成的“一对多”关系。例如：一个项目对应多个计划阶段。
3、多对多模式
描述对象相互不分主次、地位，互为一对多的关系。例如：一种器材可以对应多个领料单，一个领料单也可以对应多种器材。
流程、规则管理
提供可视化的流程编辑工具、流程定义和流程监控功能。提供函数集提供常用规则方法，以及规则定义语言描述规则。提供基本规则：
1、直接映射
原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算。
2、数学运算
数据源的一个或多个字段进行数学运算得到的目标字段，比如：合同里的支付计划由多个时间段和支付比例组成，由此得出其总的合同支付时间和支付金额，这种规则一般对数值型字段而言。
3、参照转换
在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。这个关联数组使用Hash算法实现是比较合适也是最常见的，在整个ETL 开始之前，它就装入内存，对性能提高的帮助非常大。
4、字符串处理
从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值，以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。
5、空值判断
对于空值的处理是数据仓库中一个常见问题，是将它作为脏数据还是作为特定一种维成员？这恐怕还要看应用的情况，也是需要进一步探求的。但是无论怎样，对于可能有NULL值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，目前我们的建议是将它转换成特定的
值。
6、日期转换
在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、6位月份值等。
7、日期运算
基于日期，我们通常会计算日差、月差、时长等。一般数据库提供的日期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必须有一套自己的日期运算函数集。
8、聚集运算
对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为SQL标准中，包括sum，count，avg，min，max。
9、既定取值
这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值
5.7 主数据管理
我们的系统必须要能保证基础数据的数据模型、编码规范的稳定性。这样才能为其他各个系统提供准确统一的数据。但是即使在稳定的数据也有会发生变更的可能性，甚至会被要求删除。但是如果直接变更或是删除，会影响到各个业务系统的使用。所以必须采取一定的措施来避免这样的问题。
5.7.1 主数据变更
在与相关部门沟通协调后，如果主数据仍然需要变更。我们将把主数据更新成新的版本，并同时通知各个业务系统，同时将继续在一定时间内维持旧数据的版本。使各个系统有时间来变更和接受新的主数据。
当变更完成后，旧的主数据版本将会被移除。如下所示：