李躍鵬,溫亮明,黎建輝

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

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

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

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

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

2 相關(guān)工作

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

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

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

(2)多對一適配:以消費(fèi)者數(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)換為臨時(shí)關(guān)系表來實(shí)現(xiàn)SQL 統(tǒng)一查詢.Gradoop 適配器將異構(gòu)數(shù)據(jù)動態(tài)轉(zhuǎn)換為屬性圖模型的節(jié)點(diǎn)和邊來實(shí)現(xiàn)Cypher 語言統(tǒng)一查詢[10].

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

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

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

3 框架設(shè)計(jì)

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

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

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

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

(2)數(shù)據(jù)提供者端Adapter是系統(tǒng)數(shù)據(jù)訪問請求的解碼器,它將中間查詢計(jì)劃解碼為數(shù)據(jù)提供者可識別的查詢語句,實(shí)現(xiàn)中間數(shù)據(jù)模型與數(shù)據(jù)提供者的數(shù)據(jù)映射.根據(jù)系統(tǒng)設(shè)計(jì)需要,數(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è)計(jì)需要,中間數(shù)據(jù)模型還需定義通用數(shù)據(jù)格式以供數(shù)據(jù)消費(fèi)者與數(shù)據(jù)提供者之間進(jìn)行查詢結(jié)果轉(zhuǎn)換.

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

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

4 框架實(shí)現(xiàn)

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

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

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

其中,E表示實(shí)體集合,R∈(E×E)表示關(guān)系集合,S表示數(shù)據(jù)源集合,L表示用于實(shí)體與關(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中的每個(gè)元素必須包含連接訪問該數(shù)據(jù)源的所有參數(shù),如連接字符串、URL 以及用戶名密碼等.

映射關(guān)系K由兩部分構(gòu)成:標(biāo)簽映射Kl:(E∪R)→L表示標(biāo)簽與ER 元素之間的映射關(guān)系,即實(shí)體集合與關(guān)系由一個(gè)標(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é)點(diǎn)集合映射為Entity,而將具有同樣Label的邊集合映射為Relation.

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

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

4.2 中間查詢計(jì)劃

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

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

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

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

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

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

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

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

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

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

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

5 案例示范

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

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

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

圖3 BAF4DUA 案例工具類

SELECT ＜RESULT＞

FROM ＜TABLES＞

WHERE ＜CONDITION＞

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

MATCH ＜ENTITY＞

MATCH ＜RELATION＞

WHERE ＜CONDITION＞

RETURN ＜RESULT＞

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

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

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

為了驗(yà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ù)查詢時(shí)間進(jìn)行了統(tǒng)計(jì),其中MySQL、Neo4j和MongoDB 數(shù)據(jù)庫的運(yùn)行環(huán)境如表2所示,查詢時(shí)間結(jié)果如表3所示.在數(shù)據(jù)導(dǎo)入過程中,TPCH 數(shù)據(jù)集的8 個(gè)文件分別導(dǎo)出為MongoDB的8 個(gè)Collection 以及Neo4j的8 類節(jié)點(diǎn).根據(jù)TPCH提供的ER 模型,我們在Neo4j 中創(chuàng)建了節(jié)點(diǎn)之間的邊.需要說明的是,TPCH 數(shù)據(jù)集的不同導(dǎo)入方式以及索引會對后續(xù)查詢時(shí)間產(chǎn)生一定影響.

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

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

由表3可知,查詢語言轉(zhuǎn)換時(shí)間在70 ms 內(nèi),相對于數(shù)據(jù)查詢時(shí)間占比最高不大于1%,并且隨著數(shù)據(jù)量的增加查詢語言轉(zhuǎn)換的時(shí)間占比會越來越少.由于Mongo 命令的解碼過程使用了第三方的JSON 轉(zhuǎn)換工具,因此中間查詢計(jì)劃解碼為MongoDB 接口的時(shí)間要比其它接口的解碼時(shí)間更多,故而查詢語言的編碼時(shí)間均在10 ms 以下.總體而言,在提高開發(fā)效率與系統(tǒng)擴(kuò)展性、滿足數(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對用戶信息進(jìn)行緩存.此時(shí)系統(tǒng)開發(fā)需同時(shí)使用SQL 與Redis 語言進(jìn)行數(shù)據(jù)查詢,如果能夠?qū)QL、Mongo 命令以及Cypher 編碼為中間查詢計(jì)劃,同時(shí)將中間查詢計(jì)劃解碼為Redis 查詢語句,那么系統(tǒng)就可以為不同主數(shù)據(jù)庫增加緩存功能,并且保持系統(tǒng)開發(fā)的接口統(tǒng)一性.

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

表4 中間查詢計(jì)劃與Redis 運(yùn)算映射

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

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

案例2.數(shù)據(jù)統(tǒng)一管理:科學(xué)數(shù)據(jù)管理系統(tǒng)通常會查詢多個(gè)數(shù)據(jù)源,甚至?xí){(diào)用不同學(xué)科的數(shù)據(jù)源來驗(yàn)證假設(shè)的真?zhèn)?國家重點(diǎn)研發(fā)計(jì)劃“科學(xué)大數(shù)據(jù)管理系統(tǒng)”項(xiàng)目為用戶提供包括天文、高能物理和微生物3 種異構(gòu)數(shù)據(jù)在內(nèi)的多元異構(gòu)數(shù)據(jù)的統(tǒng)一訪問接口.以高能物理數(shù)據(jù)處理系統(tǒng)EventDB[17]為例,它通過分布式存儲與數(shù)據(jù)索引,能夠?qū)Ω吣芪锢韺?shí)驗(yàn)中產(chǎn)生的EB級事例進(jìn)行存儲與查詢.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 小時(shí)內(nèi)1 號探測器、12 號通道、0 號事件的脈沖跨度的變化情況.

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

表5 中間查詢計(jì)劃與EventDB 運(yùn)算映射

假設(shè)用戶習(xí)慣按照探測器進(jìn)行事例查詢,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)系首先編碼為中間查詢計(jì)劃,然后轉(zhuǎn)換為EventDB 查詢命令.

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

6 結(jié)論與展望

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

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