基于云計算的智能電網大數據處理平臺

李 佳，徐勝超

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

0 引 言

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

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

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

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

1 智能電網大數據處理的數學模型

1.1 大數據處理的數學模型

判斷一個智能電網的狀態，最常用的數據模型是潮流計算[12,13]。經典的潮流方程的極坐標形式為

(1)

(2)

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

1.2 智能電網大數據的劃分

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

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

圖1 智能電網大數據的任務劃分

2 SP-DPP平臺的設計

2.1 平臺的總體設計思路

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

智能電網大數據處理云平臺SP-DPP邏輯上劃分成4個模塊：大數據存儲與管理模塊、任務分配與調度模塊、大數據執行模塊和客戶端模塊。該SP-DPP云平臺的主要功能是滿足智能電網海量數據處理的需求，通過計算出潮流計算的結果，對智能電網的狀態安全進行分析與監控。

2.2 大數據存儲與管理模塊

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

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

圖2 基于云計算的智能電網大數據處理平臺SP-DPP

2.3 任務分配與調度模塊

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

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

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

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

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

另外任務分配與調度模塊設計中還必須根據當前文件系統中文件所在的位置和大小決定如何創建其它的工作機，并對工作機大數據處理的執行狀態進行監控。

2.4 大數據處理執行模塊

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

2.5 客戶端模塊

客戶端是互聯網上的用戶訪問SP-DPP云平臺的方式，SP-DPP云平臺可供客戶端訪問。客戶端可以按照服務等級協議(service level agreements，SLA)，采用按時付費(pay-per-use，PPU)的模式來管理。

3 SP-DPP平臺的實現

3.1 編程模型的實現

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

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

MapReduce編程規范[18]是分布式大數據存儲、任務調度、任務執行、容錯、負載均衡的整合體，在SP-DPP平臺中，應用程序編寫人員只需將精力放在Mapper和Reducer程序的編寫上即可完成智能電網大數據狀態安全的分析。

3.2 各個模塊的實現

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

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

工作機模塊的實現使用了Hadoop的規范中的TaskTracker角色來完成。相對于JobTracker的主控任務來說，TaskTracker是從屬任務，運行在從屬節點上，主要負責接收JobTracker分發的子任務并執行，并將執行狀態和結果向上傳遞給JobTracker。最后在Hadoop的規范中還有一個作業(Job)的提交者，即是客戶端。

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

3.3 電網大數據處理的編碼

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

Map函數相應的偽代碼如圖4所示。

Reduce函數相應的偽代碼如圖5所示。

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

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

3.4 SP-DPP平臺的優勢

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

圖3 SP-DPP平臺實現模塊的邏輯關系

圖4 Map函數的偽代碼

圖5 Reduce函數的偽代碼

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

4.1 智能電網大數據的選取

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

4.2 大數據處理平臺硬件的配置

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

4.3 大數據處理平臺的軟件環境的建立

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

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

4.4 吞吐量的測試

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

表2 智能電網大數據處理吞吐量的測試

4.5 執行時間與加速比

執行時間測試在SP-DPP平臺中是指通過調整和改變物理節點個數，設置一個固定的預想電網故障數量，測試執行時間的長短。加速比的計算公式如下

(3)

執行時間測試結果見表3。加速比測試結果如圖6所示。

表3 調整物理節點的Slave個數執行時間測試

圖6 SP-DPP上智能電網大數據處理的加速比測試結果

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

5 結束語

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