流水线处理技术在数据集成中的应用

3 性能测试与分析

与流水线处理方法相对应的一种方法为同步方法，即通过查询先将底层信息源的结果组装在一起，一次传给集成端处理。由于采用的都是对象数据块的形式，因此用于与流水线对比的同步方法的算法思想为：

(1)客户端发送带全局查询QID（该查询QID为全局唯一的，通过客户端API自动生成）的SQL查询命令(结果查询重写)，并通过通信平台将该查询命令放入服务器端执行队列中；

(2)服务器端接收到查询命令，执行查询，将所得的结果存放于文件中，然后一次发送给客户端；

(3)客户端接收到关于本次查询结果集的文件，然后处理该结果集文件。

将基于内存控制的流水线处理方法与同步方法在以下实验环境下进行测试对比，为减少误差，多次测试得出平均值，有如下数据：

监视器端与集成端采用相同配置环境，相关配置为：
CPU：Intel(R) Core(TM)2 Duo CPU E4500 @ 2.2 GHz；操作系统：Windows XP；内存：2.0 GB；数据库：Oracle 9i；JDK版本：1.6.0_07；开发工具：Myeclipse6.5。

本实验性能测试如图3所示，可以看出，与传统的同步方法相比，采用本文算法具有较好的性能特性，主要在于基于内存控制的流水线处理过程是一个监视器端与集成器端并行流水线运行的过程，并充分应用了现在多处理器多线程处理的技术，减少了集成端空闲等待的时间。

设查询信息源并包装所有数据成公共类型数据块的时间代价为Cost(Q)，传输放入文件中的所有数据块到集成端的时间为Cost(T)，集成端将传输过来的数据解析并初始化到数据仓库的时间为Cost(P)，则基于同步方法的时间代价为：Cost(Q)+Cost(T)+Cost(P)。

设查询信息源并包装查询的数据成公共类型数据块为一块的时间代价为：Cost(Q1)，传输其中一块数据块到集成端的时间为Cost(T1)，集成端将传输过来的一块数据块解析并初始化到数据仓库的时间为Cost(P1)，因为这里数据块是个固定的常数，则基于本文的算法的时间代价为：Cost(Q1)+Cost(T1)+Cost(P1)+max(Cost(Q)-Cost(Q1)，Cost(T)-Cost(T1)，Cost(P)-Cost(P1))，其中max为各处理逻辑减去初始处理的最大时间。

从上面理论上可以分析得出，基于内存控制的流水线处理技术较同步技术可以更好地提高效率。同时还存在几个问题：

(1)当集成端需要OLAP查询或实化视图初始化比较多时，仍然会出现内存溢出的问题，这时可以应用线程池技术[4]，有效控制这类线程运行的数量，同样，监视器端也使用这种方案。

(2)当集成端与监视器端进行流水线处理时，如果监视器端与集成端出现网络中断，或者其中一个出现突发事件（如断电）时，之前的一些过程就需要重做，并回滚。特别是针对网络中断的情况，容易造成监视器端查询线程的线程泄漏，即集成端认为之前的操作没成功，然后重新进行操作，然而监视器端的处理线程却还没完。避免这些情况出现的解决方案为：设置一个超时，当达到设定时间而这一流水处理过程未进行时，自动中断这些处理流程，或者可以在监视器端对查询组装后数据块分块存储在硬盘上，然后进行文件数据块的发送，这样减少了块之间的命令的交互逻辑，而且有效地控制了线程泄漏，但是也增加了文件的读写与控制，增加了I/O开销。

数据集成仍然是一个比较热门的研究点，在基于数据仓库方法的数据集成中，分析了实化视图初始化以及OLAP查询中面对大数据量处理的问题，应用了基于内存控制的流水线处理方法，充分利用了Java的多线程处理技术，并从实验和理论上分析了该方法较同步方法的优点。