基于云計(jì)算的智能電網(wǎng)大數(shù)據(jù)處理平臺(tái)

李 佳，徐勝超

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

0 引 言

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

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

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

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

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

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

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

(1)

(2)

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

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

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

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

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

2 SP-DPP平臺(tái)的設(shè)計(jì)

2.1 平臺(tái)的總體設(shè)計(jì)思路

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

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

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

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

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

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

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

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

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

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

然后就是容錯(cuò)的問(wèn)題。這里SP-DPP平臺(tái)使用冗余的方式和分布式存儲(chǔ)來(lái)處理，這是云計(jì)算的特點(diǎn)。容錯(cuò)策略還必須自動(dòng)檢測(cè)到失效節(jié)點(diǎn)，將失效節(jié)點(diǎn)排除，不影響SP-DPP平臺(tái)的主控任務(wù)的正常運(yùn)行。

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

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

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

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

2.5 客戶端模塊

客戶端是互聯(lián)網(wǎng)上的用戶訪問(wèn)SP-DPP云平臺(tái)的方式，SP-DPP云平臺(tái)可供客戶端訪問(wèn)。客戶端可以按照服務(wù)等級(jí)協(xié)議(service level agreements，SLA)，采用按時(shí)付費(fèi)(pay-per-use，PPU)的模式來(lái)管理。

3 SP-DPP平臺(tái)的實(shí)現(xiàn)

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

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

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

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

3.2 各個(gè)模塊的實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

3.4 SP-DPP平臺(tái)的優(yōu)勢(shì)

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

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

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

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

4 SP-DPP平臺(tái)的搭建與測(cè)試

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

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

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

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

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

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

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

4.4 吞吐量的測(cè)試

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

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

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

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

(3)

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

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

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

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

5 結(jié)束語(yǔ)

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