据我了解的一些企业，这最近几年企业信息化过程中系统没有少上，什么
ERP
，
PDM
，
CSM
，
DSERP
等算起来将近有七八套，在一定程度上提高了企业的信息化管理水平，但是又迎来了另一个问题。企业的许多数据在不同的系统中需要维护，经常会出现不同的系统间数据不一致的问题，这就需要各系统之间进行集成。由于各系统架构不一致，所以目前采取的方式主要是数据级别的集成。
我总结了一下，根据实时性数据集成可以分为两种，实时性和非实时的。目前采取的方案是非实时的，对于各系统间需要整合的数据，是由一个系统定时导出成
xml
格式的数据，然后由另一个系统定时来处理。非实时的系统比较容易实现，不好的地方就在于不能实时实现各系统的无缝集成。而实时的系统数据集成就可以采用数据库层的直接集成或者通过面向服务架构（
SOA
）来实现，对于不同厂家的产品，开放数据库接口给其他厂商一般来说不太好接受，就是一个公司的各个产品之间项目开放接口也比较难接受，个人感觉未来发展的趋势主要还是利用
SOA
来实现数据集成。
关于
SOA
，业界这两年炒得很火热，很多公司
IBM
，
SAP
，
Oracle
等都给出了自己的解决方案，方案多了让人眼花缭乱，也不太好选择，不过在
Oracle
公司收购了
BEA
以后，他们在服务器
+
数据库上的优势使得他们的方案跟其他公司相比占了不小优势。
下面是我收集整理的一点对
Oracle
的实时数据集成方案的资料，跟大家分享一下。
实时数据集成一般分为两个处理过程：一是对数据按照
SOA
架构的需要进行整合加工形成可用的信息，二是将信息以符合
SOA
规范的方式发布出去。具体的实时数据集成模式可以按照对这两个处理过程的不同分为以下四种：
第一种是在
中间件层上进行数据的加工整合，同时通过中间件层的标准接口将整合后的数据以标准接口发布。
在中间层上存在一个虚拟的数据服务层，该层通过
JDBC
，
FILE
适 配器、应用适配器等与数据层的各种数据源实现连接，将数据源中的各种数据实体映射成中间件的虚拟数据层的表，虚拟数据层中的表都只有元数据，而不存储实际 的生产数据。用户可以在虚拟数据层上采用可视化图形界面定义数据映射关系，进行数据加工整合，这些数据加工逻辑一般会以文件或者
数据库
方式存储。定义好的数据可以通过
web service
，
JDBC,
数据对象等多种方式发布出去。当用户通过中间件访问虚拟数据层的数据时，虚拟数据层会根据系统定义的逻辑首先将需要加工的细节数据从各个数据源抽取到虚拟数据层，然后中间件根据设计时的数据加工逻辑对其进行加工，最后中间件将加工好的数据以调用接口要求的格式返回。
1.
处理都在中间件服务器上，相对来讲，对数据的处理会比较灵活，应用和底层的数据实现松耦合。
2.
当一个请求涉及到多个底层数据源时，对底层的数据访问可以采用并发方式进行。
3.
借助中间件的灵活性，数据可以采用多种方式对外提供接口，从而大大方便各种应用的开发。
4.
所有的数据都是实时从数据源取来，保证数据的时效性。
这样做的问题是数据的处理在中间件层进行，一是带来从数据源到中间件层的数据传输，二是中间件一般都是
J2EE
架构，其强项并不是数据处理，在数据量不大时并无大碍，当数据量非常大时，其实现机制就注定了效率会出现问题。
第二种是在
数据源层负责数据的加工处理，然后将整合后的数据以标准的接口发布到中间件层，由中间件层负责数据的访问。
这种处理方式一般是
数据库
厂商或者
ETL
厂商推荐的方式，根据用户的业务需求逻辑，首先在数据源层通过
ETL
工具
设计
数据转化流程，然后将流程的转化逻辑发布成
web
服务，同时将转化后的数据也发布成
web
服务，然后将这些服务注册到中间件层，当前端用户需要数据服务时，它需要调用两个
web
服务，第一个是转化
web
服务，该
web
服务调用相应的
ETL
工具对数据进行整合加工，然后将整合的数据存储在临时表中。第二个服务是调用数据服务，直接从临时表中取出加工后的数据，与第一种模式的区别在于，它将数据的加工处理放在了数据源层，其优势在于：
1.
ETL
工具天生就是做数据整合的，而且适合大数据量的整合，所以针对大数据量效率会非常高。
2.
在数据源层整合可以充分利用数据库的处理能力，毕竟数据库才是做数据处理的行家。
3.
依靠
E-LT
工具的变化数据捕捉功能，可以进行增量数据的处理。
4.
数据转化和数据获取松耦合，可以实现异步处理。
1.
由于数据的加工处理依赖于数据库的处理能力，因此在所有的数据源中，必须有一个为关系型数据库系统，而第一种模式由中间件负责数据处理，数据源没有限制。
2.
在应用的流程设计中，需要调用两次
WEB
服务，一次为转化，一次为取数据读取，数据量非常小的情况下，有点画蛇添足的味道。
第三种是
将分散在数据层的数据先整合到
ODS
或者数据仓库中进行整合加工，然后再将加工整理后的数据以标准接口发布到中间件层。
为了保证为企业提供一个全局的数据视图，我们可以通过建立一个全局的操作型
数据库ODS(operational data storage)
，该数据库与企业内的其它数据源通过变化数据捕捉（
change data capture
）方式保持实时同步，当数据源内的数据发生变化时，
CDC
会捕捉到变化的数据并通过
ETL
工具或者其它手段（如主数据
管理
工具）同步到
ODS
数据库中。
最后一点就是数据的发布格式，在该模式中，中间件层负责数据的接入访问，
ODS
里的数据可以封装成
WEB
服务发布在中间件层。当前端业务流程需要集成的数据时，可以直接访问
ODS
内的数据，如果数据集成比较复杂，我们可以根据用户的业务需要，通过
ETL
工具或者其它工具（第二种模式）对统一模型层的数据进行加工放到汇总数据层，然后再从汇总数据层访问数据。
第四种是
采 用数据网格的方式将数据层的数据整合在中间层，形成数据网格，中间件负责数据的加工，整合，然后以标准的方式发布出去。它和第一种方式非常相似，数据的整 合加工和发布都在中间件层上，唯一不同的是我们采用数据网格技术在中间层增加了一层对象缓存层，数据的整合加工和访问接入都发生在中间件层，当客户端访问 数据时，所有的流程方式都和第一种模式没什么区别，但需要访问的数据都通过数据网格层缓存在了中间件层，因此减少了数据源访问和网络传输的时间，访问速度 会大大加快，从而可以在一定程度上解决第一种模式的不足，但数据处理仍然发生在中间件层，如果中间件处理能力有限，系统的效率还会受到局限。
1.
系统扩展性好，数据网格层的扩展性决定了整个系统的扩展性。
2.
当机器的处理能力不足时，通过集群方式可以大大提高性能。
3.
真正实现了前台数据与后台数据源的松耦合。数据网格负责与各种后台数据源的交互。
2.
如果应用已经上线，需要针对数据网格提供的接口修改应用。
以上四个模式各有自己的应用范围，从总体上看，数据的处理越靠近底层，效率越高，灵活性越差；越往上走，效率越低，灵活性越好；其实各种数据集成模式无所谓好坏，关键是看业务需求，只要能够满足业务需求就够了。
本文转自 牛海彬 51CTO博客，原文链接：http://blog.51cto.com/newhappy/136076，如需转载请自行联系原作者
