黃華林 龐欣婷

1(廣西電網(wǎng)有限責任公司 廣西 南寧 530000) 2(廣西第一工業(yè)學校 廣西 南寧 530000)

0 引 言

隨著信息化時代的到來與人工智能技術(shù)的不斷發(fā)展，世界各主要國家相繼提出“智能電網(wǎng)”這一概念。近幾年，各國均在大力推進智能電網(wǎng)項目的建設(shè)與發(fā)展。隨著智能電網(wǎng)建設(shè)進程的逐步深入，智能電網(wǎng)所產(chǎn)出的數(shù)據(jù)量也呈指數(shù)式增長，特別是智能電網(wǎng)的電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)[1-3]。這對智能電網(wǎng)的數(shù)據(jù)管理平臺的可靠性和實時性均提出了更高的要求，傳統(tǒng)的數(shù)據(jù)管理模式遠遠不能滿足這些求需求[4]。因此，在智能電網(wǎng)中，研究如何存儲、管理和共享這些關(guān)鍵數(shù)據(jù)成為急需解決的關(guān)鍵問題。

電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的顯著特點是數(shù)據(jù)規(guī)模大，且數(shù)據(jù)是由分布在不同地域的設(shè)備采集的，需要分布式管理。Hadoop是一個開源的云計算架構(gòu)，具備可靠性高、數(shù)據(jù)處理量大以及容錯性高等優(yōu)勢，已經(jīng)成為信息領(lǐng)域研究的熱點[5-6]。

為解決智能電網(wǎng)中海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的高效管理，本文設(shè)計了基于Hadoop的數(shù)據(jù)資源管理平臺。首先分析了海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)管理平臺結(jié)構(gòu)與功能；然后分別針對海量電網(wǎng)數(shù)據(jù)分布式存儲和海量數(shù)據(jù)檢索提出了基于Hadoop集群的存儲方法和基于MapReduce的數(shù)據(jù)檢索方法；最后對數(shù)據(jù)資源管理平臺進行了性能測試。

1 平臺結(jié)構(gòu)與功能

海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)資源管理平臺的主要目的是實現(xiàn)海量、分布的電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的高性能存儲和檢索，為后續(xù)高效準確地實現(xiàn)電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的分析與挖掘奠定基礎(chǔ)。整個電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)管理平臺有四個模塊構(gòu)成：元數(shù)據(jù)管理模塊、信息管理模塊、節(jié)點管理模塊和海量存儲模塊。基于分布式結(jié)構(gòu)設(shè)計數(shù)據(jù)管理平臺，實現(xiàn)了不同地區(qū)電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的高效集中，主節(jié)點的服務(wù)器可以對其他節(jié)點數(shù)據(jù)進行有效的調(diào)度與管理。數(shù)據(jù)資源管理平臺的結(jié)構(gòu)圖如圖1所示。

圖1 平臺總體結(jié)構(gòu)

1.1 元數(shù)據(jù)管理模塊

平臺基于XML Schema實現(xiàn)元數(shù)據(jù)的表示規(guī)范、元數(shù)據(jù)界面生成方法以及元數(shù)據(jù)的組織管理，基于元數(shù)據(jù)實現(xiàn)電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的有效分類與管理。XML Schema不但可以對電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)進行分類存儲和檢索，還可以實現(xiàn)數(shù)據(jù)的動態(tài)管理。平臺的元數(shù)據(jù)管理包含分類管理、Schema管理、XML解析、XML驗證等幾個子功能模塊。各個功能模塊既相互獨立，又有機配合，共同完成對海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的組織管理。平臺元數(shù)據(jù)模塊的組織形式如圖2所示。

圖2 元數(shù)據(jù)管理

1.2 信息管理模塊

基于XML Schema實現(xiàn)海量電網(wǎng)監(jiān)測元數(shù)據(jù)的組織與存儲后，每一類元數(shù)據(jù)都會有相應(yīng)的組織方式，利用XML Schema可以進行高效存儲與檢索。由于海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的復雜性，平臺采用自上而下的方法實現(xiàn)電網(wǎng)信息的元數(shù)據(jù)管理。因此，當用戶上傳數(shù)據(jù)資源后，必須要準確填寫該數(shù)據(jù)資源的描述字段，平臺會自動生成一個描述文件，可以為后續(xù)的數(shù)據(jù)統(tǒng)計和資源檢索提供支撐。此外，用戶上傳數(shù)據(jù)資源后，平臺還會將該資源的物理存儲地址寫入數(shù)據(jù)庫，方便后續(xù)資源維護。圖3為平臺的信息管理流程。

圖3 平臺信息管理流程

1.3 節(jié)點管理模塊

節(jié)點管理模塊是平臺設(shè)計的關(guān)鍵技術(shù)模塊之一。平臺的節(jié)點管理包括節(jié)點信息管理和節(jié)點管理兩部分。在測試目前常用的節(jié)點管理算法(例如隨機算法、輪詢算法、最小負載算法)的基礎(chǔ)上，平臺采用了一種基于抖動系數(shù)的最小負載算法[6]。該算法有效提高了負載均衡，能夠?qū)Ω鱾€子節(jié)點進行動態(tài)監(jiān)測，還可以監(jiān)控布置于各地電網(wǎng)系統(tǒng)的分布式服務(wù)器中的數(shù)據(jù)資源、知識資源以及系統(tǒng)資源等。

1.4 海量存儲模塊

基于對開源Hadoop分布式文件系統(tǒng)(HDFS)[7-9]的測試基礎(chǔ)上，平臺對傳統(tǒng)的存儲架構(gòu)進行了改進，以適應(yīng)對海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的高效存儲、管理與檢索。圖4為平臺設(shè)計的海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的存儲結(jié)構(gòu)與數(shù)據(jù)訪問關(guān)系。海量存儲模塊由三部分構(gòu)成，即存儲端、查詢端與訪問鏈路。海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的來源是網(wǎng)絡(luò)，包括Zigbee網(wǎng)絡(luò)或者以太網(wǎng)等。海量存儲模塊以Hadoop為核心，DataNode中保存各地分布式節(jié)點上傳的電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)。圖4中，海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的實時存儲由左側(cè)的存儲客戶端完成，而海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的檢索查詢功能由右側(cè)的檢索客戶端完成。其中存儲客戶端通常部署在各地的電網(wǎng)監(jiān)測部門，而查詢客戶端位于數(shù)據(jù)中心或數(shù)據(jù)監(jiān)測工作區(qū)內(nèi)。

圖4 數(shù)據(jù)存儲結(jié)構(gòu)與數(shù)據(jù)訪問關(guān)系

2 平臺實現(xiàn)關(guān)鍵技術(shù)

隨著智能電網(wǎng)建設(shè)進程的不斷加快，電力設(shè)備采集的狀態(tài)數(shù)據(jù)類型也不斷增加，例如：用戶數(shù)據(jù)、絕緣子數(shù)據(jù)、報警數(shù)據(jù)、設(shè)備數(shù)據(jù)(張力、傾角等)、線路數(shù)據(jù)等。隨著時間的增長，對存儲這些數(shù)據(jù)所需的空間需求也會越來越大，傳統(tǒng)的數(shù)據(jù)庫無法存儲和處理這些海量的電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)。針對海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的存儲與檢索問題，平臺設(shè)計了基于Hadoop集群的數(shù)據(jù)存儲方式和基于MapReduce的數(shù)據(jù)檢索算法。

2.1 基于Hadoop集群海量數(shù)據(jù)分布式存儲

對海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)進行分類?；跀?shù)據(jù)狀態(tài)，將數(shù)據(jù)分為靜態(tài)數(shù)據(jù)和動態(tài)數(shù)據(jù)兩類。其中靜態(tài)數(shù)據(jù)是指穩(wěn)定性強，占用的存儲空間相對較小的數(shù)據(jù)，包括用戶數(shù)據(jù)、線路數(shù)據(jù)、檢測設(shè)備數(shù)據(jù)、絕緣子數(shù)據(jù)等；動態(tài)數(shù)據(jù)是指數(shù)據(jù)會隨著時間的推移而飛速增長，需要的存儲空間大，包括電網(wǎng)狀態(tài)檢測過程中采集的溫度數(shù)據(jù)、報警數(shù)據(jù)、張力數(shù)據(jù)以及傾角數(shù)據(jù)等。動態(tài)數(shù)據(jù)是電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)存儲與檢索的重點和難點。平臺的靜態(tài)數(shù)據(jù)采用傳統(tǒng)的關(guān)系數(shù)據(jù)庫存儲。針對海量電網(wǎng)狀態(tài)監(jiān)測動態(tài)數(shù)據(jù)的存儲問題，設(shè)計了基于HDFS的快速存儲框架。

在數(shù)據(jù)資源管理平臺中，數(shù)據(jù)的接收與上傳是由存儲客戶端完成的，因此電網(wǎng)狀態(tài)監(jiān)測額數(shù)據(jù)由存儲客戶端上傳到HDFS[10]。為了提高數(shù)據(jù)存儲速度以及減少系統(tǒng)與硬盤的交互次數(shù)，建立一個數(shù)據(jù)緩存區(qū)，用于保存數(shù)據(jù)發(fā)送端傳輸?shù)臄?shù)據(jù)，依據(jù)客戶端數(shù)據(jù)處理能力，自適應(yīng)地設(shè)定緩存區(qū)大小(如64 MB、128 MB)。當接收數(shù)據(jù)存滿緩存區(qū)后，客戶端將數(shù)據(jù)上傳至HDFS。因此，客戶端與HDFS每次交互的數(shù)據(jù)大小相等，既便于數(shù)據(jù)維護，又顯著地減少了數(shù)據(jù)交互次數(shù)與元數(shù)據(jù)量。具體實現(xiàn)流程如圖5所示。

圖5 數(shù)據(jù)存儲流程

2.2 基于MapReduce的海量數(shù)據(jù)檢索算法

為提高海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的檢索效率，平臺設(shè)計了基于MapReduce的海量數(shù)據(jù)檢索算法。該檢索算法中，核心內(nèi)容是Map和Reduce函數(shù)。

檢索客戶端主函數(shù)的功能是實現(xiàn)用戶檢索與MapReduce框架直接的信息交互。在海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)管理平臺中，用戶在檢索過程中，需要錄入的檢索信息包括：檢索文件地址、檢索結(jié)果導出文件地址、檢索關(guān)鍵詞、關(guān)鍵詞位置以及Reducer個數(shù)。檢索算法基于用戶輸入的檢索信息，將符合條件的數(shù)據(jù)進行高效匯總，匯總后的數(shù)據(jù)直接呈現(xiàn)給用戶。因此，數(shù)據(jù)檢索過程的重點是客戶端主函數(shù)和Map函數(shù)。

2.2.1 主函數(shù)

主函數(shù)的重要功能就是設(shè)置與數(shù)據(jù)檢索過程相關(guān)的各個參數(shù)，平臺中需要設(shè)置的檢索參數(shù)如圖6所示。

圖6 主函數(shù)需要設(shè)置的參數(shù)

2.2.2 Map函數(shù)

首先對主函數(shù)導入的檢索信息進行分割形成多個Split，每個Map函數(shù)檢索一個Split，并對存儲的數(shù)據(jù)進行檢索查詢，具體查詢過程如下：

步驟1Map任務(wù)開始，讀取相關(guān)檢索信息。

步驟2讀入一行關(guān)鍵詞數(shù)據(jù)，將數(shù)據(jù)分解為字符串數(shù)組。

步驟3讀取待檢索的存儲數(shù)據(jù)。

步驟4與檢索關(guān)鍵詞匹配。若匹配成功，將鍵值保存如臨時文件；否則繼續(xù)匹配下一個關(guān)鍵詞。

步驟5檢測是否有下一個關(guān)鍵詞。若有，轉(zhuǎn)入步驟4；否則，當前Map任務(wù)結(jié)束。

步驟6導出數(shù)據(jù)檢索結(jié)果。

3 實驗與分析

為驗證文中設(shè)計的海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)管理平臺的性能，在實驗室搭建的Hadoop平臺上進行性能測試。測試的內(nèi)容包括平臺的I/O基準性能、數(shù)據(jù)存儲性能和數(shù)據(jù)檢索性能。測試環(huán)境如下：平臺共有27個節(jié)點，每個節(jié)點客戶端的配置均為8核CPU，主頻3.3 GHz，內(nèi)存8 GB，網(wǎng)絡(luò)為千兆以太網(wǎng)，Hadoop版本2.6.0。

3.1 I/O基準測試

在數(shù)據(jù)管理平臺沒有其他任務(wù)的條件下，基于TestDSFIO進行HDFS的基準I/O性能測試。測試內(nèi)容包括不同文件大小、不同文件個數(shù)時HDFS的時間消耗。

首先，測試20個文件不同文件大小的讀寫操作，測試結(jié)果如圖7所示。圖中繪制了平均寫操作的運行時間和文件整體寫操作的運行時間。測試結(jié)果表明，隨著文件大小的逐漸增加，平臺寫文件的總體時間消耗也逐漸增加，但是平均時間消耗一直在下降。此外，還對讀文件的時間消耗進行測試，測試曲線與圖7的數(shù)值不同但變化趨勢相同。

圖7 文件大小對運行時間的影響

然后，測試平臺對不同文件個數(shù)的讀寫操作，測試結(jié)果如圖8所示。圖8給出的是寫文件的時間消耗，文件大小為100 MB。隨著文件數(shù)量的增多，同樣是總體時間消耗逐漸增加，平均時間消耗下降。

圖8 文件個數(shù)對運行時間影響

3.2 數(shù)據(jù)存儲測試

開啟海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)管理測試平臺，模擬10個數(shù)據(jù)發(fā)送端線程，各線程每秒產(chǎn)生200條數(shù)據(jù)(數(shù)據(jù)量約為32 KB)。數(shù)據(jù)沒間隔2小時上傳一次，每個上傳文件約為120 MB。平臺運行10小時后，統(tǒng)計文件分布情況。測試結(jié)果表明，文件被成功上傳至各個節(jié)點，且資源分配十分均勻，沒有發(fā)生數(shù)據(jù)丟包問題，存儲過程成功完成。

3.3 數(shù)據(jù)檢索測試

設(shè)置發(fā)送端數(shù)據(jù)，模擬文件大小和發(fā)送頻率均不相同的電網(wǎng)數(shù)據(jù)文件。開啟數(shù)據(jù)檢索客戶端，測試數(shù)據(jù)檢索時間消耗。為了驗證平臺的數(shù)據(jù)檢索性能，將同樣數(shù)據(jù)存儲到Oracle系統(tǒng)中，并統(tǒng)計檢索時間消耗。設(shè)置幾組檢索關(guān)鍵詞，分別統(tǒng)計平臺與Oracle系統(tǒng)的數(shù)據(jù)檢索性能，測試結(jié)果如表2所示。表中每組測試均是5次測試所得的平均時間消耗。

表1 檢索時間對比

測試結(jié)果表明，當檢索條數(shù)低于150萬時，Oracle系統(tǒng)的時間消耗較少，但是隨著檢索條數(shù)的繼續(xù)增加，基于Hadoop的集群檢索優(yōu)勢得到了充分的體現(xiàn)，檢索耗費時間明顯少于Oracle系統(tǒng)。測試實驗驗證了平臺更適合海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的檢索。

4 結(jié) 語

本文研究了智能電網(wǎng)中海量電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的存儲與管理問題，設(shè)計了基于Hadoop的海量數(shù)據(jù)管理平臺。測試結(jié)果表明，該平臺能夠高效地存儲與檢索海量數(shù)據(jù)。平臺的設(shè)計為不同地區(qū)電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的分布式存儲和管理奠定了基礎(chǔ)。進一步測試結(jié)果表明，平臺對大文件的傳輸效率還有很大的提升空間，是下一步研究的重點問題。