李 佳，徐勝超

(1.江蘇食品藥品職業(yè)技術(shù)學(xué)院 信息工程學(xué)院，江蘇 淮安 223003；2.欽州學(xué)院 電子與信息工程學(xué)院，廣西 欽州 535011)

0 引 言

保證智能電網(wǎng)正常運行的數(shù)據(jù)包括電壓、用戶負(fù)荷、電量等信息，早期的處理技術(shù)有MPI集群計算、Globus網(wǎng)格計算等[1,2]，這些技術(shù)在十幾年前都可以滿足電網(wǎng)公司的應(yīng)用需求[3-5]。然而，這幾年隨著電網(wǎng)數(shù)據(jù)，軟件容量的增大，早期的技術(shù)已經(jīng)不能滿足電網(wǎng)公司的需求。隨著云計算和大數(shù)據(jù)處理等技術(shù)的出現(xiàn)與發(fā)展，它們被應(yīng)用到智能電網(wǎng)狀態(tài)安全與檢測等領(lǐng)域[6-8]。

云計算是軟件即服務(wù)(SaaS)、平臺即服務(wù)(PaaS)、基礎(chǔ)設(shè)施即服務(wù)(IaaS)、虛擬化Virtualization等技術(shù)的躍進或者商業(yè)實現(xiàn)的結(jié)果[9]，而且云計算的某些商業(yè)實現(xiàn)部分開放源代碼的，所以我們可以采用更加先進、速度更加快的云平臺來處理智能電網(wǎng)大數(shù)據(jù)[10]。

云計算是近年來各大IT公司比較熱門的研究內(nèi)容，因為它提供給客戶端的是一種有償?shù)纳虡I(yè)服務(wù)，企業(yè)有利可圖，這些云平臺的源代碼版權(quán)屬于各大IT公司，并不對外完全公布，只有少量的開放源代碼。通過比較得知云計算的MapReduce規(guī)范[11]最早被Google公司用于大規(guī)模數(shù)據(jù)集的并行處理。這一方法構(gòu)造成本低，搭建容易，而且軟件比較先進，因此近年來在大數(shù)據(jù)處理領(lǐng)域得到了廣泛應(yīng)用。

通過上面的分析，本文提出一個基于云計算的智能電網(wǎng)大數(shù)據(jù)處理平臺SP-DPP(smart power system big data processing platform in cloud environment)，結(jié)合智能電網(wǎng)大數(shù)據(jù)的狀態(tài)安全分析的特點，詳細(xì)描述了該平臺的設(shè)計思想與實現(xiàn)過程，然后利用云計算Apache的Hadoop中的MapReduce規(guī)范開源代碼實現(xiàn)了該平臺，最后的案例程序與測試結(jié)果驗證了智能電網(wǎng)大數(shù)據(jù)處理平臺SP-DPP的正確性與高性能。

1 智能電網(wǎng)大數(shù)據(jù)處理的數(shù)學(xué)模型

1.1 大數(shù)據(jù)處理的數(shù)學(xué)模型

判斷一個智能電網(wǎng)的狀態(tài)，最常用的數(shù)據(jù)模型是潮流計算[12,13]。經(jīng)典的潮流方程的極坐標(biāo)形式為

(1)

(2)

其中，Pi，Qi，Ui，Uj，Gij，Bij，θij分別是智能電網(wǎng)的參數(shù)，對電網(wǎng)的狀態(tài)進行判斷，往往是設(shè)置P，Q，U，θ這4個參數(shù)中的任何兩個，然后通過方程組的約束條件，求解出其它的另外兩個參數(shù)。如果方程組中的n很大，那么智能電網(wǎng)的規(guī)模也很大，近年來各個電網(wǎng)公司的調(diào)度中心經(jīng)常需要判斷電網(wǎng)的運行情況，如果規(guī)模很大，該方程組的計算量將十分巨大，如果能夠在規(guī)定的時間內(nèi)求出潮流計算的結(jié)果，是具有很大的現(xiàn)實意義[14]。本文的智能電網(wǎng)大數(shù)據(jù)處理就是基于上述數(shù)學(xué)模型。

1.2 智能電網(wǎng)大數(shù)據(jù)的劃分

我們可以考慮主-從模式的編程模型的思路進行智能大數(shù)據(jù)的任務(wù)劃分。如果每次設(shè)置不同的電網(wǎng)異常狀態(tài)的預(yù)想事故，把每一個預(yù)想事故都劃分為一個子任務(wù)形式，這個子任務(wù)類似于MapReduce中的Mapper，Mapper子程序代碼通過串行潮流計算就可以得到不同一組電網(wǎng)運行狀態(tài)。不是每個預(yù)想事故都可以導(dǎo)致智能電網(wǎng)出現(xiàn)異常，所以還需要進行匯總判斷。Reducer這種匯總歸約功能正好完成狀態(tài)的判斷匯總。

如圖1所示為面向MapReduce的智能電網(wǎng)大數(shù)據(jù)處理的劃分模型。每個Map分別解方程組約束中的潮流子結(jié)果，得到一個特定的電網(wǎng)運行狀態(tài)，每個Reduce對應(yīng)于潮流計算的判斷各個參數(shù)指標(biāo)是否越界或者異常，最后由一個主程序控制整個應(yīng)用程序的運行流程即可完成整個智能電網(wǎng)的運行狀態(tài)異常檢測。

圖1 智能電網(wǎng)大數(shù)據(jù)的任務(wù)劃分

2 SP-DPP平臺的設(shè)計

2.1 平臺的總體設(shè)計思路

我們設(shè)計SP-DPP云平臺主要基于下面3點考慮：①SP-DPP云平臺與之前老舊的計算平臺不同之處在于它是把互聯(lián)網(wǎng)上的IT相關(guān)的能力以服務(wù)的方式供用戶使用，用戶是通過注冊服務(wù)，訪問服務(wù)的形式來使用云平臺；②SP-DPP云平臺中具有存儲智能電網(wǎng)大數(shù)據(jù)的穩(wěn)定可靠的中心節(jié)點，主要以集群服務(wù)器組成；③SP-DPP平臺在提交和分配大數(shù)據(jù)處理任務(wù)的時候，是把任務(wù)往大數(shù)據(jù)中心節(jié)點上調(diào)度，這點與傳統(tǒng)的網(wǎng)格不一樣，網(wǎng)格平臺中往往是把應(yīng)用相關(guān)的數(shù)據(jù)(參數(shù)文件、配置文件、代碼文件)往工作機節(jié)點上調(diào)度[15]；按照這3個原則與思路，我們設(shè)計的SP-DPP云平臺中網(wǎng)絡(luò)體系結(jié)構(gòu)如圖2所示。

智能電網(wǎng)大數(shù)據(jù)處理云平臺SP-DPP邏輯上劃分成4個模塊：大數(shù)據(jù)存儲與管理模塊、任務(wù)分配與調(diào)度模塊、大數(shù)據(jù)執(zhí)行模塊和客戶端模塊。該SP-DPP云平臺的主要功能是滿足智能電網(wǎng)海量數(shù)據(jù)處理的需求，通過計算出潮流計算的結(jié)果，對智能電網(wǎng)的狀態(tài)安全進行分析與監(jiān)控。

2.2 大數(shù)據(jù)存儲與管理模塊

大數(shù)據(jù)的存儲與管理功能是對要處理的大數(shù)據(jù)采用分布式文件系統(tǒng)DFS(distribute file system)進行存儲，同時對文件系統(tǒng)的名空間進行管理。DFS的設(shè)計與選取必須比以前的集群并行文件系統(tǒng)更加先進與方便，這里我們充分利用云計算的虛擬化技術(shù)[16]，DFS自動為系統(tǒng)管理這些TB到PB級的海量數(shù)據(jù)，程序設(shè)計中看到的是一個文件系統(tǒng)而不是很多文件系統(tǒng)，對用戶透明。例如SP-DPP云平臺要獲取/dfs/tmp/file1的數(shù)據(jù)，程序設(shè)計中引用的是一個文件路徑，但是實際的大數(shù)據(jù)存放在很多不同的物理節(jié)點上。

另外對DFS，該模塊還需要對文件系統(tǒng)的命名空間進行管理，這樣大數(shù)據(jù)處理的任務(wù)分配與調(diào)度模塊、工作機模塊就可以訪問到這些數(shù)據(jù)。

圖2 基于云計算的智能電網(wǎng)大數(shù)據(jù)處理平臺SP-DPP

2.3 任務(wù)分配與調(diào)度模塊

對于SP-DPP平臺來說，要完成一個大數(shù)據(jù)的處理，首先是大數(shù)據(jù)存儲，然后就是任務(wù)分配與調(diào)度，最后是大數(shù)據(jù)處理的執(zhí)行。任務(wù)分配與調(diào)度是最關(guān)鍵的模塊。任務(wù)分配與調(diào)度模塊主要功能是對平臺的大數(shù)據(jù)處理的大任務(wù)進行劃分，然后調(diào)度這些子任務(wù)到空閑工作機上執(zhí)行。雖然其功能比較單一，但是其考慮的問題是很多的。

首先是任務(wù)劃分的問題。并不是所有的大數(shù)據(jù)處理類應(yīng)用都可以在SP-DPP平臺上運行，要根據(jù)應(yīng)用的特點進行劃分。由于智能電網(wǎng)的潮流計算的大數(shù)據(jù)處理在劃分任務(wù)時，可以把每一個電網(wǎng)預(yù)想異常情況的初始參數(shù)設(shè)計為一個子任務(wù)，并作為最基本的工作單元進行處理，任務(wù)調(diào)度模塊的功能就是要高效地調(diào)度這些工作單元到工作機上執(zhí)行。

其次是調(diào)度策略問題，調(diào)度策略的設(shè)計需要綜合考慮工作機的硬件配置情況與軟件信息。硬件配置情況包括CPU的主頻、內(nèi)存大小、空余磁盤空間等。軟件信息包括CPU的利用率高低、網(wǎng)絡(luò)帶寬情況、負(fù)載大小情況、可靠性情況。最終目標(biāo)是使工作單元在各個物理節(jié)點之間的遷移方法更加靈活，目前IBM公司的“藍(lán)云計劃”中的虛擬機軟件就做到了這點[17]。

然后就是容錯的問題。這里SP-DPP平臺使用冗余的方式和分布式存儲來處理，這是云計算的特點。容錯策略還必須自動檢測到失效節(jié)點，將失效節(jié)點排除，不影響SP-DPP平臺的主控任務(wù)的正常運行。

最后是負(fù)載均衡問題，即將多個負(fù)載不是很重的虛擬機計算節(jié)點合并到同一個物理節(jié)點上，提高各個真實的物理節(jié)點的硬件資源的利用率。

另外任務(wù)分配與調(diào)度模塊設(shè)計中還必須根據(jù)當(dāng)前文件系統(tǒng)中文件所在的位置和大小決定如何創(chuàng)建其它的工作機，并對工作機大數(shù)據(jù)處理的執(zhí)行狀態(tài)進行監(jiān)控。

2.4 大數(shù)據(jù)處理執(zhí)行模塊

由于SP-DPP云平臺使用虛擬化技術(shù)，虛擬化技術(shù)包括桌面虛擬化、系統(tǒng)虛擬化等，桌面虛擬化是用戶使用云資源的重要方式。SP-DPP云平臺中的智能電網(wǎng)大數(shù)據(jù)處理的都是在虛擬機上運行的，執(zhí)行模塊的主要功能就是負(fù)責(zé)接收調(diào)度模塊分發(fā)的工作單元，采用虛擬機的方式執(zhí)行，并將執(zhí)行狀態(tài)和臨時結(jié)果向上傳遞給調(diào)度模塊中的主控程序。執(zhí)行模塊中子任務(wù)的數(shù)據(jù)是從大數(shù)據(jù)存儲與管理模塊中獲取的，其執(zhí)行完后，結(jié)果繼續(xù)存儲在大數(shù)據(jù)服務(wù)器中。

2.5 客戶端模塊

客戶端是互聯(lián)網(wǎng)上的用戶訪問SP-DPP云平臺的方式，SP-DPP云平臺可供客戶端訪問?？蛻舳丝梢园凑辗?wù)等級協(xié)議(service level agreements，SLA)，采用按時付費(pay-per-use，PPU)的模式來管理。

3 SP-DPP平臺的實現(xiàn)

3.1 編程模型的實現(xiàn)

對于一個并行大數(shù)據(jù)處理問題，其編程模型主要有主-從模式(Master-Slave)、映射歸約模式(MapReduce)、分治模式(Divide-Conquer)等，這類編程模型中都有類似工作單元(Work Unit)的獨立子任務(wù)執(zhí)行功能，隨著云平臺中數(shù)據(jù)存儲技術(shù)、數(shù)據(jù)管理技術(shù)的發(fā)展，云平臺處理的大數(shù)據(jù)之間還存在依賴關(guān)系，現(xiàn)有的先進軟件都允許子任務(wù)節(jié)點之間進行交互，這樣使得云平臺可以處理的應(yīng)用類型大大增加。

在實現(xiàn)的SP-DPP智能電網(wǎng)云平臺時，我們利用了Apache的開源的云計算平臺Hadoop中的MapReduce規(guī)范。值得說明的MapReduce只是云計算的編程模型的一種，微軟公司提出的DryaLINQ是另外一種并行編程模型，DryaLINQ局限于.NET的LINQ(language integrated query)系統(tǒng)同時并不開源，從而限制了它的發(fā)展前景。Google公司的MapReduce軟件更加先進與成熟，但是其代碼不對外界公布。

MapReduce編程規(guī)范[18]是分布式大數(shù)據(jù)存儲、任務(wù)調(diào)度、任務(wù)執(zhí)行、容錯、負(fù)載均衡的整合體，在SP-DPP平臺中，應(yīng)用程序編寫人員只需將精力放在Mapper和Reducer程序的編寫上即可完成智能電網(wǎng)大數(shù)據(jù)狀態(tài)安全的分析。

3.2 各個模塊的實現(xiàn)

首先是大數(shù)據(jù)的存儲與管理的實現(xiàn)，其實Google公司和IBM公司都有云計算的內(nèi)部大數(shù)據(jù)的存儲與管理的實現(xiàn)項目，例如Google File Sysyem項目、BigTable項目，IBM公司的基于塊設(shè)備的存儲區(qū)域網(wǎng)絡(luò)SAN等。前面這些都不開放源代碼，這個功能的實現(xiàn)我們選擇了開源的Hadoop的HDFS，SP-DPP平臺中利用HDFS可以部署主控服務(wù)器NameNode、數(shù)據(jù)服務(wù)器DateNode、作業(yè)服務(wù)器JobTracker和任務(wù)服務(wù)器TaskTracker等角色，我們選擇兩個角色DateNode、NameNode即可完成大數(shù)據(jù)的存儲，同時對文件系統(tǒng)的命名空間進行管理。

其次是任務(wù)分配與調(diào)度模塊的實現(xiàn)。根據(jù)我們上一節(jié)描述的原則，我們也選擇了Hadoop的規(guī)范中的JobTracker角色來完成。在任務(wù)分配的時候，首先需要對電網(wǎng)大數(shù)據(jù)的分片進行設(shè)置，預(yù)先放置在HDFS中。各種調(diào)度策略、負(fù)載均衡策略、容錯策略都是Hadoop中原始策略，如果改進這些策略需要對開源代碼進行分析與更改才可以達(dá)到更好的效果。值得指出的是Hadoop的MapReduce規(guī)范里JobTracker是用于調(diào)度和管理它下屬的TaskTracker，TaskTracker負(fù)責(zé)執(zhí)行工作單元(Work Unit)，它運行在DataNode上，即大數(shù)據(jù)存儲的物理節(jié)點上要同時部署TaskTracker和DataNode。

工作機模塊的實現(xiàn)使用了Hadoop的規(guī)范中的TaskTracker角色來完成。相對于JobTracker的主控任務(wù)來說，TaskTracker是從屬任務(wù)，運行在從屬節(jié)點上，主要負(fù)責(zé)接收J(rèn)obTracker分發(fā)的子任務(wù)并執(zhí)行，并將執(zhí)行狀態(tài)和結(jié)果向上傳遞給JobTracker。最后在Hadoop的規(guī)范中還有一個作業(yè)(Job)的提交者，即是客戶端。

我們實現(xiàn)的SP-DPP云平臺中各個功能模塊的邏輯關(guān)系如圖3所示。實線框Master是一個實際的物理節(jié)點，實現(xiàn)的是智能電網(wǎng)大數(shù)據(jù)任務(wù)分配與調(diào)度模塊，實線框Slave也是一個實際的物理節(jié)點，它實現(xiàn)了工作機模塊和大數(shù)據(jù)存儲與管理模塊，虛線框都是虛擬的節(jié)點，Cilent客戶端是用戶與SP-DPP云平臺的交互服務(wù)窗口，是實際的物理節(jié)點。

3.3 電網(wǎng)大數(shù)據(jù)處理的編碼

前面我們通過配置MapReduce編程環(huán)境，即可完成SP-DPP平臺基本軟件環(huán)境的搭建。接著需要利用MapReduce對智能電網(wǎng)的潮流計算程序進行編程。需要分別書寫Map函數(shù)的代碼和Reduce函數(shù)的代碼。

Map函數(shù)相應(yīng)的偽代碼如圖4所示。

Reduce函數(shù)相應(yīng)的偽代碼如圖5所示。

上述代碼的編寫需要一定的MapReduce的知識，Map函數(shù)的代碼主要是針對潮流計算的串行計算的代碼按照Mapreduce的語法進行移植。Reduce函數(shù)的代碼書寫需要采用簡單的主-從并行程序設(shè)計的思路。

另外由于Hadoop的MapReduce是采用跨平臺的Java語言，由于歷史的原因很多潮流計算的串行源代碼是C++語言書寫,這里我們還利用了JNI技術(shù)在Java環(huán)境下調(diào)用的C++代碼。把這些代碼輸入到Mapreduce環(huán)境下，Hadoop就可以利用NameNode、DateNode、JobTracker和TaskTracker等角色透明的執(zhí)行。

3.4 SP-DPP平臺的優(yōu)勢

本文搭建的SP-DPP云平臺比以前的網(wǎng)格計算、P2P計算、集群計算軟件上要先進，本文的大數(shù)據(jù)處理的任務(wù)分配與調(diào)度模式還改變了傳統(tǒng)的計算模式，使大數(shù)據(jù)處理可以自動地更加靠近存放智能電網(wǎng)數(shù)據(jù)的節(jié)點。早期的并行編程都是數(shù)據(jù)將往任務(wù)往上調(diào)度，SP-DPP平臺是將任務(wù)往數(shù)據(jù)上調(diào)度，因為數(shù)據(jù)容量太大，移動與傳輸速度太慢，將計算盡可能“本地化”以節(jié)約網(wǎng)絡(luò)帶寬而獲得高效的計算速度[19]。

圖3 SP-DPP平臺實現(xiàn)模塊的邏輯關(guān)系

圖4 Map函數(shù)的偽代碼

圖5 Reduce函數(shù)的偽代碼

4 SP-DPP平臺的搭建與測試

4.1 智能電網(wǎng)大數(shù)據(jù)的選取

本文選擇了IEEE 118節(jié)點的智能電網(wǎng)的基本數(shù)據(jù)，按照式(1)和式(2)的方程組約束來計算電網(wǎng)的運行狀態(tài)，要處理的電壓U，功率P，用電負(fù)荷Q等預(yù)先設(shè)置電網(wǎng)的預(yù)想事故為5*104個。這些數(shù)據(jù)的容量為15 GB，相當(dāng)與每個預(yù)先事故容量大為0.3 MB。

4.2 大數(shù)據(jù)處理平臺硬件的配置

根據(jù)前面幾節(jié)分析的SP-DPP的設(shè)計與實現(xiàn)思路和網(wǎng)絡(luò)體系結(jié)構(gòu)，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，我們選擇了學(xué)校的一個機房內(nèi)的機器組成。SP-DPP平臺中共有9個實際的PC機物理節(jié)點，這9個機器在處于同一個局域網(wǎng)內(nèi)，云服務(wù)器主機的配置為：Intel Xeon E3-1220 v5 3.0 GHz四核，內(nèi)存：8 G DDR4，硬盤：1*Intel企業(yè)級SSD，1*SATA 1T，網(wǎng)卡：2*千兆網(wǎng)口；工作機節(jié)點的硬件配置如下：CPU型號Intel Xeon E5 3.0 GHZ；內(nèi)存為8 GB。硬盤容量為1 TB；這些節(jié)點之間通過局域網(wǎng)內(nèi)的1臺千兆交換機相聯(lián)。

4.3 大數(shù)據(jù)處理平臺的軟件環(huán)境的建立

9臺PC機都安裝RedHat Linux操作系統(tǒng)，Hadoop版本為1.0.4，JRE環(huán)境為1.6，用戶只要繼承MapReduceBase，分別實現(xiàn)Map和Reduce的兩個類，即可編寫Map和Reduce的程序[20]。

根據(jù)Apache的Hadoop規(guī)范，對于1個Master機器，部署NameNode和JobTracker，8個Slave機器全部部署DataNode和TaskTracker。值得注意的是Google公司的MapReduce規(guī)范里數(shù)據(jù)服務(wù)器DataNode與任務(wù)服務(wù)器TaskTracker是部署在不同的機器上的，Apache的Hadoop規(guī)范里Data-Node和TaskTracker是同一個節(jié)點，這一點在搭建SP-DPP云平臺的時候必須注意，詳細(xì)軟件配置見表1。

4.4 吞吐量的測試

吞吐量是在相同的時間內(nèi)，我們調(diào)整SP-DPP云平臺的實際物理節(jié)點個數(shù)，完成預(yù)想事故個數(shù)的情況比較。實驗結(jié)果見表2，我們設(shè)置了運行時間為2000 s。表2可以看出SP-DPP平臺完成預(yù)先設(shè)置的電網(wǎng)故障個數(shù)隨著物理節(jié)點的增加穩(wěn)定增加，基本成線性變化，這個實驗結(jié)果和MapReduce主-從模式的編程模型在預(yù)想性能增加上相符合。

表2 智能電網(wǎng)大數(shù)據(jù)處理吞吐量的測試

4.5 執(zhí)行時間與加速比

執(zhí)行時間測試在SP-DPP平臺中是指通過調(diào)整和改變物理節(jié)點個數(shù)，設(shè)置一個固定的預(yù)想電網(wǎng)故障數(shù)量，測試執(zhí)行時間的長短。加速比的計算公式如下

(3)

執(zhí)行時間測試結(jié)果見表3。加速比測試結(jié)果如圖6所示。

表3 調(diào)整物理節(jié)點的Slave個數(shù)執(zhí)行時間測試

圖6 SP-DPP上智能電網(wǎng)大數(shù)據(jù)處理的加速比測試結(jié)果

從表3中可以看出，整SP-DPP平臺進行智能電網(wǎng)狀態(tài)安全分析的執(zhí)行時間隨著Slave物理節(jié)點的增加而穩(wěn)定的緩慢降低，根據(jù)式(3)Speedup隨著物理節(jié)點數(shù)n保持穩(wěn)定的增加,接近于線性Linear，當(dāng)節(jié)點個數(shù)繼續(xù)增加時甚至超過了線性增長，如圖6所示，如果在云平臺上部署更加多的物理節(jié)點，SP-DPP可以在很快的時間內(nèi)完成所有工作單元的計算，也就是說電網(wǎng)公司的調(diào)度中心可以在可以接受的時間范圍內(nèi)判斷整個智能電網(wǎng)是否安全運行。

5 結(jié)束語

本文提出了一個基于云計算的智能電網(wǎng)大數(shù)據(jù)處理平臺SP-DPP。通過對電力系統(tǒng)潮流計算測試，實驗結(jié)果表明SP-DPP云平臺具有良好的吞吐量和加速比。值得說明的是SP-DPP平臺不針對特定的應(yīng)用而設(shè)計，SP-DPP平臺上可運行的應(yīng)用不局限于潮流計算，任何具有Master-Slave特色的并行應(yīng)用都可以通過任務(wù)劃分與數(shù)據(jù)劃分，利用Map-Reduce的編程思想在SP-DPP平臺上完成計算。下一步的工作是利用Spark或者更新版本的Hadoop的MapReduce規(guī)范完成平臺搭建[21]。