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

（1.西南交通大學(xué) 機(jī)械工程學(xué)院，成都 610031；2.西南交通大學(xué) 電氣工程學(xué)院，成都 610031）

0 引言

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

云存儲(chǔ)能夠解決智能電網(wǎng)對(duì)海量數(shù)據(jù)的存儲(chǔ)的難題，最大限度地整合系統(tǒng)的存儲(chǔ)能力，減少電網(wǎng)智能化的成本，大幅提高當(dāng)前系統(tǒng)的整體性能，對(duì)智能電網(wǎng)的發(fā)展起到巨大的推動(dòng)作用。云計(jì)算雖然在智能電網(wǎng)方面未見(jiàn)成型的系統(tǒng)[3,4]，但已經(jīng)在其他領(lǐng)域得到了大量的應(yīng)用[7,8]，而且智能電網(wǎng)方面的云計(jì)算系統(tǒng)也在架構(gòu)設(shè)計(jì)開(kāi)發(fā)階段了[9]，但是Hadoop集群在處理電網(wǎng)大數(shù)據(jù)上具有巨大的優(yōu)勢(shì)[1,12]。

1 Hadoop概述

Hadoop作為一個(gè)開(kāi)源的云計(jì)算基礎(chǔ)框架，一個(gè)分布式系統(tǒng)基礎(chǔ)架構(gòu)，可以使用戶充分利用集群的威力高速運(yùn)算和存儲(chǔ)，具有可靠的數(shù)據(jù)存儲(chǔ)和處理能力、易于擴(kuò)展的計(jì)算機(jī)集群、以高容錯(cuò)性的多數(shù)據(jù)副本、以軟件開(kāi)源及廉價(jià)計(jì)算機(jī)集群帶來(lái)的低成本等優(yōu)勢(shì)，正成為信息領(lǐng)域研究的熱點(diǎn)。

HBase (Hadoop Database)，是一個(gè)在HDFS系統(tǒng)基礎(chǔ)上的高可靠性、高性能、面向列、可伸縮的分布式NoSQL數(shù)據(jù)庫(kù)，是谷歌公司BigTable技術(shù)的開(kāi)源項(xiàng)目[15]，利用HBase技術(shù)可在廉價(jià)PC服務(wù)器集群上搭建起大規(guī)模非關(guān)系結(jié)構(gòu)化快速讀寫(xiě)的存儲(chǔ)倉(cāng)庫(kù)。

MapReduce作為并行處理大數(shù)據(jù)集的軟件框架，在Hadoop上得到了實(shí)現(xiàn)[7]。它負(fù)責(zé)分配工作以及與用戶程序進(jìn)行通信，通過(guò)把對(duì)數(shù)據(jù)集的大規(guī)模操作分發(fā)給網(wǎng)絡(luò)上的每個(gè)節(jié)點(diǎn)上，實(shí)現(xiàn)數(shù)據(jù)的分布式處理。

2 智能電網(wǎng)數(shù)據(jù)云存儲(chǔ)系統(tǒng)設(shè)計(jì)

智能電網(wǎng)環(huán)境下電力數(shù)據(jù)具有：規(guī)模大、類型多、價(jià)值密度低和變化快的特點(diǎn)[5]，按照數(shù)據(jù)的產(chǎn)生源大致分為三類：一是電網(wǎng)運(yùn)行和設(shè)備檢測(cè)或監(jiān)測(cè)數(shù)據(jù)；二是電力企業(yè)營(yíng)銷數(shù)據(jù)，如交易電價(jià)、售電量、用電客戶等方面的數(shù)據(jù)；三是電力企業(yè)管理數(shù)據(jù)[5]。因此隨著時(shí)間的增長(zhǎng)，存儲(chǔ)電網(wǎng)數(shù)據(jù)所需的空間將越來(lái)越大，同理在查詢數(shù)據(jù)時(shí)也將更為費(fèi)時(shí)費(fèi)力。

圖1 云存儲(chǔ)系統(tǒng)結(jié)構(gòu)

針對(duì)上述智能電網(wǎng)數(shù)據(jù)的特點(diǎn)，結(jié)合Hbase分布式數(shù)據(jù)庫(kù)稀疏存儲(chǔ)、自動(dòng)切分?jǐn)?shù)據(jù)、提供高并發(fā)讀寫(xiě)操作等特點(diǎn)，構(gòu)建出智能電網(wǎng)數(shù)據(jù)云存儲(chǔ)系統(tǒng)。

如圖1所示為云存儲(chǔ)系統(tǒng)的結(jié)構(gòu)圖，整個(gè)系統(tǒng)由存儲(chǔ)客戶端、Hadoop服務(wù)器集群、查詢客戶端三部分組成。數(shù)據(jù)源包括智能電網(wǎng)中的發(fā)電、變電、輸電、用電、調(diào)度、銷售、財(cái)政等數(shù)據(jù)，由各類監(jiān)控管理設(shè)備或終端經(jīng)由以太網(wǎng)等網(wǎng)絡(luò)傳輸，并經(jīng)由存儲(chǔ)客戶端存儲(chǔ)到集群當(dāng)中。系統(tǒng)核心是以大量廉價(jià)的PC機(jī)為基礎(chǔ)，通過(guò)Hadoop分布式框架搭建的服務(wù)器集群，由少量的NameNode（負(fù)責(zé)維護(hù)文件系統(tǒng)命名空間）和大量的DataNode（負(fù)責(zé)存儲(chǔ)數(shù)據(jù)塊）組成。圖1左邊是存儲(chǔ)客戶端，負(fù)責(zé)將上傳的數(shù)據(jù)映射成Hbase數(shù)據(jù)庫(kù)Htable表項(xiàng)，并且存儲(chǔ)到Hbase數(shù)據(jù)庫(kù)中；右邊為查詢服務(wù)器，負(fù)責(zé)處理海量數(shù)據(jù)的查詢，為數(shù)據(jù)分析應(yīng)用提供海量數(shù)據(jù)基礎(chǔ)。

2.1 集群搭建及Hbase表設(shè)計(jì)

通過(guò)虛擬化技術(shù)，在安裝Windows 7操作系統(tǒng)的PC機(jī)上，安裝VMware Workstation 10，虛擬Linux環(huán)境，形成一個(gè)處于10.10.11.0段的局域網(wǎng)絡(luò)。在各機(jī)上安裝JDK、SSH、Hadoop-0.20.2以及Hbase-0.90.5，完成搭建一個(gè)完全分布模式下的Hadoop集群，最后再在各機(jī)上安裝Zookeeper-3.3.4來(lái)管理Hadoop集群。

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

2.2 存儲(chǔ)客戶端設(shè)計(jì)

實(shí)驗(yàn)以調(diào)度系統(tǒng)向云存儲(chǔ)系統(tǒng)進(jìn)行數(shù)據(jù)上傳為例，將一臺(tái)PC機(jī)作為調(diào)度系統(tǒng)數(shù)據(jù)發(fā)生端，將滿足國(guó)標(biāo)DLT890[12]標(biāo)準(zhǔn)(轉(zhuǎn)化自IEC系列標(biāo)準(zhǔn))[6,11]的數(shù)據(jù)上傳到集群。其中數(shù)據(jù)包含了地理（GIS）信息、電力設(shè)備和線路信息、財(cái)政信息、負(fù)載信息、量測(cè)信息、電力保護(hù)信息、設(shè)備儲(chǔ)備與損耗信息、預(yù)測(cè)及計(jì)劃信息等[14]，這些信息數(shù)據(jù)以通用信息模型及其拓展模型為模板形成，并且通過(guò)RDF（Resource Description Framework）網(wǎng)絡(luò)資源描述語(yǔ)言[10]的方式描述，如圖2所示。

圖2 智能電網(wǎng)CIM/RDF數(shù)據(jù)

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

上述數(shù)據(jù)上傳的詳細(xì)過(guò)程如圖3所示，其中上傳緩沖區(qū)通過(guò)HTablePool類對(duì)上傳的數(shù)據(jù)行進(jìn)行緩沖和管理，除此之外通過(guò)建立上傳文件流隊(duì)列實(shí)現(xiàn)用戶的多文件上傳操作。

2.3 查詢客戶端設(shè)計(jì)

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

1)TableInputFormat函數(shù)，負(fù)責(zé)將數(shù)據(jù)以表的形式通過(guò)表分割成為Splits，然后提交給Map函數(shù)。

2)TableMapper函數(shù)，負(fù)責(zé)處理TableInputFormat函數(shù)提交的Splits，配置RowKey值的范圍、該數(shù)據(jù)項(xiàng)的版本、過(guò)濾器等設(shè)置，確定數(shù)據(jù)查找的條件并創(chuàng)建掃描讀入對(duì)象Scan，最后將查詢到的數(shù)據(jù)交給TableReducer函數(shù)。

3)TableReducer函數(shù)，負(fù)責(zé)對(duì)查詢到的數(shù)據(jù)進(jìn)行分析處理。實(shí)驗(yàn)中由于無(wú)特殊應(yīng)用需求，只對(duì)查詢數(shù)據(jù)進(jìn)行了排序，提交到TableOutputFormat函數(shù)。

4)TableReducer個(gè)數(shù)配置，通過(guò)配置TableReducer個(gè)數(shù)能夠調(diào)節(jié)Hadoop集群的負(fù)載以及該MapReduce任務(wù)的處理速度，TableReducer個(gè)數(shù)在很大程度上影響整個(gè)MapReduce任務(wù)的效率。

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

表1 Hbase數(shù)據(jù)行

圖3 存儲(chǔ)過(guò)程

圖4 查詢過(guò)程

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

3.1 實(shí)驗(yàn)平臺(tái)環(huán)境

本文的所有實(shí)驗(yàn)均在實(shí)驗(yàn)室搭建的Hadoop平臺(tái)上運(yùn)行。平臺(tái)有9個(gè)節(jié)點(diǎn)組成，均為廉價(jià)PC機(jī)，每個(gè)節(jié)點(diǎn)的物理配置為雙核CPU，主頻為2.0MHz，內(nèi)存為2G，網(wǎng)絡(luò)帶寬100Mbps局域網(wǎng)，硬盤為100G，Hadoop版本為0.20.205，Hbase版本為0.90.5，數(shù)據(jù)行最大版本數(shù)為3。

3.2 數(shù)據(jù)查詢性能分析

實(shí)驗(yàn)是在集群無(wú)其他任務(wù)的條件下，使用測(cè)試客戶端以不同的配置測(cè)試Hbase的I/O性能，以得到Hbase的I/O性能最優(yōu)時(shí)Hbase的配置。其中影響Hbase的I/O性能的主要因素是要在集群上開(kāi)多少個(gè)并行進(jìn)程來(lái)處理查詢和分析處理任務(wù)。

1）實(shí)驗(yàn)中只改變MapReduce的并行進(jìn)程個(gè)數(shù)（即改變每個(gè)InputSplit的大?。３制渌麠l件不變，創(chuàng)建查詢170萬(wàn)行數(shù)據(jù)的任務(wù)并獲取任務(wù)運(yùn)行時(shí)間，結(jié)果如圖5所示。

圖5 MapReduce個(gè)數(shù)對(duì)Hbase性能的影響

2）控制MapReduce的并行進(jìn)程個(gè)數(shù)（Map和Reduce任務(wù)均為18個(gè)）及其他條件不變，只改變查詢數(shù)據(jù)行的數(shù)量，從10萬(wàn)行到350萬(wàn)行，并獲取任務(wù)運(yùn)行時(shí)間，結(jié)果如圖6所示。

圖6 數(shù)據(jù)處理量對(duì)Hbase性能的影響

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

3.3 數(shù)據(jù)讀寫(xiě)性能比較

實(shí)驗(yàn)是在集群無(wú)其它任務(wù)運(yùn)行且MapReduce配置相同的條件下，使用測(cè)試客戶端對(duì)Hbase進(jìn)行寫(xiě)入數(shù)據(jù)和查詢數(shù)據(jù)，將同樣的數(shù)據(jù)放到Oracle系統(tǒng)（四核CPU，8GB內(nèi)存，硬盤650GB）里查詢并統(tǒng)計(jì)時(shí)間。

表2 Oracle與Hbase查詢時(shí)間對(duì)比表

由上表2可以看出，當(dāng)數(shù)據(jù)量低于80萬(wàn)行時(shí)，單機(jī)服務(wù)的傳統(tǒng)Oracle數(shù)據(jù)庫(kù)有很大的優(yōu)勢(shì)；但是隨著查詢數(shù)據(jù)量的增大，集群Hbase數(shù)據(jù)庫(kù)的優(yōu)勢(shì)越來(lái)越明顯。但是當(dāng)在大量數(shù)據(jù)入庫(kù)時(shí)，兩種數(shù)據(jù)庫(kù)系統(tǒng)寫(xiě)入速度都不太理想，不過(guò)針對(duì)這一問(wèn)題，Hbase也提供了一種與數(shù)據(jù)庫(kù)文件導(dǎo)入類似的以Hfile（按照Hbase數(shù)據(jù)格式存儲(chǔ)的文件格式）的方式入庫(kù)，其寫(xiě)入速度與HDFS速度一樣[13]，并且在文件格式轉(zhuǎn)換時(shí)，還能通過(guò)MapReduce的方式利用集群的整體性能快速地將數(shù)據(jù)轉(zhuǎn)換為Hfile。綜上，該集群非常適合存儲(chǔ)大規(guī)模的存儲(chǔ)次數(shù)頻繁但每次數(shù)據(jù)量不多的智能電網(wǎng)大數(shù)據(jù)，且在電網(wǎng)大數(shù)據(jù)處理上具有快速、可靠、廉價(jià)的優(yōu)勢(shì)。

4 結(jié)論

本文研究了基于Hadoop的智能電網(wǎng)數(shù)據(jù)云存儲(chǔ)系統(tǒng)，首先分析智能電網(wǎng)數(shù)據(jù)的特點(diǎn)，利用Hbase分布式數(shù)據(jù)庫(kù)的特點(diǎn)，設(shè)計(jì)并實(shí)現(xiàn)了智能電網(wǎng)數(shù)據(jù)云存儲(chǔ)系統(tǒng)。搭建了具有9個(gè)節(jié)點(diǎn)的廉價(jià)PC機(jī)組成的Hadoop集群，然后開(kāi)發(fā)了基于Hbase以及MapReduce的存儲(chǔ)和查詢客戶端，并且對(duì)集群進(jìn)行了大量的實(shí)驗(yàn)，包括MapReduce配置實(shí)驗(yàn)和與HDFS性能比較實(shí)驗(yàn)，表明了本集群適合應(yīng)用于智能電網(wǎng)大數(shù)據(jù)的存儲(chǔ)，并且提供了快速處理大數(shù)據(jù)的能力，在行業(yè)電網(wǎng)數(shù)據(jù)分析中具有快速、有效、可靠、廉價(jià)的優(yōu)勢(shì)。

[1]劉樹(shù)仁,宋亞奇,朱永利,王德文.基于Hadoop的智能電網(wǎng)狀態(tài)監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)研究[J].計(jì)算機(jī)科學(xué),2013,40(1):81-84.

[2]張懷宇,朱松林,張揚(yáng),樓其民,張亮.輸變電設(shè)備狀態(tài)檢修技術(shù)體系研究與實(shí)施[J].電網(wǎng)技術(shù),2009,33(13):46-48.

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

[4]呂躍剛,關(guān)曉慧,劉俊承.風(fēng)力發(fā)電機(jī)組狀態(tài)監(jiān)測(cè)系統(tǒng)研究[J].自動(dòng)化與儀表,2012,27(1):6-10.

[5]宋亞奇,周國(guó)亮,朱永利.智能電網(wǎng)大數(shù)據(jù)處理技術(shù)現(xiàn)狀與挑戰(zhàn)[J].電網(wǎng)技術(shù),2013,37(4):927-935.

[6]曹陽(yáng),姚建國(guó),楊勝春,姜海,高志遠(yuǎn).智能電網(wǎng)核心標(biāo)準(zhǔn)IEC61970最新進(jìn)展[J].電力系統(tǒng)自動(dòng)化,2011,35(17):1-4.

[7]李偉衛(wèi),李梅,張陽(yáng),申愛(ài)麗.基于分布式數(shù)據(jù)倉(cāng)庫(kù)的分類分析研究[J].計(jì)算機(jī)應(yīng)用研究,2013,30(10):2936-2939.

[8]徐恩虎,凌衛(wèi)青,王堅(jiān),馬云龍.基于云計(jì)算的面向智能交通海量信息的高性能計(jì)算支撐公共服務(wù)框架[J].機(jī)電產(chǎn)品開(kāi)發(fā)與創(chuàng)新,2013,26(1):87-89.

[9]劉萌,褚曉東,張文,馮宗英.負(fù)荷分布式控制的云計(jì)算平臺(tái)構(gòu)架設(shè)計(jì)[J].電網(wǎng)技術(shù),2012,36(8):140-144.

[10]Tom White.Hadoop權(quán)威指南[M].清華大學(xué)出版社,2011,7.

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

[12]陳勇.基于Hadoop平臺(tái)的通訊數(shù)據(jù)分布式查詢算法的設(shè)計(jì)與實(shí)現(xiàn)[D].北京:北京交通大學(xué),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.