流水線處理技術(shù)在數(shù)據(jù)集成中的應(yīng)用

隨著個(gè)人計(jì)算機(jī)和計(jì)算機(jī)網(wǎng)絡(luò)的飛速發(fā)展，以及信息化的高速推進(jìn)，互聯(lián)網(wǎng)提供的信息總量也在迅猛增長。如果企業(yè)和社會(huì)組織實(shí)現(xiàn)數(shù)據(jù)共享，可以使更多的人更充分地利用已有的數(shù)據(jù)資源。可是為不同應(yīng)用服務(wù)的信息都存儲(chǔ)在許多不同的數(shù)據(jù)源之中，數(shù)據(jù)內(nèi)容以及數(shù)據(jù)格式千差萬別，且其管理系統(tǒng)也各不相同。如何對(duì)這些數(shù)據(jù)進(jìn)行有效的集成管理，屏蔽這些信息的異構(gòu)，并提供一個(gè)統(tǒng)一的訪問接口以透明地訪問各信息源，成為一些大型企業(yè)或社會(huì)組織關(guān)心的事情。數(shù)據(jù)集成正是在這一背景下提出的。

1 基于數(shù)據(jù)復(fù)制方法的集成模式

數(shù)據(jù)復(fù)制方法[1]是當(dāng)前比較常用的數(shù)據(jù)集成模式，該方法將各個(gè)數(shù)據(jù)源的數(shù)據(jù)復(fù)制到與其相關(guān)的其他數(shù)據(jù)源上，并維護(hù)數(shù)據(jù)源整體上的數(shù)據(jù)一致性、提高信息共享利用的效率。這種方式可以復(fù)制信息源的整個(gè)數(shù)據(jù)，也可以是信息源的部分信息。數(shù)據(jù)復(fù)制方法在用戶使用某個(gè)數(shù)據(jù)源之前，將用戶可能用到的其他數(shù)據(jù)源的數(shù)據(jù)預(yù)先復(fù)制過來，如果用戶要使用的數(shù)據(jù)已經(jīng)被復(fù)制，則只需要查詢?cè)摷尚畔⒃?，并與中介器/包裝器的虛擬數(shù)據(jù)集成[2]相比，大大提高了系統(tǒng)處理用戶請(qǐng)求的效率。

基于數(shù)據(jù)復(fù)制方式最常見的一種方法是數(shù)據(jù)倉庫方法[1]。該方法將各個(gè)數(shù)據(jù)的全部或者部分?jǐn)?shù)據(jù)復(fù)制到數(shù)據(jù)倉庫，用戶像訪問普通數(shù)據(jù)庫一樣直接訪問數(shù)據(jù)倉庫。該方式實(shí)現(xiàn)了對(duì)物理數(shù)據(jù)庫語義異構(gòu)的屏蔽和數(shù)據(jù)訪問的控制，提供了一個(gè)統(tǒng)一的數(shù)據(jù)邏輯視圖來隱藏底層的數(shù)據(jù)細(xì)節(jié)。圖1所示為一個(gè)典型的數(shù)據(jù)倉庫體系結(jié)構(gòu)圖[3]。

在該集成模型中，每一個(gè)數(shù)據(jù)源對(duì)應(yīng)一個(gè)監(jiān)視器（Monitor），監(jiān)視器負(fù)責(zé)收集所需要集成的信息源中數(shù)據(jù)的變化以便上報(bào)給集成端(收集的方式有如下類別：針對(duì)信息源有日志的情況，可以通過日志分析提取要上報(bào)的增量；對(duì)于沒有日志情況可以通過觸發(fā)器方式或者快照差分方式獲取信息源的增量)，同時(shí)監(jiān)視器還具有一個(gè)包裝器的功能，提供信息源的數(shù)據(jù)查詢提取以及類型轉(zhuǎn)化功能。當(dāng)作為數(shù)據(jù)查詢功能的時(shí)候，不僅將數(shù)據(jù)初始化同步到數(shù)據(jù)倉庫中，同時(shí)也相當(dāng)于一個(gè)服務(wù)器，不斷偵聽來自于集成器的命令查詢請(qǐng)求，當(dāng)有請(qǐng)求到達(dá)時(shí)，執(zhí)行查詢，并將該監(jiān)視器對(duì)應(yīng)的數(shù)據(jù)源的數(shù)據(jù)包裝成基于公共類型的數(shù)據(jù)，或以XML文件的方式和固定大小對(duì)象數(shù)據(jù)塊的方式傳遞給集成器，然后集成器負(fù)責(zé)將提取后的數(shù)據(jù)進(jìn)行合成。其中監(jiān)視器與集成器中的通信流程如圖2所示。

2 基于內(nèi)存控制的流水線處理方法

從上面的數(shù)據(jù)倉庫體系結(jié)構(gòu)可知，監(jiān)視器必須具備一個(gè)包裝器（wrapper）的功能。數(shù)據(jù)倉庫端保存的數(shù)據(jù)是各底層信息源的部分副本（一般情況為訪問非常頻繁），但是不是很頻繁的訪問數(shù)據(jù)還是保持在底層信息源端，當(dāng)一個(gè)OLAP查詢（如下鉆）經(jīng)過查詢分解后，不能在數(shù)據(jù)倉庫端獲取，而必須通過一個(gè)甚至幾個(gè)底層信息源端的查詢，然后在集成器端進(jìn)行結(jié)果的合并（如要通過兩個(gè)底層數(shù)據(jù)庫中表的連接操作）才能獲取查詢結(jié)果。在實(shí)化視圖初始化時(shí)，提高查詢的效率以及提高實(shí)化視圖初始化的時(shí)間，是非常重要的。

本文關(guān)注的便是如何提高查詢效率、響應(yīng)速度、集成端的處理效率，以及在提交查詢后，如何減少集成端的空閑等待時(shí)間，并且在大數(shù)據(jù)量的情況下同時(shí)做到內(nèi)存控制，以防止在大數(shù)據(jù)量的情況下查詢導(dǎo)致內(nèi)存溢出。

在解決提高查詢效率、響應(yīng)速度、集成端的插入效率的同時(shí)，防止內(nèi)存溢出以及在減少集成端的空閑等待時(shí)間方面，利用了基于生產(chǎn)者/消費(fèi)者的流水線處理方法，該方式主要思想是實(shí)現(xiàn)服務(wù)器與客戶端的流水并行[4]，查詢的結(jié)果以固定大小數(shù)據(jù)塊的形式分塊組裝，并在監(jiān)視器端與集成端都使用一定大小的緩沖隊(duì)列來暫存這些數(shù)據(jù)塊，以有效防止內(nèi)存溢出。以一次實(shí)化視圖的初始化過程為例，描述該方式的算法流程為：

(1)集成端發(fā)送帶全局查詢QID（該查詢QID為全局唯一的，通過客戶端API自動(dòng)生成）的SQL查詢命令(結(jié)果查詢重寫)，并通過通信平臺(tái)將該查詢命令放入服務(wù)器端執(zhí)行隊(duì)列中，同時(shí)預(yù)設(shè)一個(gè)數(shù)據(jù)塊計(jì)數(shù)為sum（該計(jì)數(shù)為服務(wù)器端初始要發(fā)送的數(shù)據(jù)塊個(gè)數(shù)），然后集成端監(jiān)聽接收隊(duì)列；

(2)監(jiān)視器端從命令隊(duì)列中取出查詢命令，創(chuàng)建查詢管理器（Data Query Manager），并將該查詢管理器與查詢QID作為一個(gè)鍵值對(duì)放入進(jìn)程全局的哈希表（Concurrent Hash Map)中，然后通過該查詢管理器中的excuteQurey()方法啟動(dòng)查詢線程，該查詢線程將獲得的記錄組織成數(shù)據(jù)塊(Data Object Block)，放入固定大小的數(shù)據(jù)塊緩沖隊(duì)列中，并在該隊(duì)列滿時(shí)，查詢線程暫停，不滿時(shí)繼續(xù)查詢，直到最后一塊為止。同時(shí)啟動(dòng)發(fā)送固定大小的數(shù)據(jù)塊的線程，該發(fā)送線程從緩沖隊(duì)列中取出數(shù)據(jù)塊，發(fā)送給客戶端，直到發(fā)送的最后一塊，該發(fā)送線程終止；

(3)當(dāng)有數(shù)據(jù)塊到達(dá)客戶端的數(shù)據(jù)塊接收隊(duì)列時(shí)，判斷該塊是否為最后一塊，如果是，則設(shè)置所有塊是否到達(dá)的標(biāo)志“flag=true”，并通知客戶端進(jìn)行處理，客戶端處理線程從隊(duì)列中取出一個(gè)數(shù)據(jù)塊進(jìn)行處理（對(duì)實(shí)化視圖初始化，處理的方式就是將該數(shù)據(jù)塊插入到數(shù)據(jù)倉庫的實(shí)化視圖中），并將數(shù)據(jù)塊計(jì)數(shù)n減1，再判斷該數(shù)據(jù)塊計(jì)數(shù)是否小于客戶端要緩沖的個(gè)數(shù)N，并同時(shí)判斷flag的值，如果sumN，且flag= =false，則發(fā)送從服務(wù)器端調(diào)取固定數(shù)目K數(shù)據(jù)塊的命令（該命令帶QID，以便到服務(wù)器端時(shí)找到之前的查詢管理器），同時(shí)設(shè)置sum=sum+K；

(4)服務(wù)器端接收到客戶端的數(shù)據(jù)塊調(diào)取命令，分離出里面的QID，從進(jìn)程全局的哈希表中找到與該QID對(duì)應(yīng)的查詢管理器，并調(diào)用里面的發(fā)送固定數(shù)據(jù)塊的方法以啟動(dòng)發(fā)送固定數(shù)目數(shù)據(jù)塊的線程，該線程與步驟(2)中發(fā)送線程相同；

(5)重復(fù)步驟(3)、步驟(4)，直到查詢的最后一塊到達(dá)客戶端，與此同時(shí)，服務(wù)器端的查詢管理器也從全局的哈希表中移除。

3 性能測(cè)試與分析

與流水線處理方法相對(duì)應(yīng)的一種方法為同步方法，即通過查詢先將底層信息源的結(jié)果組裝在一起，一次傳給集成端處理。由于采用的都是對(duì)象數(shù)據(jù)塊的形式，因此用于與流水線對(duì)比的同步方法的算法思想為：

(1)客戶端發(fā)送帶全局查詢QID（該查詢QID為全局唯一的，通過客戶端API自動(dòng)生成）的SQL查詢命令(結(jié)果查詢重寫)，并通過通信平臺(tái)將該查詢命令放入服務(wù)器端執(zhí)行隊(duì)列中；

(2)服務(wù)器端接收到查詢命令，執(zhí)行查詢，將所得的結(jié)果存放于文件中，然后一次發(fā)送給客戶端；

(3)客戶端接收到關(guān)于本次查詢結(jié)果集的文件，然后處理該結(jié)果集文件。

將基于內(nèi)存控制的流水線處理方法與同步方法在以下實(shí)驗(yàn)環(huán)境下進(jìn)行測(cè)試對(duì)比，為減少誤差，多次測(cè)試得出平均值，有如下數(shù)據(jù)：

監(jiān)視器端與集成端采用相同配置環(huán)境，相關(guān)配置為：
CPU：Intel(R) Core(TM)2 Duo CPU E4500 @ 2.2 GHz；操作系統(tǒng)：Windows XP；內(nèi)存：2.0 GB；數(shù)據(jù)庫：Oracle 9i；JDK版本：1.6.0_07；開發(fā)工具：Myeclipse6.5。

本實(shí)驗(yàn)性能測(cè)試如圖3所示，可以看出，與傳統(tǒng)的同步方法相比，采用本文算法具有較好的性能特性，主要在于基于內(nèi)存控制的流水線處理過程是一個(gè)監(jiān)視器端與集成器端并行流水線運(yùn)行的過程，并充分應(yīng)用了現(xiàn)在多處理器多線程處理的技術(shù)，減少了集成端空閑等待的時(shí)間。

設(shè)查詢信息源并包裝所有數(shù)據(jù)成公共類型數(shù)據(jù)塊的時(shí)間代價(jià)為Cost(Q)，傳輸放入文件中的所有數(shù)據(jù)塊到集成端的時(shí)間為Cost(T)，集成端將傳輸過來的數(shù)據(jù)解析并初始化到數(shù)據(jù)倉庫的時(shí)間為Cost(P)，則基于同步方法的時(shí)間代價(jià)為：Cost(Q)+Cost(T)+Cost(P)。

設(shè)查詢信息源并包裝查詢的數(shù)據(jù)成公共類型數(shù)據(jù)塊為一塊的時(shí)間代價(jià)為：Cost(Q1)，傳輸其中一塊數(shù)據(jù)塊到集成端的時(shí)間為Cost(T1)，集成端將傳輸過來的一塊數(shù)據(jù)塊解析并初始化到數(shù)據(jù)倉庫的時(shí)間為Cost(P1)，因?yàn)檫@里數(shù)據(jù)塊是個(gè)固定的常數(shù)，則基于本文的算法的時(shí)間代價(jià)為：Cost(Q1)+Cost(T1)+Cost(P1)+max(Cost(Q)-Cost(Q1)，Cost(T)-Cost(T1)，Cost(P)-Cost(P1))，其中max為各處理邏輯減去初始處理的最大時(shí)間。

從上面理論上可以分析得出，基于內(nèi)存控制的流水線處理技術(shù)較同步技術(shù)可以更好地提高效率。同時(shí)還存在幾個(gè)問題：

(1)當(dāng)集成端需要OLAP查詢或?qū)嵒晥D初始化比較多時(shí)，仍然會(huì)出現(xiàn)內(nèi)存溢出的問題，這時(shí)可以應(yīng)用線程池技術(shù)[4]，有效控制這類線程運(yùn)行的數(shù)量，同樣，監(jiān)視器端也使用這種方案。

(2)當(dāng)集成端與監(jiān)視器端進(jìn)行流水線處理時(shí)，如果監(jiān)視器端與集成端出現(xiàn)網(wǎng)絡(luò)中斷，或者其中一個(gè)出現(xiàn)突發(fā)事件（如斷電）時(shí)，之前的一些過程就需要重做，并回滾。特別是針對(duì)網(wǎng)絡(luò)中斷的情況，容易造成監(jiān)視器端查詢線程的線程泄漏，即集成端認(rèn)為之前的操作沒成功，然后重新進(jìn)行操作，然而監(jiān)視器端的處理線程卻還沒完。避免這些情況出現(xiàn)的解決方案為：設(shè)置一個(gè)超時(shí)，當(dāng)達(dá)到設(shè)定時(shí)間而這一流水處理過程未進(jìn)行時(shí)，自動(dòng)中斷這些處理流程，或者可以在監(jiān)視器端對(duì)查詢組裝后數(shù)據(jù)塊分塊存儲(chǔ)在硬盤上，然后進(jìn)行文件數(shù)據(jù)塊的發(fā)送，這樣減少了塊之間的命令的交互邏輯，而且有效地控制了線程泄漏，但是也增加了文件的讀寫與控制，增加了I/O開銷。

數(shù)據(jù)集成仍然是一個(gè)比較熱門的研究點(diǎn)，在基于數(shù)據(jù)倉庫方法的數(shù)據(jù)集成中，分析了實(shí)化視圖初始化以及OLAP查詢中面對(duì)大數(shù)據(jù)量處理的問題，應(yīng)用了基于內(nèi)存控制的流水線處理方法，充分利用了Java的多線程處理技術(shù)，并從實(shí)驗(yàn)和理論上分析了該方法較同步方法的優(yōu)點(diǎn)。