基于Hadoop平臺電力數據服務匹配查詢性能研究

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

(國網江蘇省電力有限公司，江蘇 南京 210016)

0 引 言

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

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

1 Hadoop和MapReduce

為了有效地處理和存儲大量RDF數據，文中使用了Hadoop框架。Hadoop[12]是一個開源實現，支持跨商品服務器集群分布式處理大型數據集。它能夠連接和協調集群內的數千個節點。Hadoop框架有兩個組件，如HDFS[6]和MapReduce[13]。Hadoop平臺生態系統包括兩部分：分布式存儲和并行計算機。Hadoop系統平臺主要使用名字節點作為分布存儲的主控節點，其目的用名字節點來存儲和管理分布式文件系統的元數據。Hadoop系統使用數字節點作為實際存儲大規模數據的從屬節點，每個從屬節點存儲實際的電力大數據。在并行分布計算架構上，Hadoop系統使用JobTracker作為MapReduce的并行計算框架主控節點，其目的用來管理、調度作業的執行。MapReduce的并行計算框架是基于HDFS之上建立的，其框架包含一個JobTracker和若干TaskTracker。

為了提高大數據處理的效率，Hadoop系統首先讓每個TaskTracker處理存儲在本地數字節點的數據。MapReduce是Hadoop平臺的最核心的組件之一。MapReduce技術是采用對數據“分而治之”的策略實現并行化處理。每一個Map的任務根據不同的鍵值對產生新的鍵值對，然后將這些新產生的鍵值對傳遞給Reduce，之后再由每個Reduce根據所提出的需求分別執行相應的任務，最后，Hadoop系統匯總所有Reduce任務的數據結果。Hadoop平臺的主控節點主要負責作業的調度和處理，同時將任務進行分割和分配從屬節點，和重新啟動已經失敗的任務等各種工作。從屬節點與數據節點一般都是配置在同一個節點上，其主要目的是負責執行JobTracker分發下來的任務和管理各自節點上的任務，并與JobTracker進行交互通信。任務一般分為Map Task和Reduce，且由TaskTracker啟動。JobTracker與TaskTracker是通過心跳進行實際通信的。

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

2 基于描述邏輯服務匹配架構模型

本體是通過概念之間的交互關系來進行描述概念的一種語義，也是一種能夠有效表達概念層次結構和語義的模型。 目前本體模型廣泛應用于計算機科學的各個領域。最近幾年國內外主要流行的本體語言有很多種，但是每種流行的本體語言各有其不同特點，在這些流行的本體語言中以W3C最為代表性。目前OWL是W3C的最新標準。OWL語言主要分為三個子語言，分別是OWL-Lite、OWL-DL和OWL-Full。其中OWL-DL是基于DL的語言，OWL-DL不同可以用來自動推理，而且也可以用來判別本體中的分類層次和概念的一致性，其表達能力最為豐富。

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

圖1 基于描述邏輯的服務匹配模型架構

通常描述邏輯表示知識庫主要是由TBox和ABox兩部分組成。其中TBox主要定義了特定知識領域的結構和包含一系列公理，包括通過已有概念構成新的概念。而ABox則主要包含TBox中概念的實例。一般來說TBox具有分類的能力，而ABox主要是將與TBox中的類相對應的實例寫入，其所建立的實例必須符合TBox中類設計的限制和屬性。一般來說這些類的實體稱為實例，主要因為這些實例能夠將原來只具有概念的架構，組合成具體實體知識關系的架構。其中TBox可以描述領域結構的公理的集合引入概念的名稱，例如表示類(一元謂詞){x|Byaqi(x)}。此外TBox還可以聲明包含關系的公理(屬性，二元謂詞){|Byaqi(x,y)}。ABox描述具體清晰的公理：例如表達一個對象是否屬于某一個概念b:C or C(b)，Byaqi(Tom)表示Tom是一個變壓器，也可以用Tom:變壓器表示，ABox關系斷言：表示兩個對象是否滿足一定的關系:R or R(a,b)。

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

Row Key:主體1 {

Column變壓器 {

Column:客體1

Column:客體2

Column:客體3

…

}

}

文中在CP_O表行結構中采用如下形式表達，即把主語和謂詞的有序對作為行鍵對。其中PO_C和OC_P的表結構與CP_O類似。

Row Key:(主體1，Predicate1) {

Column變壓器 {

Column:客體1

Column:客體2

Column:客體3

…

}

}

3 實 驗

3.1 實驗環境和實驗設置

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

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

表1 查詢集

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

3.2 實驗結果與分析

實驗基于語義搜索信息檢索(IR)。在搜索引擎中，IR基于關鍵字和返回不太相關的文件。該模型的搜索方法是使用本體匹配技術和MapReduce開發高效查詢信息檢索。通過應用MapReduce，本體模型給出了基于語義相似性的相關RDF數據集。可以加入相關的RDF數據集在特定的減速機中，因此，相關信息是在搜索引擎中準確檢索用戶輸入。

3.2.1 查詢處理的迭代時間

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

圖2 第一個查詢的迭代時間

圖3 第二個查詢的迭代時間

圖4 第三個查詢的迭代時間

3.2.2 查詢處理的響應時間

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

圖5 第一個查詢的響應時間

圖7 第三個查詢的響應時間

在圖5中，非結構化數據格式需要80.3秒，而帶有Hadoop的OWL-DL需要39.1秒。結果表明在使用Hadoop的OWL-DL中實現了有效的查詢處理，并且與其他格式相比，響應時間較短。

圖6、圖7顯示每個SPARQL查詢的查詢時間因線性大而增加，因為大型RDF數據集顯示了使用Hadoop的OWL-DL中的最佳響應時間。觀察到X軸的第一列顯示最差響應時間，最后一列顯示最佳響應時間。帶有Hadoop的OWL-DL使用MapReduce并減少不需要的數據集。

圖6 第二個查詢的響應時間

3.2.3 查詢地理數據集的運行時間

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

表2 地理數據集查詢運行時間

4 結束語

針對電力大數據呈現的復雜性和異構性以及地理圖數據在服務匹配查詢中困難的問題，提出基于Hadoop平臺電力數據服務匹配查詢模型，該模型是基于TBox和ABox組件的描述邏輯。該模型采用描述邏輯使得MapReduce操作在執行Hadoop簡化了查詢和匹配過程，其查詢DL結構化數據存儲在Mongodb中。最后基于實際數據進行大量實驗，結果證明了所提出的系統模型提供了最小的搜索時間和最佳的匹配準確度。下一步的工作包括擴展DL模式通過集成Hyperclique和Lattice模式進行匹配。