基于查詢語言轉(zhuǎn)換的多源數(shù)據(jù)統(tǒng)一訪問框架①

李躍鵬,溫亮明,黎建輝

1(中國科學(xué)院 計算機網(wǎng)絡(luò)信息中心,北京 100190)

2(中國科學(xué)院大學(xué),北京 100049)

1 引言

大數(shù)據(jù)應(yīng)用系統(tǒng)是由多種數(shù)據(jù)處理工具構(gòu)成的集成性系統(tǒng),其數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)存儲位置、數(shù)據(jù)管理與分析工具等均具有多樣化特點[1,2].例如在電商系統(tǒng)中,通過關(guān)系數(shù)據(jù)庫管理用戶交易數(shù)據(jù),商品數(shù)據(jù)存儲于文檔數(shù)據(jù)庫;為加快系統(tǒng)響應(yīng)速度,通過Key-Value 數(shù)據(jù)庫緩存高頻率訪問數(shù)據(jù);統(tǒng)計報表使用流處理工具、SQL 查詢引擎等進行歷史數(shù)據(jù)統(tǒng)計分析.在科學(xué)大數(shù)據(jù)管理領(lǐng)域,科研項目通過領(lǐng)域關(guān)系型數(shù)據(jù)庫管理從傳感器、遙感衛(wèi)星等科學(xué)裝置獲得的實驗數(shù)據(jù);使用領(lǐng)域非結(jié)構(gòu)化數(shù)據(jù)庫進行高能物理對撞機事件數(shù)據(jù)的存儲與索引;通過圖數(shù)據(jù)庫管理物種、基因組等知識圖譜數(shù)據(jù);借助領(lǐng)域數(shù)據(jù)分析工具對各類實驗數(shù)據(jù)進行統(tǒng)計與交叉分析,進而得出實驗結(jié)論[3].大數(shù)據(jù)集成系統(tǒng)使用的數(shù)據(jù)處理工具分為兩類:數(shù)據(jù)提供者使用標(biāo)準(zhǔn)查詢語言、WebService 等接口方式提供數(shù)據(jù)庫、開放平臺等基礎(chǔ)數(shù)據(jù)管理服務(wù);數(shù)據(jù)消費者調(diào)用多個數(shù)據(jù)提供者接口獲取數(shù)據(jù),并通過標(biāo)準(zhǔn)查詢語言、WebService 等接口對多源異構(gòu)數(shù)據(jù)進行查詢、統(tǒng)計、分析、展示等操作,如SQL 查詢引擎、數(shù)據(jù)倉庫、管理系統(tǒng)等.數(shù)據(jù)消費者與數(shù)據(jù)提供者之間的數(shù)據(jù)訪問方式具有以下特點:

(1)數(shù)據(jù)訪問接口各異:數(shù)據(jù)提供者接口需經(jīng)轉(zhuǎn)換才能符合數(shù)據(jù)消費者的接口格式要求.比如報表系統(tǒng)中,數(shù)據(jù)消費者使用SQL 語言對數(shù)據(jù)進行統(tǒng)計,然而數(shù)據(jù)提供者的服務(wù)接口為文檔查詢、WebService 以及文件等形式.

(2)數(shù)據(jù)訪問模式多樣:數(shù)據(jù)消費者與數(shù)據(jù)提供者之間是多對多數(shù)據(jù)訪問方式.例如數(shù)據(jù)倉庫使用SQL語言對多個異構(gòu)數(shù)據(jù)源進行分析;而異構(gòu)數(shù)據(jù)源除了為數(shù)據(jù)倉庫提供服務(wù),還會被多個部門或外部應(yīng)用系統(tǒng)消費.

(3)松耦合方式集成:數(shù)據(jù)消費者與數(shù)據(jù)提供者獨立運行、部署與迭代更新.例如作為數(shù)據(jù)提供者,存儲用戶、業(yè)務(wù)與實驗等數(shù)據(jù)的數(shù)據(jù)庫會根據(jù)技術(shù)、場景等因素進行更新,然而數(shù)據(jù)消費者的訪問接口卻并不改變;相反,數(shù)據(jù)消費者會根據(jù)業(yè)務(wù)、性能等需要調(diào)整數(shù)據(jù)消費者的數(shù)據(jù)訪問接口.

基于以上數(shù)據(jù)訪問特點,要實現(xiàn)數(shù)據(jù)提供者接口與消費者接口的交互協(xié)作,集成系統(tǒng)必須提供一個接口適配器以滿足雙方需要,目前已有研究特定應(yīng)用場景接口適配器的相關(guān)工作.隨著數(shù)據(jù)提供者與數(shù)據(jù)消費者工具的更新變化,這種針對特定應(yīng)用場景的一對一型接口適配器勢必難以適應(yīng)數(shù)據(jù)遷移與工具迭代更新需要,因此我們提出了一種基于查詢語言轉(zhuǎn)換的多源數(shù)據(jù)統(tǒng)一訪問框架,通過引入中間數(shù)據(jù)模型和雙端適配器將數(shù)據(jù)訪問接口API 與實際數(shù)據(jù)模型相分離,使得集成系統(tǒng)具有更好的靈活性和擴展性.

2 相關(guān)工作

接口適配器以數(shù)據(jù)消費者數(shù)據(jù)模型或數(shù)據(jù)提供者數(shù)據(jù)模型作為中間數(shù)據(jù)模型.首先將數(shù)據(jù)提供者或數(shù)據(jù)消費者的Schema 映射為中間數(shù)據(jù)模型,然后通過數(shù)據(jù)轉(zhuǎn)換或查詢語言轉(zhuǎn)換方式完成接口適配轉(zhuǎn)換.數(shù)據(jù)轉(zhuǎn)換適配器將數(shù)據(jù)提供者所持有數(shù)據(jù)動態(tài)或一次性轉(zhuǎn)換為消費者可識別的數(shù)據(jù)格式進行存儲或處理;查詢語言轉(zhuǎn)換適配器將數(shù)據(jù)消費者端的查詢語言轉(zhuǎn)換為數(shù)據(jù)提供者端的查詢語言.

根據(jù)數(shù)據(jù)消費者對數(shù)據(jù)提供者的訪問方式,數(shù)據(jù)消費者與數(shù)據(jù)提供者的接口適配方式分為一對一適配、多對一適配以及多對多適配3 種(如圖1(a)至圖1(c)所示).

(1)一對一適配:采用查詢語言轉(zhuǎn)換方式將數(shù)據(jù)消費者接口轉(zhuǎn)換為數(shù)據(jù)提供者查詢語言.例如文獻(xiàn)Sql2Saprql (RETRO)[4]、Sparql2Sql (D2RQ)[5]、Cypher2sql (Cytosm)[6]等提出了將不同查詢語言轉(zhuǎn)換為SQL 查詢語句或?qū)QL 查詢語句轉(zhuǎn)換為其它查詢語言的方法.

(2)多對一適配:以消費者數(shù)據(jù)模型為中間數(shù)據(jù)模型,數(shù)據(jù)提供者向統(tǒng)一模型動態(tài)提供適配數(shù)據(jù).例如SparkSQL[7],Presto[8]、Impala[9]等SQL 查詢引擎適配器將關(guān)系數(shù)據(jù)庫、文檔數(shù)據(jù)庫、CSV 文件、JSON 文件等數(shù)據(jù)源動態(tài)轉(zhuǎn)換為臨時關(guān)系表來實現(xiàn)SQL 統(tǒng)一查詢.Gradoop 適配器將異構(gòu)數(shù)據(jù)動態(tài)轉(zhuǎn)換為屬性圖模型的節(jié)點和邊來實現(xiàn)Cypher 語言統(tǒng)一查詢[10].

(3)多對多適配:為數(shù)據(jù)提供者和數(shù)據(jù)消費者提供接口適配.例如Polystore[11]要求系統(tǒng)支持多種全局?jǐn)?shù)據(jù)模型與本地數(shù)據(jù)模型之間的轉(zhuǎn)換,通過數(shù)據(jù)提供者與數(shù)據(jù)消費之間的成對查詢語言轉(zhuǎn)換適配器為上層應(yīng)用提供多樣化數(shù)據(jù)查詢接口.

以數(shù)據(jù)訪問接口適配方法存在的問題是中間數(shù)據(jù)模型與查詢語言模型綁定,使得接口適配器只在單個數(shù)據(jù)提供者與數(shù)據(jù)消費者之間產(chǎn)生效用.對于數(shù)據(jù)轉(zhuǎn)換適配器,當(dāng)多個數(shù)據(jù)消費者的數(shù)據(jù)模型不同時,數(shù)據(jù)提供者必須向數(shù)據(jù)消費者提供不同的適配數(shù)據(jù).對于查詢語言轉(zhuǎn)換適配器,多對多訪問同樣必須采用case by case 方式實現(xiàn)成對查詢語言轉(zhuǎn)換.當(dāng)系統(tǒng)中存在n個異構(gòu)數(shù)據(jù)提供者和n個數(shù)據(jù)消費者時,要支持多對多訪問就必須開發(fā)n!個適配器,如果新增一個異構(gòu)數(shù)據(jù)提供者則需要實現(xiàn)2n個轉(zhuǎn)換器,從而影響系統(tǒng)對新數(shù)據(jù)源的擴展性.因此,本文嘗試探索提出一種雙適配器數(shù)據(jù)統(tǒng)一訪問框架(如圖1(d)所示),通過數(shù)據(jù)提供者與數(shù)據(jù)消費者兩端適配器將查詢語言與數(shù)據(jù)模型分離,從而對新數(shù)據(jù)提供者與數(shù)據(jù)消費者的支持只要按需實現(xiàn)一個適配器即可.

圖1 數(shù)據(jù)提供者與消費者接口適配方式

3 框架設(shè)計

雙Adapter 數(shù)據(jù)統(tǒng)一訪問框架BAF4DUA 將多個異構(gòu)數(shù)據(jù)消費者與數(shù)據(jù)提供者接口進行適配,為上層應(yīng)用提供多樣化的數(shù)據(jù)服務(wù)接口.該框架使用中間模型統(tǒng)一表示數(shù)據(jù)提供者所持有數(shù)據(jù),中間查詢計劃統(tǒng)一表示消費者與提供者查詢語言的語義;數(shù)據(jù)消費者與數(shù)據(jù)提供者兩端分別與中間模型進行接口適配,將數(shù)據(jù)訪問接口與數(shù)據(jù)模型分離,從而支持消費者與提供者多對多數(shù)據(jù)訪問,提高系統(tǒng)的靈活性與擴展性.

如圖2所示,雙Adapter 數(shù)據(jù)統(tǒng)一訪問框架由數(shù)據(jù)消費端Adapter、中間數(shù)據(jù)模型、中間查詢計劃、數(shù)據(jù)提供者端Adapter 以及數(shù)據(jù)映射5 部分構(gòu)成.

圖2 雙Adapter 數(shù)據(jù)統(tǒng)一訪問框架

(1)數(shù)據(jù)消費者端Adapter是系統(tǒng)數(shù)據(jù)訪問請求的編碼器.它將消費者查詢語句涉及的目標(biāo)數(shù)據(jù)與中間數(shù)據(jù)模型進行映射,同時將查詢語句的語義編碼為中間查詢計劃.根據(jù)系統(tǒng)設(shè)計需要,數(shù)據(jù)消費者端Adapter還需對查詢結(jié)果進行格式轉(zhuǎn)換以滿足消費者應(yīng)用需求.

(2)數(shù)據(jù)提供者端Adapter是系統(tǒng)數(shù)據(jù)訪問請求的解碼器,它將中間查詢計劃解碼為數(shù)據(jù)提供者可識別的查詢語句,實現(xiàn)中間數(shù)據(jù)模型與數(shù)據(jù)提供者的數(shù)據(jù)映射.根據(jù)系統(tǒng)設(shè)計需要,數(shù)據(jù)提供者端Adapter 還需要將查詢結(jié)果轉(zhuǎn)換統(tǒng)一數(shù)據(jù)格式.

(3)中間數(shù)據(jù)模型為系統(tǒng)多源異構(gòu)數(shù)據(jù)提供統(tǒng)一語義視圖,它定義數(shù)據(jù)的統(tǒng)一表示方式,記錄中間模型的元素構(gòu)成與數(shù)據(jù)持有者的映射關(guān)系,支持?jǐn)?shù)據(jù)的增、刪、改、查、合并等操作.根據(jù)系統(tǒng)設(shè)計需要,中間數(shù)據(jù)模型還需定義通用數(shù)據(jù)格式以供數(shù)據(jù)消費者與數(shù)據(jù)提供者之間進行查詢結(jié)果轉(zhuǎn)換.

(4)中間查詢計劃將數(shù)據(jù)提供者和數(shù)據(jù)消費者接口對數(shù)據(jù)的操作進行抽象化處理,定義系統(tǒng)支持的運算類型,實現(xiàn)數(shù)據(jù)提供者與數(shù)據(jù)消費者查詢操作與中間查詢計劃運算的相互轉(zhuǎn)換.由于不同數(shù)據(jù)提供者和數(shù)據(jù)消費者對數(shù)據(jù)運算操作的支持程度不同,根據(jù)系統(tǒng)設(shè)計需要,還必須對不支持的數(shù)據(jù)操作進行補償運算.

(5)數(shù)據(jù)映射將數(shù)據(jù)提供者所持有數(shù)據(jù)與中間數(shù)據(jù)模型進行映射,在映射過程中數(shù)據(jù)提供者根據(jù)中間數(shù)據(jù)模型的定義,將其所持有的數(shù)據(jù)按照映射規(guī)范向中間數(shù)據(jù)模型注冊.在此過程中,數(shù)據(jù)映射規(guī)范需要適量增加或減少原有數(shù)據(jù)的限制以滿足中間數(shù)據(jù)模型的定義.

4 框架實現(xiàn)

為了驗證BAF4DUA 框架在實際系統(tǒng)中的應(yīng)用,本文實現(xiàn)了一個多對多數(shù)據(jù)統(tǒng)一訪問系統(tǒng),其中數(shù)據(jù)消費者接口為標(biāo)準(zhǔn)查詢語言,數(shù)據(jù)提供者接口為常用數(shù)據(jù)庫.該系統(tǒng)中間數(shù)據(jù)模型使用實體與關(guān)系對數(shù)據(jù)進行統(tǒng)一表述,數(shù)據(jù)映射將數(shù)據(jù)庫、WebService 等查詢接口的數(shù)據(jù)對象映射為中間數(shù)據(jù)模型元素.中間查詢計劃選擇四類運算形式化描述查詢語句的語義信息,消費者與提供者Adapter 將各自接口與中間數(shù)據(jù)模型和中間查詢計劃進行適配.目前系統(tǒng)支持通過SQL、Cypher、MongoDB 等查詢語言接口對不同數(shù)據(jù)提供者進行數(shù)據(jù)訪問,在不影響系統(tǒng)其它組成部分的情況下,可實現(xiàn)數(shù)據(jù)庫遷移、緩存、統(tǒng)一管理等應(yīng)用需求.

4.1 中間數(shù)據(jù)模型與數(shù)據(jù)映射

中間數(shù)據(jù)模型對集成系統(tǒng)中的異構(gòu)數(shù)據(jù)采用統(tǒng)一方式進行語義描述,系統(tǒng)數(shù)據(jù)用實體(Entity)與關(guān)系(Relation)兩個概念對常見數(shù)據(jù)源進行描述[12].實體為具有相似意義的數(shù)據(jù)集合,實體元素的具體數(shù)據(jù)格式不限,既包括結(jié)構(gòu)化形式的表數(shù)據(jù),也包括非結(jié)構(gòu)化形式的文檔數(shù)據(jù);關(guān)系為實體間的語義關(guān)聯(lián),可通過多種方式進行表示,關(guān)系表示形式包括實體條件表達(dá)式或存儲的關(guān)系數(shù)據(jù).中間數(shù)據(jù)模型的形式化表示如下:

其中,E表示實體集合,R∈(E×E)表示關(guān)系集合,S表示數(shù)據(jù)源集合,L表示用于實體與關(guān)系標(biāo)識的標(biāo)簽集合,K表示L、S與E、R之間的映射關(guān)系,ρ表示S與R之間的數(shù)據(jù)映射方式.

異構(gòu)數(shù)據(jù)源S包括兩種形式:一是以標(biāo)準(zhǔn)查詢語言為訪問接口的數(shù)據(jù)庫管理工具,如關(guān)系數(shù)據(jù)庫、文檔數(shù)據(jù)庫以及圖數(shù)據(jù)庫等;二是其它非標(biāo)準(zhǔn)化數(shù)據(jù)訪問接口,如WebService、Shell 命令以及文件系統(tǒng)等.S中的每個元素必須包含連接訪問該數(shù)據(jù)源的所有參數(shù),如連接字符串、URL 以及用戶名密碼等.

映射關(guān)系K由兩部分構(gòu)成:標(biāo)簽映射Kl:(E∪R)→L表示標(biāo)簽與ER 元素之間的映射關(guān)系,即實體集合與關(guān)系由一個標(biāo)簽唯一標(biāo)識;數(shù)據(jù)映射Ks:(E∪R)→(S∪ρ)表示數(shù)據(jù)源與Entity、Relation 元素之間的映射關(guān)系,即Entity 與Relation 由數(shù)據(jù)源與數(shù)據(jù)映射方式構(gòu)成.

針對不同數(shù)據(jù)源,數(shù)據(jù)映射方式ρ采用多種方法將異構(gòu)數(shù)據(jù)源映射為Entity和Relation 元素.對于提供標(biāo)準(zhǔn)查詢語言接口的數(shù)據(jù)源,可使用通用的數(shù)據(jù)映射規(guī)范自動將數(shù)據(jù)源映射到中間數(shù)據(jù)模型.如表1所示,將關(guān)系模型數(shù)據(jù)中的Table 映射為中間數(shù)據(jù)模型的Entity 元素,將“外鍵”或?qū)傩韵嚓P(guān)的邏輯表達(dá)式映射為中間數(shù)據(jù)模型中的Relation 元素;將文檔模型數(shù)據(jù)源中的Collection 映射為中間數(shù)據(jù)模型的Entity,將文檔的DBref 或?qū)傩缘倪壿嫳磉_(dá)式映射為中間數(shù)據(jù)模型的Relation;將屬性圖模型數(shù)據(jù)源中具有相同Label的節(jié)點集合映射為Entity,而將具有同樣Label的邊集合映射為Relation.

表1 數(shù)據(jù)映射關(guān)系

對于無標(biāo)準(zhǔn)查詢語言接口的數(shù)據(jù)提供者,需要根據(jù)數(shù)據(jù)提供者的數(shù)據(jù)訪問接口特點自定義數(shù)據(jù)源與中間數(shù)據(jù)模型的映射方式.例如WebService 接口與中間數(shù)據(jù)模型的映射需要根據(jù)服務(wù)URL、Token 以及業(yè)務(wù)參數(shù)等與實體、關(guān)系進行映射.

4.2 中間查詢計劃

查詢計劃是對查詢語句所表達(dá)語義的形式化描述,它是一個節(jié)點為數(shù)據(jù)模型運算的樹形結(jié)構(gòu).中間查詢計劃p:umsrc→umtarget描述了從數(shù)據(jù)umsrc向查詢目標(biāo)數(shù)據(jù)umtarget轉(zhuǎn)換的運算過程,它代表了查詢語句的查詢目標(biāo),系統(tǒng)支持的運算類型越多,執(zhí)行計劃能夠支持的查詢功能越豐富.在實現(xiàn)過程中,我們選擇了4 類中間數(shù)據(jù)模型運算作為中間查詢計劃的基礎(chǔ)組成部分:

(1)scan(umsrc,umtarget,item)運算對參加運算的中間數(shù)據(jù)模型中實體與關(guān)系進行選擇.其中item指umsrc中的實體或關(guān)系元素,scan運算將umsrc中的item元素加入umtarget.如果item類型為Relation,scan運算同時將與該Relation 關(guān)聯(lián)的Entity 添加到umtarget.

(2)filter(umtarget,item,cond,type)運算對umtarget中Entity 或Relation 集合內(nèi)數(shù)據(jù)對象進行條件約束.其中item指umtarget中的實體或關(guān)系元素,cond為item中數(shù)據(jù)對象滿足的邏輯表達(dá)式條件,type為過濾運算類型.根據(jù)不同過濾運算類型,filter運算采用不同形式過濾umtarget中的數(shù)據(jù).

(3)link(umsrc,umtarget,item1,item2)運算在Entity 元素item1與item2之間建立一個關(guān)系加入umtarget中.建立Relation的方式有兩種:一是通過item1與item2之間的邏輯表達(dá)式創(chuàng)建一個臨時Relation;二是從umsrc選擇與item1、item2對應(yīng)的Relation 加入umtarget.

(4)project(umtarget,cond)運算根據(jù)cond條件選擇umtarget中的元素或元素內(nèi)容保留參與后續(xù)運算.cond條件包括兩類:umtarget中Entity 或Relation 元素;Entity或Relation 數(shù)據(jù)的屬性、列等子元素.

4.3 消費者端Adapter 與數(shù)據(jù)提供者端Adapter

BAF4DUA 架構(gòu)中適配器對數(shù)據(jù)消費者和數(shù)據(jù)提供者的數(shù)據(jù)查詢接口進行轉(zhuǎn)換翻譯:第1 步,數(shù)據(jù)消費者端Adapter 將數(shù)據(jù)消費者查詢語句編碼為中間查詢計劃統(tǒng)一表示;第2 步,數(shù)據(jù)提供者端Adapter 將中間查詢計劃解碼為數(shù)據(jù)提供者可識別的查詢語句.通過中間查詢計劃對查詢語句的統(tǒng)一形式化表示,BAF4DUA框架將查詢語言接口與數(shù)據(jù)模型解耦.

查詢語句在數(shù)據(jù)源執(zhí)行過程中會解析節(jié)點為數(shù)據(jù)模型運算的邏輯查詢計劃樹,數(shù)據(jù)源執(zhí)行引擎遍歷查詢計劃樹依序執(zhí)行運算節(jié)點.數(shù)據(jù)消費者端Adapter對查詢語句的語義編碼過程需實現(xiàn)中間查詢計劃與邏輯查詢計劃、中間數(shù)據(jù)模型與數(shù)據(jù)源的運算映射兩部分內(nèi)容:

(1)數(shù)據(jù)映射:主要過程是解析數(shù)據(jù)消費者請求的查詢語句,獲取查詢語句的目標(biāo)數(shù)據(jù)對象,根據(jù)數(shù)據(jù)映射方式ρ獲取目標(biāo)數(shù)據(jù)對象與中間數(shù)據(jù)模型Entity和Relation的對應(yīng)關(guān)系,收集相應(yīng)的數(shù)據(jù)作為后續(xù)運算參數(shù).

(2)運算映射:主要過程是將數(shù)據(jù)消費者查詢語句解析為邏輯查詢計劃樹并自底向上遍歷,根據(jù)根節(jié)點到當(dāng)前運算節(jié)點路徑計算邏輯查詢計劃樹中的每個運算節(jié)點所處的狀態(tài)并據(jù)此確定后續(xù)運算映射.邏輯查詢計劃樹的運算節(jié)點與中間執(zhí)行計劃運算節(jié)點之間存在一對一、一對多、多對一以及多對多關(guān)系,根據(jù)運算映射關(guān)系生成中間執(zhí)行計劃的運算節(jié)點以及中間執(zhí)行計劃樹.

與數(shù)據(jù)消費者端對查詢語句的編碼過程相反,數(shù)據(jù)提供者端Adapter對中間執(zhí)行計劃樹解碼操作,生成數(shù)據(jù)提供者查詢語言接口的邏輯查詢計劃樹.解碼過程根據(jù)數(shù)據(jù)映射方式ρ從中間執(zhí)行計劃運算節(jié)點的參數(shù)中抽取出數(shù)據(jù)源的操作對象,實現(xiàn)中間數(shù)據(jù)模型與數(shù)據(jù)源的有效映射.根據(jù)中間執(zhí)行計劃運算節(jié)點與邏輯查詢計劃運算節(jié)點的對應(yīng)關(guān)系生成邏輯查詢計劃樹,進而生成目標(biāo)查詢語句提交給數(shù)據(jù)提供者執(zhí)行.

5 案例示范

5.1 BAF4DUA 案例工具實現(xiàn)

根據(jù)第4 節(jié)提出的BAF4DUA 框架實現(xiàn)方案,本文實現(xiàn)了一個支持關(guān)系模型、屬性圖模型和文檔模型與中間數(shù)據(jù)模型的相互映射,以及SQL、Cypher、Mongo 命令3 種查詢語言的相互轉(zhuǎn)換的案例工具.

如圖3所示,BAF4DUA 案例工具的具體實現(xiàn)主要包括10 個類.UnifiedDataModel 類為Entity 與Relation 組成的圖數(shù)據(jù)結(jié)構(gòu),在使用BAF4DUA 案例工具之前需根據(jù)數(shù)據(jù)提供者的數(shù)據(jù)進行初始化,通過UnifiedDataModel 類,查詢語言轉(zhuǎn)換過程中可以確定中間查詢計劃、數(shù)據(jù)提供者查詢對象、數(shù)據(jù)消費者查詢對象之間的映射關(guān)系.接口類Encoder 與Decoder 包含查詢語言與中間查詢計劃UnifiedQueryPlan 進行轉(zhuǎn)換的encode與decode函數(shù).SqlEncoder、CypherEncoder以及MongoEncoder為Encoder 接口類的具體實現(xiàn),其中SqlEncoder 首先利用Apache Calcite[13]將SQL 語句解析為SQL 查詢計劃,然后通過遍歷SQL 查詢計劃將SQL 查詢計劃中的JOIN、FILTER 運算以及表達(dá)式轉(zhuǎn)換為UnifiedQueryPlan 中對應(yīng)運算Operator.類似的,我們使用開源工具Cytosm[14]以及Mongo-Shell-Like-Query[15]分別將Cypher 與Mongo 命令分別解析成相應(yīng)的查詢計劃,根據(jù)4.3 節(jié)所述遍歷該查詢計劃生成對應(yīng)的UnifiedQueryPlan對象.SqlDecoder、Cypher-Decoder 以及MongoDecoder為Decoder 接口類的具體實現(xiàn).其中SqlDecoder 假設(shè)最終生成的SQL 語句模式為:

圖3 BAF4DUA 案例工具類

SELECT ＜RESULT＞

FROM ＜TABLES＞

WHERE ＜CONDITION＞

根據(jù)UnifiedQueryPlan 類的Entities 與Relations成員生成SQL 語句的SELECT 與FROM 元素;通過解析查詢計劃中的運算Operator 生成SQL 語句的WHERE條件對結(jié)果進行過濾;類似的,CypherDecoder 主要針對如下Cypher 句式:

MATCH ＜ENTITY＞

MATCH ＜RELATION＞

WHERE ＜CONDITION＞

RETURN ＜RESULT＞

根據(jù)中間查詢計劃UnifiedQueryPlan 生成句式的各部分的內(nèi)容;MongoDecoder 則將UnifiedQueryPlan中的Operator 運算統(tǒng)一組合成一個Pipeline,將Scan、Filter、Link 以及Project 四類運算轉(zhuǎn)換為Mongo 命令Pipeline 中的JSON 運算對象,最后將整個Pipeline對象序列化為Mongo Shell 命令語句.

需要指出的是,本文中案例工具的實現(xiàn)方式存在一定的局限性,尤其是Decoder 部分的實現(xiàn)還有很大的提升空間.例如本文使用了固定的查詢語句模式,根據(jù)中間查詢計劃分別轉(zhuǎn)換為固定句式中的組成部分,而不是將中間查詢計劃直接轉(zhuǎn)換為數(shù)據(jù)提供者查詢語句對應(yīng)的查詢計劃.除此之外,本文的案例沒有對聚合查詢、多語句查詢等操作進行處理.

5.2 查詢語言轉(zhuǎn)換性能

為了驗證查詢語言轉(zhuǎn)換對查詢性能的影響,我們將生成的1 GB TPCH[16]數(shù)據(jù)導(dǎo)入關(guān)系型數(shù)據(jù)庫MySQL、圖數(shù)據(jù)庫Neo4j 以及文檔型數(shù)據(jù)庫MongoDB 中,對TPCH 基準(zhǔn)測試中單表查詢語句Q1 與多表查詢語句Q2的查詢語言轉(zhuǎn)換與數(shù)據(jù)查詢時間進行了統(tǒng)計,其中MySQL、Neo4j和MongoDB 數(shù)據(jù)庫的運行環(huán)境如表2所示,查詢時間結(jié)果如表3所示.在數(shù)據(jù)導(dǎo)入過程中,TPCH 數(shù)據(jù)集的8 個文件分別導(dǎo)出為MongoDB的8 個Collection 以及Neo4j的8 類節(jié)點.根據(jù)TPCH提供的ER 模型,我們在Neo4j 中創(chuàng)建了節(jié)點之間的邊.需要說明的是,TPCH 數(shù)據(jù)集的不同導(dǎo)入方式以及索引會對后續(xù)查詢時間產(chǎn)生一定影響.

表2 數(shù)據(jù)庫運行環(huán)境

表3 查詢語言轉(zhuǎn)換與數(shù)據(jù)查詢時間(ms)

由表3可知,查詢語言轉(zhuǎn)換時間在70 ms 內(nèi),相對于數(shù)據(jù)查詢時間占比最高不大于1%,并且隨著數(shù)據(jù)量的增加查詢語言轉(zhuǎn)換的時間占比會越來越少.由于Mongo 命令的解碼過程使用了第三方的JSON 轉(zhuǎn)換工具,因此中間查詢計劃解碼為MongoDB 接口的時間要比其它接口的解碼時間更多,故而查詢語言的編碼時間均在10 ms 以下.總體而言,在提高開發(fā)效率與系統(tǒng)擴展性、滿足數(shù)據(jù)統(tǒng)一訪問的前提下,查詢語言轉(zhuǎn)換帶來的查詢性能損失在可接受范圍之內(nèi).

5.3 查詢語言轉(zhuǎn)換應(yīng)用案例

案例1.數(shù)據(jù)庫緩存:為提高系統(tǒng)的響應(yīng)速度,應(yīng)用系統(tǒng)通常采用主數(shù)據(jù)庫與緩存數(shù)據(jù)庫相結(jié)合的方式管理業(yè)務(wù)數(shù)據(jù),例如使用Redis對用戶信息進行緩存.此時系統(tǒng)開發(fā)需同時使用SQL 與Redis 語言進行數(shù)據(jù)查詢,如果能夠?qū)QL、Mongo 命令以及Cypher 編碼為中間查詢計劃,同時將中間查詢計劃解碼為Redis 查詢語句,那么系統(tǒng)就可以為不同主數(shù)據(jù)庫增加緩存功能,并且保持系統(tǒng)開發(fā)的接口統(tǒng)一性.

為實現(xiàn)以上目標(biāo),系統(tǒng)需要一個數(shù)據(jù)提供者端Adapter 將中間查詢計劃轉(zhuǎn)換為Redis 查詢語言.其中數(shù)據(jù)映射將Redis 數(shù)據(jù)庫中具有一定模式的Key 定義為中間數(shù)據(jù)模型的Entity;Entity的屬性值與Key 值相對應(yīng);Relation 則根據(jù)用戶定義表達(dá)式進行Entity的關(guān)聯(lián).中間查詢計劃與Redis的具體運算映射方式如表4所示.

表4 中間查詢計劃與Redis 運算映射

以客戶Customer 數(shù)據(jù)為例,假設(shè)客戶數(shù)據(jù)在Redis中Key的存儲模式為＜Cust_ID_USERNAME_NATION,customer_object_hash＞,那么Customer 實體定義為以字符串“Cust”開頭的Key,實體屬性ID、USERNAME、NATION的值分別對應(yīng)以“_”進行分割的每個值.如圖4所示,假設(shè)系統(tǒng)要查詢“李”姓中國籍客戶,那么使用SQL、Cypher 以及MongoDB 命令進行查詢時會首先編碼為中間查詢計劃,然后再轉(zhuǎn)換為Redis查詢語句,最后實現(xiàn)Redis對3 類主數(shù)據(jù)庫的緩存.

圖4 Redis 查詢語言轉(zhuǎn)換案例

案例2.數(shù)據(jù)統(tǒng)一管理:科學(xué)數(shù)據(jù)管理系統(tǒng)通常會查詢多個數(shù)據(jù)源,甚至?xí){(diào)用不同學(xué)科的數(shù)據(jù)源來驗證假設(shè)的真?zhèn)?國家重點研發(fā)計劃“科學(xué)大數(shù)據(jù)管理系統(tǒng)”項目為用戶提供包括天文、高能物理和微生物3 種異構(gòu)數(shù)據(jù)在內(nèi)的多元異構(gòu)數(shù)據(jù)的統(tǒng)一訪問接口.以高能物理數(shù)據(jù)處理系統(tǒng)EventDB[17]為例,它通過分布式存儲與數(shù)據(jù)索引,能夠?qū)Ω吣芪锢韺嶒炛挟a(chǎn)生的EB級事例進行存儲與查詢.EventDB的接口形式為特定命令,如有以下查詢命令:time=178789800～178807800&detID=1&channel=12&pulse=0～255&eventType=0,其含義為查詢2017年8月31日15:50:00 至2017年8月31日20:50:00 之間5 小時內(nèi)1 號探測器、12 號通道、0 號事件的脈沖跨度的變化情況.

數(shù)據(jù)提供者Adapter的數(shù)據(jù)映射需根據(jù)科研用戶的查詢需求和習(xí)慣,根據(jù)實驗因素與中間模型進行映射.例如相同特征的事例映射與Entity 集合對應(yīng);實體屬性為EventDB 中事例的相關(guān)數(shù)據(jù)值;Relation 根據(jù)自定義表達(dá)式進行Entity 關(guān)聯(lián).中間查詢計劃與EventDB命令的映射如表5所示.

表5 中間查詢計劃與EventDB 運算映射

假設(shè)用戶習(xí)慣按照探測器進行事例查詢,EventDB中的探測器編號為n的事例與Entity 映射,事例的time、detID、channel、pulse 與eventType 等屬性為Entity的屬性值.如圖5所示,如果要查詢3 號探測器在2017年8月31日15:50:00 至2017年8月31日20:50:00 之間內(nèi)的所有脈沖變化,那么SQL、Cypher、MongoDB的查詢語句可根據(jù)以上映射關(guān)系首先編碼為中間查詢計劃,然后轉(zhuǎn)換為EventDB 查詢命令.

圖5 EventDB 查詢語言轉(zhuǎn)換案例

6 結(jié)論與展望

在大數(shù)據(jù)時代,集成系統(tǒng)使用多樣化工具對內(nèi)外部數(shù)據(jù)進行統(tǒng)一管理分析,這增加了系統(tǒng)開發(fā)、數(shù)據(jù)管理工具更新遷移以及數(shù)據(jù)統(tǒng)一管理等任務(wù)的接口適配成本.本文提出了一種基于查詢語言轉(zhuǎn)換的多源數(shù)據(jù)統(tǒng)一訪問框架BAF4DUA,該框架特色之處在于采用了雙Adapter 模式:數(shù)據(jù)消費者Adapter 先將消費者數(shù)據(jù)訪問接口語言轉(zhuǎn)換為中間數(shù)據(jù)模型的查詢計劃,而后通過數(shù)據(jù)提供者端Adapter 將中間查詢計劃轉(zhuǎn)換為數(shù)據(jù)提供者的數(shù)據(jù)訪問接口.通過BAF4DUA 框架,可實現(xiàn)數(shù)據(jù)消費者的查詢語言接口與數(shù)據(jù)源的數(shù)據(jù)模型相分離,數(shù)據(jù)消費者和數(shù)據(jù)提供者可采用即插即用的方式增加或更新相應(yīng)的Adapter,增加了系統(tǒng)的靈活性與擴展性,更符合集成系統(tǒng)多對多數(shù)據(jù)訪問的特點.

本文所提BAF4DUA 框架的局限性在于僅考慮了單一使用場景下的數(shù)據(jù)查詢操作,還需要進一步完善以適應(yīng)更復(fù)雜的數(shù)據(jù)統(tǒng)一訪問應(yīng)用場景.后續(xù)研究可從以下幾個方面進一步拓展:(1)設(shè)計與實現(xiàn)支持具備count、sum 等更豐富功能的查詢運算類型;(2)設(shè)計與實現(xiàn)查詢數(shù)據(jù)位于不同數(shù)據(jù)庫場景下的數(shù)據(jù)處理方案;(3)設(shè)計與實現(xiàn)智能化數(shù)據(jù)統(tǒng)一插入存儲方案.