在Hadoop集群下的智能電網數據云倉庫設計

鄭柏恒，孟 文，易 東，梁曉波

（1.西南交通大學 機械工程學院，成都 610031；2.西南交通大學 電氣工程學院，成都 610031）

0 引言

智能電網是電網的智能化，通過將信息技術、通信技術、計算機技術與原有的電網高度緊密地集合到一起的新型電網，實現電網的可靠、安全、經濟、高效、環境友好和使用安全的目標。但是隨著電網智能化的不斷提高，其數據量也隨之以指數級的增長。面對這海量數據的存儲的難題，國內已有電力調度系統的建設大多采用常規的解決方案，即采用昂貴的大型服務器為基礎，通過傳統的關系數據庫的方式管理，并且以數據庫分片的方式存放到磁盤陣列中的形式[1]。這導致系統的擴展升級較為困難，費用十分高昂，且整個系統模塊間耦合性較強，難以滿足電網智能化所要求的高效、可靠、經濟的目標[2]。

云存儲能夠解決智能電網對海量數據的存儲的難題，最大限度地整合系統的存儲能力，減少電網智能化的成本，大幅提高當前系統的整體性能，對智能電網的發展起到巨大的推動作用。云計算雖然在智能電網方面未見成型的系統[3,4]，但已經在其他領域得到了大量的應用[7,8]，而且智能電網方面的云計算系統也在架構設計開發階段了[9]，但是Hadoop集群在處理電網大數據上具有巨大的優勢[1,12]。

1 Hadoop概述

Hadoop作為一個開源的云計算基礎框架，一個分布式系統基礎架構，可以使用戶充分利用集群的威力高速運算和存儲，具有可靠的數據存儲和處理能力、易于擴展的計算機集群、以高容錯性的多數據副本、以軟件開源及廉價計算機集群帶來的低成本等優勢，正成為信息領域研究的熱點。

HBase (Hadoop Database)，是一個在HDFS系統基礎上的高可靠性、高性能、面向列、可伸縮的分布式NoSQL數據庫，是谷歌公司BigTable技術的開源項目[15]，利用HBase技術可在廉價PC服務器集群上搭建起大規模非關系結構化快速讀寫的存儲倉庫。

MapReduce作為并行處理大數據集的軟件框架，在Hadoop上得到了實現[7]。它負責分配工作以及與用戶程序進行通信，通過把對數據集的大規模操作分發給網絡上的每個節點上，實現數據的分布式處理。

2 智能電網數據云存儲系統設計

智能電網環境下電力數據具有：規模大、類型多、價值密度低和變化快的特點[5]，按照數據的產生源大致分為三類：一是電網運行和設備檢測或監測數據；二是電力企業營銷數據，如交易電價、售電量、用電客戶等方面的數據；三是電力企業管理數據[5]。因此隨著時間的增長，存儲電網數據所需的空間將越來越大，同理在查詢數據時也將更為費時費力。

圖1 云存儲系統結構

針對上述智能電網數據的特點，結合Hbase分布式數據庫稀疏存儲、自動切分數據、提供高并發讀寫操作等特點，構建出智能電網數據云存儲系統。

如圖1所示為云存儲系統的結構圖，整個系統由存儲客戶端、Hadoop服務器集群、查詢客戶端三部分組成。數據源包括智能電網中的發電、變電、輸電、用電、調度、銷售、財政等數據，由各類監控管理設備或終端經由以太網等網絡傳輸，并經由存儲客戶端存儲到集群當中。系統核心是以大量廉價的PC機為基礎，通過Hadoop分布式框架搭建的服務器集群，由少量的NameNode（負責維護文件系統命名空間）和大量的DataNode（負責存儲數據塊）組成。圖1左邊是存儲客戶端，負責將上傳的數據映射成Hbase數據庫Htable表項，并且存儲到Hbase數據庫中；右邊為查詢服務器，負責處理海量數據的查詢，為數據分析應用提供海量數據基礎。

2.1 集群搭建及Hbase表設計

通過虛擬化技術，在安裝Windows 7操作系統的PC機上，安裝VMware Workstation 10，虛擬Linux環境，形成一個處于10.10.11.0段的局域網絡。在各機上安裝JDK、SSH、Hadoop-0.20.2以及Hbase-0.90.5，完成搭建一個完全分布模式下的Hadoop集群，最后再在各機上安裝Zookeeper-3.3.4來管理Hadoop集群。

創建Hbase表時需要確定表的結構和表的屬性。表的結構有三種基本類型包括：行關鍵字（RowKey）、時間戳（Time Stamp）和列族（ColumnFamily）。其中行關鍵字由用戶ID（類型為32位二進制）、數據存入時間（Datatime類型）、數據類型（String類型）、數據行ID（類型64位二進制）四個部分組成的字節數組，由RowKey生產器生成。時間戳根據輸入數據的時間戳而定，若數據為靜態數據本身無時間戳則由存入數據庫時間為時間戳的值。列族，利用其稀疏和動態創建列的特性，根據輸入文件描述的對象動態創建列并且把數據存到對應列中。而表的屬性主要用到的有：數據行最大版本數，Hbase通過保留舊版本以預防誤操作，在這由于數據被修改的可能性較小故設為3；壓縮算法，使用snappy算法，其壓縮效率與lzo相近但解壓效率遠高于Izo，使數據查詢速度加快。

2.2 存儲客戶端設計

實驗以調度系統向云存儲系統進行數據上傳為例，將一臺PC機作為調度系統數據發生端，將滿足國標DLT890[12]標準(轉化自IEC系列標準)[6,11]的數據上傳到集群。其中數據包含了地理（GIS）信息、電力設備和線路信息、財政信息、負載信息、量測信息、電力保護信息、設備儲備與損耗信息、預測及計劃信息等[14]，這些信息數據以通用信息模型及其拓展模型為模板形成，并且通過RDF（Resource Description Framework）網絡資源描述語言[10]的方式描述，如圖2所示。

圖2 智能電網CIM/RDF數據

在實驗里，存儲客戶端根據用戶信息和相關配置信息創建配置信息并且初始化RowKey工廠以及創建數據行上傳緩沖區HTablePool，然后將上傳文件中的數據映射為數據行存放到上傳緩沖區中，當緩沖區存放的數據行達到一定的行數再提交實行稀疏的磁盤存儲，如表1所示，且數據項中可以含有空的列項，并且為空的數據項不占用任何存儲空間。由于HTable是有序的且Hbase具有自動切分數據的能力，故只需控制存儲數據行的RowKey不連續遞增，就能把數據行均勻的存到集群機器上，保持機器負載的均衡，避免了新數據扎堆存儲到相同的機器上降低整個存儲系統的I/O性能的現象。

上述數據上傳的詳細過程如圖3所示，其中上傳緩沖區通過HTablePool類對上傳的數據行進行緩沖和管理，除此之外通過建立上傳文件流隊列實現用戶的多文件上傳操作。

2.3 查詢客戶端設計

Hbase輕量化地集成了Hadoop中的MapReduce并行運算模型[9]，并且根據自身的特點突出優化了其表查詢的效率以及提出了基于MapReduce的表查詢函數。因此用戶在查詢時主要設計的是TableInputFormat、TableMapper、TableReducer、TableOutputFormat四個函數[8]，其整體查詢過程如圖4所示。

1)TableInputFormat函數，負責將數據以表的形式通過表分割成為Splits，然后提交給Map函數。

2)TableMapper函數，負責處理TableInputFormat函數提交的Splits，配置RowKey值的范圍、該數據項的版本、過濾器等設置，確定數據查找的條件并創建掃描讀入對象Scan，最后將查詢到的數據交給TableReducer函數。

3)TableReducer函數，負責對查詢到的數據進行分析處理。實驗中由于無特殊應用需求，只對查詢數據進行了排序，提交到TableOutputFormat函數。

4)TableReducer個數配置，通過配置TableReducer個數能夠調節Hadoop集群的負載以及該MapReduce任務的處理速度，TableReducer個數在很大程度上影響整個MapReduce任務的效率。

5)TableOutputFormat函數，除了負載匯總TableReducer函數處理完的數據以外，還提供了底層刷新的機制，大大地增加了大量數據在相界面呈現時的速度。

表1 Hbase數據行

圖3 存儲過程

圖4 查詢過程

3 實驗與結果分析

3.1 實驗平臺環境

本文的所有實驗均在實驗室搭建的Hadoop平臺上運行。平臺有9個節點組成，均為廉價PC機，每個節點的物理配置為雙核CPU，主頻為2.0MHz，內存為2G，網絡帶寬100Mbps局域網，硬盤為100G，Hadoop版本為0.20.205，Hbase版本為0.90.5，數據行最大版本數為3。

3.2 數據查詢性能分析

實驗是在集群無其他任務的條件下，使用測試客戶端以不同的配置測試Hbase的I/O性能，以得到Hbase的I/O性能最優時Hbase的配置。其中影響Hbase的I/O性能的主要因素是要在集群上開多少個并行進程來處理查詢和分析處理任務。

1）實驗中只改變MapReduce的并行進程個數（即改變每個InputSplit的大小），保持其他條件不變，創建查詢170萬行數據的任務并獲取任務運行時間，結果如圖5所示。

圖5 MapReduce個數對Hbase性能的影響

2）控制MapReduce的并行進程個數（Map和Reduce任務均為18個）及其他條件不變，只改變查詢數據行的數量，從10萬行到350萬行，并獲取任務運行時間，結果如圖6所示。

圖6 數據處理量對Hbase性能的影響

由上述兩組實驗可以看出，每個MapReduce任務的并行進程個數太少時集群資源沒用充分地利用查詢速度降低；而并行進程個數太多時，雖然數據處理的速度有所增加，但卻浪費了大量的時間在進程創建和節點通訊上，反而得不償失；除此之外如果每個進程處理的數據過多會大量占用節點內存，導致該節點無法處理別的進程，降低了效率。因此根據上述兩個實驗得出在集群用18個進程且每個進程生命周期為20秒（即處理約170行數據）時得到較好的效率。故對于本集群，MapReduce的并行進程個數應設置為[查詢數據行數/90000]+1。這樣設置雖然犧牲了集群的小部分任務處理速度，但是卻使集群在多任務高負載運行下保證每個任務的處理速度。

3.3 數據讀寫性能比較

實驗是在集群無其它任務運行且MapReduce配置相同的條件下，使用測試客戶端對Hbase進行寫入數據和查詢數據，將同樣的數據放到Oracle系統（四核CPU，8GB內存，硬盤650GB）里查詢并統計時間。

表2 Oracle與Hbase查詢時間對比表

由上表2可以看出，當數據量低于80萬行時，單機服務的傳統Oracle數據庫有很大的優勢；但是隨著查詢數據量的增大，集群Hbase數據庫的優勢越來越明顯。但是當在大量數據入庫時，兩種數據庫系統寫入速度都不太理想，不過針對這一問題，Hbase也提供了一種與數據庫文件導入類似的以Hfile（按照Hbase數據格式存儲的文件格式）的方式入庫，其寫入速度與HDFS速度一樣[13]，并且在文件格式轉換時，還能通過MapReduce的方式利用集群的整體性能快速地將數據轉換為Hfile。綜上，該集群非常適合存儲大規模的存儲次數頻繁但每次數據量不多的智能電網大數據，且在電網大數據處理上具有快速、可靠、廉價的優勢。

4 結論

本文研究了基于Hadoop的智能電網數據云存儲系統，首先分析智能電網數據的特點，利用Hbase分布式數據庫的特點，設計并實現了智能電網數據云存儲系統。搭建了具有9個節點的廉價PC機組成的Hadoop集群，然后開發了基于Hbase以及MapReduce的存儲和查詢客戶端，并且對集群進行了大量的實驗，包括MapReduce配置實驗和與HDFS性能比較實驗，表明了本集群適合應用于智能電網大數據的存儲，并且提供了快速處理大數據的能力，在行業電網數據分析中具有快速、有效、可靠、廉價的優勢。

[1]劉樹仁,宋亞奇,朱永利,王德文.基于Hadoop的智能電網狀態監測數據存儲研究[J].計算機科學,2013,40(1):81-84.

[2]張懷宇,朱松林,張揚,樓其民,張亮.輸變電設備狀態檢修技術體系研究與實施[J].電網技術,2009,33(13):46-48.

[3]王德文,宋亞奇,朱永利.基于云計算的智能電網信息平臺[J].電力系統自動化,2010,34(22):7-12.

[4]呂躍剛,關曉慧,劉俊承.風力發電機組狀態監測系統研究[J].自動化與儀表,2012,27(1):6-10.

[5]宋亞奇,周國亮,朱永利.智能電網大數據處理技術現狀與挑戰[J].電網技術,2013,37(4):927-935.

[6]曹陽,姚建國,楊勝春,姜海,高志遠.智能電網核心標準IEC61970最新進展[J].電力系統自動化,2011,35(17):1-4.

[7]李偉衛,李梅,張陽,申愛麗.基于分布式數據倉庫的分類分析研究[J].計算機應用研究,2013,30(10):2936-2939.

[8]徐恩虎,凌衛青,王堅,馬云龍.基于云計算的面向智能交通海量信息的高性能計算支撐公共服務框架[J].機電產品開發與創新,2013,26(1):87-89.

[9]劉萌,褚曉東,張文,馮宗英.負荷分布式控制的云計算平臺構架設計[J].電網技術,2012,36(8):140-144.

[10]Tom White.Hadoop權威指南[M].清華大學出版社,2011,7.

[11]Lars George.Hbase The Definitive Guide(影印版)[M].東南大學出版社,2011.8.

[12]陳勇.基于Hadoop平臺的通訊數據分布式查詢算法的設計與實現[D].北京:北京交通大學,2009.

[13]IEC 61970-501-2008 Energy Management System Application Program Interface(EMS-API)Part 501：CIM RDF Schema[S].2008.

[14]IEC61970-301 Ed.2:2010 Energy Management System Application Program Interface(EMS-API)Part 301:Common Information Modle(CIM) base[S].2010.

[15]Fay Chang,Jeffrey Dean,Sanjay Ghemaway,Wilson C Hsieh,Deborah A Wallach,Mike Burrows,Tushar Chandra,Andrew Fikes,Robert E Gruber.Bigtable:A Distributed Storage System for Structured Data[R].Google Incorporated,2006,10.