流水線(xiàn)處理技術(shù)在數(shù)據(jù)集成中的應(yīng)用
隨著個(gè)人計(jì)算機(jī)和計(jì)算機(jī)網(wǎng)絡(luò)的飛速發(fā)展,以及信息化的高速推進(jìn),互聯(lián)網(wǎng)提供的信息總量也在迅猛增長(zhǎng)。如果企業(yè)和社會(huì)組織實(shí)現(xiàn)數(shù)據(jù)共享,可以使更多的人更充分地利用已有的數(shù)據(jù)資源??墒菫椴煌瑧?yīng)用服務(wù)的信息都存儲(chǔ)在許多不同的數(shù)據(jù)源之中,數(shù)據(jù)內(nèi)容以及數(shù)據(jù)格式千差萬(wàn)別,且其管理系統(tǒng)也各不相同。如何對(duì)這些數(shù)據(jù)進(jìn)行有效的集成管理,屏蔽這些信息的異構(gòu),并提供一個(gè)統(tǒng)一的訪(fǎng)問(wèn)接口以透明地訪(fǎng)問(wèn)各信息源,成為一些大型企業(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ù)制方法在用戶(hù)使用某個(gè)數(shù)據(jù)源之前,將用戶(hù)可能用到的其他數(shù)據(jù)源的數(shù)據(jù)預(yù)先復(fù)制過(guò)來(lái),如果用戶(hù)要使用的數(shù)據(jù)已經(jīng)被復(fù)制,則只需要查詢(xún)?cè)摷尚畔⒃矗⑴c中介器/包裝器的虛擬數(shù)據(jù)集成[2]相比,大大提高了系統(tǒng)處理用戶(hù)請(qǐng)求的效率。
基于數(shù)據(jù)復(fù)制方式最常見(jiàn)的一種方法是數(shù)據(jù)倉(cāng)庫(kù)方法[1]。該方法將各個(gè)數(shù)據(jù)的全部或者部分?jǐn)?shù)據(jù)復(fù)制到數(shù)據(jù)倉(cāng)庫(kù),用戶(hù)像訪(fǎng)問(wèn)普通數(shù)據(jù)庫(kù)一樣直接訪(fǎng)問(wèn)數(shù)據(jù)倉(cāng)庫(kù)。該方式實(shí)現(xiàn)了對(duì)物理數(shù)據(jù)庫(kù)語(yǔ)義異構(gòu)的屏蔽和數(shù)據(jù)訪(fǎng)問(wèn)的控制,提供了一個(gè)統(tǒng)一的數(shù)據(jù)邏輯視圖來(lái)隱藏底層的數(shù)據(jù)細(xì)節(jié)。圖1所示為一個(gè)典型的數(shù)據(jù)倉(cāng)庫(kù)體系結(jié)構(gòu)圖[3]。
在該集成模型中,每一個(gè)數(shù)據(jù)源對(duì)應(yīng)一個(gè)監(jiān)視器(Monitor),監(jiān)視器負(fù)責(zé)收集所需要集成的信息源中數(shù)據(jù)的變化以便上報(bào)給集成端(收集的方式有如下類(lèi)別:針對(duì)信息源有日志的情況,可以通過(guò)日志分析提取要上報(bào)的增量;對(duì)于沒(méi)有日志情況可以通過(guò)觸發(fā)器方式或者快照差分方式獲取信息源的增量),同時(shí)監(jiān)視器還具有一個(gè)包裝器的功能,提供信息源的數(shù)據(jù)查詢(xún)提取以及類(lèi)型轉(zhuǎn)化功能。當(dāng)作為數(shù)據(jù)查詢(xún)功能的時(shí)候,不僅將數(shù)據(jù)初始化同步到數(shù)據(jù)倉(cāng)庫(kù)中,同時(shí)也相當(dāng)于一個(gè)服務(wù)器,不斷偵聽(tīng)來(lái)自于集成器的命令查詢(xún)請(qǐng)求,當(dāng)有請(qǐng)求到達(dá)時(shí),執(zhí)行查詢(xún),并將該監(jiān)視器對(duì)應(yīng)的數(shù)據(jù)源的數(shù)據(jù)包裝成基于公共類(lèi)型的數(shù)據(jù),或以XML文件的方式和固定大小對(duì)象數(shù)據(jù)塊的方式傳遞給集成器,然后集成器負(fù)責(zé)將提取后的數(shù)據(jù)進(jìn)行合成。其中監(jiān)視器與集成器中的通信流程如圖2所示。
2 基于內(nèi)存控制的流水線(xiàn)處理方法
從上面的數(shù)據(jù)倉(cāng)庫(kù)體系結(jié)構(gòu)可知,監(jiān)視器必須具備一個(gè)包裝器(wrapper)的功能。數(shù)據(jù)倉(cāng)庫(kù)端保存的數(shù)據(jù)是各底層信息源的部分副本(一般情況為訪(fǎng)問(wèn)非常頻繁),但是不是很頻繁的訪(fǎng)問(wèn)數(shù)據(jù)還是保持在底層信息源端,當(dāng)一個(gè)OLAP查詢(xún)(如下鉆)經(jīng)過(guò)查詢(xún)分解后,不能在數(shù)據(jù)倉(cāng)庫(kù)端獲取,而必須通過(guò)一個(gè)甚至幾個(gè)底層信息源端的查詢(xún),然后在集成器端進(jìn)行結(jié)果的合并(如要通過(guò)兩個(gè)底層數(shù)據(jù)庫(kù)中表的連接操作)才能獲取查詢(xún)結(jié)果。在實(shí)化視圖初始化時(shí),提高查詢(xún)的效率以及提高實(shí)化視圖初始化的時(shí)間,是非常重要的。
本文關(guān)注的便是如何提高查詢(xún)效率、響應(yīng)速度、集成端的處理效率,以及在提交查詢(xún)后,如何減少集成端的空閑等待時(shí)間,并且在大數(shù)據(jù)量的情況下同時(shí)做到內(nèi)存控制,以防止在大數(shù)據(jù)量的情況下查詢(xún)導(dǎo)致內(nèi)存溢出。
在解決提高查詢(xún)效率、響應(yīng)速度、集成端的插入效率的同時(shí),防止內(nèi)存溢出以及在減少集成端的空閑等待時(shí)間方面,利用了基于生產(chǎn)者/消費(fèi)者的流水線(xiàn)處理方法,該方式主要思想是實(shí)現(xiàn)服務(wù)器與客戶(hù)端的流水并行[4],查詢(xún)的結(jié)果以固定大小數(shù)據(jù)塊的形式分塊組裝,并在監(jiān)視器端與集成端都使用一定大小的緩沖隊(duì)列來(lái)暫存這些數(shù)據(jù)塊,以有效防止內(nèi)存溢出。以一次實(shí)化視圖的初始化過(guò)程為例,描述該方式的算法流程為:
(1)集成端發(fā)送帶全局查詢(xún)QID(該查詢(xún)QID為全局唯一的,通過(guò)客戶(hù)端API自動(dòng)生成)的SQL查詢(xún)命令(結(jié)果查詢(xún)重寫(xiě)),并通過(guò)通信平臺(tái)將該查詢(xún)命令放入服務(wù)器端執(zhí)行隊(duì)列中,同時(shí)預(yù)設(shè)一個(gè)數(shù)據(jù)塊計(jì)數(shù)為sum(該計(jì)數(shù)為服務(wù)器端初始要發(fā)送的數(shù)據(jù)塊個(gè)數(shù)),然后集成端監(jiān)聽(tīng)接收隊(duì)列;
(2)監(jiān)視器端從命令隊(duì)列中取出查詢(xún)命令,創(chuàng)建查詢(xún)管理器(Data Query Manager),并將該查詢(xún)管理器與查詢(xún)QID作為一個(gè)鍵值對(duì)放入進(jìn)程全局的哈希表(Concurrent Hash Map)中,然后通過(guò)該查詢(xún)管理器中的excuteQurey()方法啟動(dòng)查詢(xún)線(xiàn)程,該查詢(xún)線(xiàn)程將獲得的記錄組織成數(shù)據(jù)塊(Data Object Block),放入固定大小的數(shù)據(jù)塊緩沖隊(duì)列中,并在該隊(duì)列滿(mǎn)時(shí),查詢(xún)線(xiàn)程暫停,不滿(mǎn)時(shí)繼續(xù)查詢(xún),直到最后一塊為止。同時(shí)啟動(dòng)發(fā)送固定大小的數(shù)據(jù)塊的線(xiàn)程,該發(fā)送線(xiàn)程從緩沖隊(duì)列中取出數(shù)據(jù)塊,發(fā)送給客戶(hù)端,直到發(fā)送的最后一塊,該發(fā)送線(xiàn)程終止;
(3)當(dāng)有數(shù)據(jù)塊到達(dá)客戶(hù)端的數(shù)據(jù)塊接收隊(duì)列時(shí),判斷該塊是否為最后一塊,如果是,則設(shè)置所有塊是否到達(dá)的標(biāo)志“flag=true”,并通知客戶(hù)端進(jìn)行處理,客戶(hù)端處理線(xiàn)程從隊(duì)列中取出一個(gè)數(shù)據(jù)塊進(jìn)行處理(對(duì)實(shí)化視圖初始化,處理的方式就是將該數(shù)據(jù)塊插入到數(shù)據(jù)倉(cāng)庫(kù)的實(shí)化視圖中),并將數(shù)據(jù)塊計(jì)數(shù)n減1,再判斷該數(shù)據(jù)塊計(jì)數(shù)是否小于客戶(hù)端要緩沖的個(gè)數(shù)N,并同時(shí)判斷flag的值,如果sumN,且flag= =false,則發(fā)送從服務(wù)器端調(diào)取固定數(shù)目K數(shù)據(jù)塊的命令(該命令帶QID,以便到服務(wù)器端時(shí)找到之前的查詢(xún)管理器),同時(shí)設(shè)置sum=sum+K;
(4)服務(wù)器端接收到客戶(hù)端的數(shù)據(jù)塊調(diào)取命令,分離出里面的QID,從進(jìn)程全局的哈希表中找到與該QID對(duì)應(yīng)的查詢(xún)管理器,并調(diào)用里面的發(fā)送固定數(shù)據(jù)塊的方法以啟動(dòng)發(fā)送固定數(shù)目數(shù)據(jù)塊的線(xiàn)程,該線(xiàn)程與步驟(2)中發(fā)送線(xiàn)程相同;
(5)重復(fù)步驟(3)、步驟(4),直到查詢(xún)的最后一塊到達(dá)客戶(hù)端,與此同時(shí),服務(wù)器端的查詢(xún)管理器也從全局的哈希表中移除。
3 性能測(cè)試與分析
與流水線(xiàn)處理方法相對(duì)應(yīng)的一種方法為同步方法,即通過(guò)查詢(xún)先將底層信息源的結(jié)果組裝在一起,一次傳給集成端處理。由于采用的都是對(duì)象數(shù)據(jù)塊的形式,因此用于與流水線(xiàn)對(duì)比的同步方法的算法思想為:
(1)客戶(hù)端發(fā)送帶全局查詢(xún)QID(該查詢(xún)QID為全局唯一的,通過(guò)客戶(hù)端API自動(dòng)生成)的SQL查詢(xún)命令(結(jié)果查詢(xún)重寫(xiě)),并通過(guò)通信平臺(tái)將該查詢(xún)命令放入服務(wù)器端執(zhí)行隊(duì)列中;
(2)服務(wù)器端接收到查詢(xún)命令,執(zhí)行查詢(xún),將所得的結(jié)果存放于文件中,然后一次發(fā)送給客戶(hù)端;
(3)客戶(hù)端接收到關(guān)于本次查詢(xún)結(jié)果集的文件,然后處理該結(jié)果集文件。
將基于內(nèi)存控制的流水線(xiàn)處理方法與同步方法在以下實(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ù)庫(kù):Oracle 9i;JDK版本:1.6.0_07;開(kāi)發(fā)工具:Myeclipse6.5。
本實(shí)驗(yàn)性能測(cè)試如圖3所示,可以看出,與傳統(tǒng)的同步方法相比,采用本文算法具有較好的性能特性,主要在于基于內(nèi)存控制的流水線(xiàn)處理過(guò)程是一個(gè)監(jiān)視器端與集成器端并行流水線(xiàn)運(yùn)行的過(guò)程,并充分應(yīng)用了現(xiàn)在多處理器多線(xiàn)程處理的技術(shù),減少了集成端空閑等待的時(shí)間。
設(shè)查詢(xún)信息源并包裝所有數(shù)據(jù)成公共類(lèi)型數(shù)據(jù)塊的時(shí)間代價(jià)為Cost(Q),傳輸放入文件中的所有數(shù)據(jù)塊到集成端的時(shí)間為Cost(T),集成端將傳輸過(guò)來(lái)的數(shù)據(jù)解析并初始化到數(shù)據(jù)倉(cāng)庫(kù)的時(shí)間為Cost(P),則基于同步方法的時(shí)間代價(jià)為:Cost(Q)+Cost(T)+Cost(P)。
設(shè)查詢(xún)信息源并包裝查詢(xún)的數(shù)據(jù)成公共類(lèi)型數(shù)據(jù)塊為一塊的時(shí)間代價(jià)為:Cost(Q1),傳輸其中一塊數(shù)據(jù)塊到集成端的時(shí)間為Cost(T1),集成端將傳輸過(guò)來(lái)的一塊數(shù)據(jù)塊解析并初始化到數(shù)據(jù)倉(cāng)庫(kù)的時(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)存控制的流水線(xiàn)處理技術(shù)較同步技術(shù)可以更好地提高效率。同時(shí)還存在幾個(gè)問(wèn)題:
(1)當(dāng)集成端需要OLAP查詢(xún)或?qū)嵒晥D初始化比較多時(shí),仍然會(huì)出現(xiàn)內(nèi)存溢出的問(wèn)題,這時(shí)可以應(yīng)用線(xiàn)程池技術(shù)[4],有效控制這類(lèi)線(xiàn)程運(yùn)行的數(shù)量,同樣,監(jiān)視器端也使用這種方案。
(2)當(dāng)集成端與監(jiān)視器端進(jìn)行流水線(xiàn)處理時(shí),如果監(jiān)視器端與集成端出現(xiàn)網(wǎng)絡(luò)中斷,或者其中一個(gè)出現(xiàn)突發(fā)事件(如斷電)時(shí),之前的一些過(guò)程就需要重做,并回滾。特別是針對(duì)網(wǎng)絡(luò)中斷的情況,容易造成監(jiān)視器端查詢(xún)線(xiàn)程的線(xiàn)程泄漏,即集成端認(rèn)為之前的操作沒(méi)成功,然后重新進(jìn)行操作,然而監(jiān)視器端的處理線(xiàn)程卻還沒(méi)完。避免這些情況出現(xiàn)的解決方案為:設(shè)置一個(gè)超時(shí),當(dāng)達(dá)到設(shè)定時(shí)間而這一流水處理過(guò)程未進(jìn)行時(shí),自動(dòng)中斷這些處理流程,或者可以在監(jiān)視器端對(duì)查詢(xún)組裝后數(shù)據(jù)塊分塊存儲(chǔ)在硬盤(pán)上,然后進(jìn)行文件數(shù)據(jù)塊的發(fā)送,這樣減少了塊之間的命令的交互邏輯,而且有效地控制了線(xiàn)程泄漏,但是也增加了文件的讀寫(xiě)與控制,增加了I/O開(kāi)銷(xiāo)。
數(shù)據(jù)集成仍然是一個(gè)比較熱門(mén)的研究點(diǎn),在基于數(shù)據(jù)倉(cāng)庫(kù)方法的數(shù)據(jù)集成中,分析了實(shí)化視圖初始化以及OLAP查詢(xún)中面對(duì)大數(shù)據(jù)量處理的問(wèn)題,應(yīng)用了基于內(nèi)存控制的流水線(xiàn)處理方法,充分利用了Java的多線(xiàn)程處理技術(shù),并從實(shí)驗(yàn)和理論上分析了該方法較同步方法的優(yōu)點(diǎn)。
評(píng)論