滕愛國(guó)，單新文，王鵬飛，陶曄波，閭 龍，顧玉皎

(國(guó)網(wǎng)江蘇省電力有限公司，江蘇 南京 210016)

0 引 言

隨著電力信息化的推進(jìn)和智能變電站、智能電表、實(shí)時(shí)監(jiān)測(cè)系統(tǒng)、現(xiàn)場(chǎng)移動(dòng)檢修系統(tǒng)、測(cè)控一體化系統(tǒng)以及一大批服務(wù)于各個(gè)專業(yè)的信息管理系統(tǒng)的建設(shè)和應(yīng)用，電力系統(tǒng)的數(shù)據(jù)的規(guī)模和種類快速增長(zhǎng)，這些數(shù)據(jù)共同構(gòu)成了智能電力大數(shù)據(jù)[1]。這些電力系統(tǒng)大數(shù)據(jù)不僅包括電力設(shè)備的運(yùn)行狀態(tài)參數(shù)數(shù)據(jù)，也包含了電力設(shè)備臺(tái)賬、電力系統(tǒng)周邊氣象環(huán)境、設(shè)備所處于的地理信息等相關(guān)數(shù)據(jù)。由于電力系統(tǒng)大數(shù)據(jù)的數(shù)據(jù)量大、涉及的結(jié)構(gòu)類型多、數(shù)據(jù)增長(zhǎng)快的特征，傳統(tǒng)的大數(shù)據(jù)存儲(chǔ)技術(shù)已經(jīng)無法適應(yīng)電力系統(tǒng)大數(shù)據(jù)環(huán)境下的存儲(chǔ)查詢需求，目前國(guó)內(nèi)外研究者主要是基于Hadoop 平臺(tái)的分布式文件系統(tǒng)為海量數(shù)據(jù)提供服務(wù)匹配查詢[2-7]。當(dāng)前不少研究是將語義網(wǎng)思想引入大數(shù)據(jù)處理能力的云計(jì)算Hadoop技術(shù)[8-9]，其主要針對(duì)Hadoop平臺(tái)的RDF數(shù)據(jù)存儲(chǔ)和服務(wù)匹配查詢方法。RDF是用于語義Web數(shù)據(jù)管理的定向標(biāo)記圖和數(shù)據(jù)模型，RDF的每個(gè)語句都將主語，謂語和賓語表示為三元組，表示用于創(chuàng)建SPARQL查詢。創(chuàng)建SPARQL查詢語言并與URI匹配并生成新的RDF圖，對(duì)于新的RDF圖，將創(chuàng)建SPARQL查詢并執(zhí)行MapReduce作業(yè)描述邏輯[10-13]。此外部分研究首先通過定義相關(guān)概念來表示應(yīng)用程序域的知識(shí)域，然后使用概念來指定域中發(fā)生的對(duì)象和個(gè)體的屬性[13-16]。為了減少存儲(chǔ)在HDFS(Hadoop分布式文件系統(tǒng))中的電力數(shù)據(jù)集，當(dāng)前主要研究使用了MapReduce框架[17-19]。部分研究是通過資源描述框架(RDF)存儲(chǔ)和表示數(shù)據(jù)的有效模型，其使用RDF框架將結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換為機(jī)器可讀形式[20-22]。但是由于電力市場(chǎng)數(shù)據(jù)數(shù)據(jù)結(jié)構(gòu)復(fù)雜、種類繁多，除傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)外，還包含大量的半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，如服務(wù)系統(tǒng)的語音數(shù)據(jù)，檢測(cè)數(shù)據(jù)中的波形數(shù)據(jù)、直升機(jī)巡檢中拍攝的圖像數(shù)據(jù)等。提取用戶輸入的準(zhǔn)確信息是電力大數(shù)據(jù)中信息匹配檢索系統(tǒng)的主要缺點(diǎn)和難點(diǎn)。

為了克服匹配問題，文中基于描述邏輯提出一種匹配模型,該模型的描述邏輯包括TBox和ABox，其模型將個(gè)體和普遍分開量化。該模型可以匹配用戶輸入本體數(shù)據(jù)庫(kù)，并能正式化電力信息域作為類和實(shí)例。DL結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化信息格式通過Hadoop處理以獲得最佳格式匹配服務(wù)平臺(tái),SPARQL查詢用于查詢存儲(chǔ)在Mongodb中的數(shù)據(jù)進(jìn)行匹配處理查詢。文中提出的匹配系統(tǒng)在查詢響應(yīng)時(shí)間方面有所改進(jìn),在迭代時(shí)間上大幅度降低。

1 Hadoop和MapReduce

為了有效地處理和存儲(chǔ)大量RDF數(shù)據(jù)，文中使用了Hadoop框架。Hadoop[12]是一個(gè)開源實(shí)現(xiàn)，支持跨商品服務(wù)器集群分布式處理大型數(shù)據(jù)集。它能夠連接和協(xié)調(diào)集群內(nèi)的數(shù)千個(gè)節(jié)點(diǎn)。Hadoop框架有兩個(gè)組件，如HDFS[6]和MapReduce[13]。Hadoop平臺(tái)生態(tài)系統(tǒng)包括兩部分：分布式存儲(chǔ)和并行計(jì)算機(jī)。Hadoop系統(tǒng)平臺(tái)主要使用名字節(jié)點(diǎn)作為分布存儲(chǔ)的主控節(jié)點(diǎn)，其目的用名字節(jié)點(diǎn)來存儲(chǔ)和管理分布式文件系統(tǒng)的元數(shù)據(jù)。Hadoop系統(tǒng)使用數(shù)字節(jié)點(diǎn)作為實(shí)際存儲(chǔ)大規(guī)模數(shù)據(jù)的從屬節(jié)點(diǎn)，每個(gè)從屬節(jié)點(diǎn)存儲(chǔ)實(shí)際的電力大數(shù)據(jù)。在并行分布計(jì)算架構(gòu)上，Hadoop系統(tǒng)使用JobTracker作為MapReduce的并行計(jì)算框架主控節(jié)點(diǎn)，其目的用來管理、調(diào)度作業(yè)的執(zhí)行。MapReduce的并行計(jì)算框架是基于HDFS之上建立的，其框架包含一個(gè)JobTracker和若干TaskTracker。

為了提高大數(shù)據(jù)處理的效率，Hadoop系統(tǒng)首先讓每個(gè)TaskTracker處理存儲(chǔ)在本地?cái)?shù)字節(jié)點(diǎn)的數(shù)據(jù)。MapReduce是Hadoop平臺(tái)的最核心的組件之一。MapReduce技術(shù)是采用對(duì)數(shù)據(jù)“分而治之”的策略實(shí)現(xiàn)并行化處理。每一個(gè)Map的任務(wù)根據(jù)不同的鍵值對(duì)產(chǎn)生新的鍵值對(duì)，然后將這些新產(chǎn)生的鍵值對(duì)傳遞給Reduce，之后再由每個(gè)Reduce根據(jù)所提出的需求分別執(zhí)行相應(yīng)的任務(wù)，最后，Hadoop系統(tǒng)匯總所有Reduce任務(wù)的數(shù)據(jù)結(jié)果。Hadoop平臺(tái)的主控節(jié)點(diǎn)主要負(fù)責(zé)作業(yè)的調(diào)度和處理，同時(shí)將任務(wù)進(jìn)行分割和分配從屬節(jié)點(diǎn)，和重新啟動(dòng)已經(jīng)失敗的任務(wù)等各種工作。從屬節(jié)點(diǎn)與數(shù)據(jù)節(jié)點(diǎn)一般都是配置在同一個(gè)節(jié)點(diǎn)上，其主要目的是負(fù)責(zé)執(zhí)行JobTracker分發(fā)下來的任務(wù)和管理各自節(jié)點(diǎn)上的任務(wù)，并與JobTracker進(jìn)行交互通信。任務(wù)一般分為Map Task和Reduce，且由TaskTracker啟動(dòng)。JobTracker與TaskTracker是通過心跳進(jìn)行實(shí)際通信的。

使用DataNode創(chuàng)建并與NameNode匹配的SPARQL查詢，并生成RDF圖。為RDF圖創(chuàng)建SPARQL查詢語言，并從HDFS中檢索數(shù)據(jù)。Gapstetep有兩個(gè)節(jié)點(diǎn)，如主節(jié)點(diǎn)和工作節(jié)點(diǎn)[5]。主節(jié)點(diǎn)拆分?jǐn)?shù)據(jù)并分配數(shù)據(jù)keyvalue對(duì)。主節(jié)點(diǎn)選擇空閑工作器并為每個(gè)工作服務(wù)器分配一個(gè)映射任務(wù)以設(shè)置HDFS專為數(shù)據(jù)存儲(chǔ)而設(shè)計(jì)，MapReduce用于數(shù)據(jù)處理。MapReduce用于執(zhí)行SPARQL查詢并在大量節(jié)點(diǎn)上提供并行處理以簡(jiǎn)化數(shù)據(jù)[11]。將密鑰值對(duì)發(fā)送回主節(jié)點(diǎn)。主節(jié)點(diǎn)存儲(chǔ)有關(guān)數(shù)據(jù)位置的詳細(xì)信息。Reduce函數(shù)采用中間鍵值對(duì)，并縮減為較小的解。基于較小的解決方案，再次創(chuàng)建SPARQL查詢語言[15-16]。

2 基于描述邏輯服務(wù)匹配架構(gòu)模型

本體是通過概念之間的交互關(guān)系來進(jìn)行描述概念的一種語義，也是一種能夠有效表達(dá)概念層次結(jié)構(gòu)和語義的模型。 目前本體模型廣泛應(yīng)用于計(jì)算機(jī)科學(xué)的各個(gè)領(lǐng)域。最近幾年國(guó)內(nèi)外主要流行的本體語言有很多種，但是每種流行的本體語言各有其不同特點(diǎn)，在這些流行的本體語言中以W3C最為代表性。目前OWL是W3C的最新標(biāo)準(zhǔn)。OWL語言主要分為三個(gè)子語言，分別是OWL-Lite、OWL-DL和OWL-Full。其中OWL-DL是基于DL的語言，OWL-DL不同可以用來自動(dòng)推理，而且也可以用來判別本體中的分類層次和概念的一致性，其表達(dá)能力最為豐富。

文中基于描述邏輯提出一種服務(wù)匹配架構(gòu)模型，如圖1所示。該架構(gòu)包括用于存儲(chǔ)和查詢RDF數(shù)據(jù)的幾個(gè)組件。描述邏輯基于RDF框架的格式將結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換為DL。處理結(jié)果通過Hadoop組件生成SPARQL查詢語言，查詢語言與Mongodb匹配輸出處理結(jié)果。在該體系模型結(jié)構(gòu)中，轉(zhuǎn)換用戶輸入非結(jié)構(gòu)化的數(shù)據(jù)是通過匹配用戶輸入來構(gòu)造本體數(shù)據(jù)庫(kù)并將信息形式轉(zhuǎn)化為類。用戶輸入通過匹配轉(zhuǎn)換為結(jié)構(gòu)格式用戶輸入，并以本體數(shù)據(jù)庫(kù)形式化信息作為類和實(shí)例。模型中的說明語言轉(zhuǎn)換器使用TBox和ABox來描述概念定義，包含和斷言。OWL DL公理是基于RDF框架來形式化數(shù)據(jù)，同時(shí)基于Hadoop框架存儲(chǔ)和查詢RDF數(shù)據(jù)。

圖1 基于描述邏輯的服務(wù)匹配模型架構(gòu)

通常描述邏輯表示知識(shí)庫(kù)主要是由TBox和ABox兩部分組成。其中TBox主要定義了特定知識(shí)領(lǐng)域的結(jié)構(gòu)和包含一系列公理，包括通過已有概念構(gòu)成新的概念。而ABox則主要包含TBox中概念的實(shí)例。一般來說TBox具有分類的能力，而ABox主要是將與TBox中的類相對(duì)應(yīng)的實(shí)例寫入，其所建立的實(shí)例必須符合TBox中類設(shè)計(jì)的限制和屬性。一般來說這些類的實(shí)體稱為實(shí)例，主要因?yàn)檫@些實(shí)例能夠?qū)⒃瓉碇痪哂懈拍畹募軜?gòu)，組合成具體實(shí)體知識(shí)關(guān)系的架構(gòu)。其中TBox可以描述領(lǐng)域結(jié)構(gòu)的公理的集合引入概念的名稱，例如表示類(一元謂詞){x|Byaqi(x)}。此外TBox還可以聲明包含關(guān)系的公理(屬性，二元謂詞){|Byaqi(x,y)}。ABox描述具體清晰的公理：例如表達(dá)一個(gè)對(duì)象是否屬于某一個(gè)概念b:C or C(b)，Byaqi(Tom)表示Tom是一個(gè)變壓器，也可以用Tom:變壓器表示，ABox關(guān)系斷言：表示兩個(gè)對(duì)象是否滿足一定的關(guān)系:R or R(a,b)。

HBase平臺(tái)是采用與傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)類似的表概念來表達(dá)，在HBase中HTable行鍵是行的唯一標(biāo)志符，HBase數(shù)據(jù)庫(kù)對(duì)行鍵提供與B+樹類似的高效索引[14]。由于三元組所表達(dá)的三個(gè)成分的謂詞數(shù)量比較少，如果在實(shí)現(xiàn)過程中不進(jìn)行切分，容易導(dǎo)致以謂詞作為HTable的行鍵的表過寬，最終導(dǎo)致列名和值進(jìn)行匹配耗時(shí)，從而影響HBase數(shù)據(jù)庫(kù)的查詢效率。因此在實(shí)際實(shí)現(xiàn)中將每個(gè)謂詞對(duì)應(yīng)兩張HTable，這樣以謂詞的三元組主語/賓語作為行鍵，另外的一成分為列名。這樣做的好處是，對(duì)固定的三元組謂詞進(jìn)行查詢的時(shí)候，能快速匹配出結(jié)果，但對(duì)于謂詞不固定的三元組，不得不需要遍歷所有的數(shù)據(jù)表，導(dǎo)致匹配的速度變慢。為了解決這個(gè)問題，文中在上述基礎(chǔ)上增加 CP_O、PO_C和OC_P三張索引表，目的是加速響應(yīng)不固定的三元組謂詞匹配，從而達(dá)到快速匹配效果。謂詞表行的結(jié)構(gòu)采用如下表達(dá)方式。

Row Key:主體1 {

Column變壓器 {

Column:客體1

Column:客體2

Column:客體3

…

}

}

文中在CP_O表行結(jié)構(gòu)中采用如下形式表達(dá)，即把主語和謂詞的有序?qū)ψ鳛樾墟I對(duì)。其中PO_C和OC_P的表結(jié)構(gòu)與CP_O類似。

Row Key:(主體1，Predicate1) {

Column變壓器 {

Column:客體1

Column:客體2

Column:客體3

…

}

}

3 實(shí) 驗(yàn)

3.1 實(shí)驗(yàn)環(huán)境和實(shí)驗(yàn)設(shè)置

采用Hadoop2.6和HBase2.0版本在五臺(tái)PC機(jī)(Intel酷睿核CPU，內(nèi)存8 GB)上進(jìn)行實(shí)驗(yàn)，將Hadoop作為運(yùn)行平臺(tái)，HBase用來存儲(chǔ)RDF數(shù)據(jù)。實(shí)驗(yàn)基于電力網(wǎng)地理數(shù)據(jù)集。生成了地理數(shù)據(jù)集，并將RDW模型中的本體類型以O(shè)WL格式表示。收集了9個(gè)RDF類和14個(gè)屬性，收集數(shù)據(jù)集的RDF三元組以表示OWL-DL格式。來自用戶的查詢用OWL表示以找到語義關(guān)系。出于實(shí)驗(yàn)的目的，使用SPARQL查詢語言。這是因?yàn)閷?shí)驗(yàn)測(cè)試了使用本體匹配為查詢提取準(zhǔn)確信息的性能。用于評(píng)估的示例查詢顯示如表1所示。

表1中，電力地理數(shù)據(jù)集拆分大小可提高使用復(fù)制模型的Hadoop性能。SPARQL查詢的大量三元組作為文件存儲(chǔ)在HDFS中，并且使用了更多的空間。實(shí)驗(yàn)基于信息檢索(IR)的語義搜索。在搜索引擎中，IR基于關(guān)鍵字并返回不太相關(guān)的文檔。提出的搜索方法是使用本體匹配技術(shù)和MapReduce來開發(fā)信息檢索的有效查詢。該模型通過應(yīng)用MapReduce，本體模型基于語義相似性給出相關(guān)的RDF數(shù)據(jù)集?？梢栽谔囟ǖ膔educer中加入相關(guān)的RDF數(shù)據(jù)集，因此，在搜索引擎中準(zhǔn)確地檢索相關(guān)信息以用于用戶輸入。三個(gè)查詢分別作用在三元組250 K，1 M，5 M，及其相對(duì)應(yīng)的RDF數(shù)據(jù)37 M，158 M，782 M。文檔分別是11，43，202，每個(gè)文檔的行數(shù)是25 000。

表1 查詢集

上述最佳分割尺寸地理數(shù)據(jù)集，以減少文本數(shù)據(jù)的大小。第一列表示查詢，第二列表示三元組的集合。作為三倍數(shù)大小增加RDF數(shù)據(jù)大小，文檔和行每個(gè)文檔的大小也會(huì)增加。三倍大小為250 K，1 M和5 M，提供了25 000英寸的一致結(jié)果。觀察到文件的分割大小減少了響應(yīng)查詢的時(shí)間。

3.2 實(shí)驗(yàn)結(jié)果與分析

實(shí)驗(yàn)基于語義搜索信息檢索(IR)。在搜索引擎中，IR基于關(guān)鍵字和返回不太相關(guān)的文件。該模型的搜索方法是使用本體匹配技術(shù)和MapReduce開發(fā)高效查詢信息檢索。通過應(yīng)用MapReduce，本體模型給出了基于語義相似性的相關(guān)RDF數(shù)據(jù)集?？梢约尤胂嚓P(guān)的RDF數(shù)據(jù)集在特定的減速機(jī)中，因此，相關(guān)信息是在搜索引擎中準(zhǔn)確檢索用戶輸入。

3.2.1 查詢處理的迭代時(shí)間

為電力地理數(shù)據(jù)集生成了SPARQL查詢，并以秒為單位計(jì)算了迭代時(shí)間。在圖2～圖4中，X軸表示數(shù)據(jù)格式，Y軸表示以秒為單位的迭代時(shí)間。對(duì)于X軸，有四列分別顯示非結(jié)構(gòu)化數(shù)據(jù)格式，OWL格式，OWL-DL和OWL-DL與Hadoop實(shí)現(xiàn)的結(jié)果。實(shí)驗(yàn)中，OWL和OWL-DL計(jì)算迭代時(shí)間基于SPARQL查詢中的三元組數(shù)。在圖2中，非結(jié)構(gòu)化數(shù)據(jù)格式的后續(xù)迭代需要9.3秒，而使用Hadoop的OWL-DL需要0.5秒。圖2和圖3中的結(jié)果表明，非結(jié)構(gòu)化數(shù)據(jù)格式提供了最差的迭代時(shí)間，而使用Hadoop的OWL-DL提供了最佳的迭代時(shí)間。在圖4中，查詢大小增加，第1列中的后續(xù)迭代時(shí)間為591.5秒，第4列為123.4秒。觀察到OWL-DL與Hadoop的性能在大型地理數(shù)據(jù)集中也很有效。查詢Q4中的FILTER條件減少了圖4中的迭代時(shí)間，并且提高了性能。因此，這些結(jié)果表明，帶有Hadoop的OWL-DL為地理數(shù)據(jù)集提供了最佳的迭代時(shí)間。

圖2 第一個(gè)查詢的迭代時(shí)間

圖3 第二個(gè)查詢的迭代時(shí)間

圖4 第三個(gè)查詢的迭代時(shí)間

3.2.2 查詢處理的響應(yīng)時(shí)間

測(cè)量了電力地理數(shù)據(jù)集的不同SPARQL查詢的響應(yīng)時(shí)間。在圖5～圖7中，X軸表示數(shù)據(jù)格式，Y軸表示以秒為單位的響應(yīng)時(shí)間。該實(shí)現(xiàn)顯示了不同數(shù)據(jù)格式的性能比較，以秒為單位。MapReduce在OWL-DL中與Hadoop一起使用，以減少數(shù)據(jù)集并提供最佳響應(yīng)時(shí)間。

圖5 第一個(gè)查詢的響應(yīng)時(shí)間

圖7 第三個(gè)查詢的響應(yīng)時(shí)間

在圖5中，非結(jié)構(gòu)化數(shù)據(jù)格式需要80.3秒，而帶有Hadoop的OWL-DL需要39.1秒。結(jié)果表明在使用Hadoop的OWL-DL中實(shí)現(xiàn)了有效的查詢處理，并且與其他格式相比，響應(yīng)時(shí)間較短。

圖6、圖7顯示每個(gè)SPARQL查詢的查詢時(shí)間因線性大而增加，因?yàn)榇笮蚏DF數(shù)據(jù)集顯示了使用Hadoop的OWL-DL中的最佳響應(yīng)時(shí)間。觀察到X軸的第一列顯示最差響應(yīng)時(shí)間，最后一列顯示最佳響應(yīng)時(shí)間。帶有Hadoop的OWL-DL使用MapReduce并減少不需要的數(shù)據(jù)集。

圖6 第二個(gè)查詢的響應(yīng)時(shí)間

3.2.3 查詢地理數(shù)據(jù)集的運(yùn)行時(shí)間

電力地理數(shù)據(jù)集的查詢運(yùn)行時(shí)間基于三元組的數(shù)量計(jì)算。表2顯示了從地理數(shù)據(jù)集收集的不同數(shù)量的三元組的查詢時(shí)間。 第一列表示三元組的數(shù)量，范圍在1 200萬到6 000萬之間。第2列到第6列表示來自表1的5個(gè)選定查詢并計(jì)算運(yùn)行時(shí)間。查詢Q1很簡(jiǎn)單，120萬次三重奏需要67.4秒，1 200萬次傳輸需要242.8秒。由于查詢大小的增加，查詢Q5花了68.5秒到220.8秒。觀察到三元組的數(shù)量增加了，回答查詢的時(shí)間也增加了。

表2 地理數(shù)據(jù)集查詢運(yùn)行時(shí)間

4 結(jié)束語

針對(duì)電力大數(shù)據(jù)呈現(xiàn)的復(fù)雜性和異構(gòu)性以及地理圖數(shù)據(jù)在服務(wù)匹配查詢中困難的問題，提出基于Hadoop平臺(tái)電力數(shù)據(jù)服務(wù)匹配查詢模型，該模型是基于TBox和ABox組件的描述邏輯。該模型采用描述邏輯使得MapReduce操作在執(zhí)行Hadoop簡(jiǎn)化了查詢和匹配過程，其查詢DL結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)在Mongodb中。最后基于實(shí)際數(shù)據(jù)進(jìn)行大量實(shí)驗(yàn)，結(jié)果證明了所提出的系統(tǒng)模型提供了最小的搜索時(shí)間和最佳的匹配準(zhǔn)確度。下一步的工作包括擴(kuò)展DL模式通過集成Hyperclique和Lattice模式進(jìn)行匹配。