基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略

蒲勇霖 于 炯 魯 亮 李梓楊 國冰磊 廖 彬

1(新疆大學(xué)信息科學(xué)與工程學(xué)院 烏魯木齊 830046) 2(中國民航大學(xué)計算機科學(xué)與技術(shù)學(xué)院 天津 300300) 3(新疆財經(jīng)大學(xué)統(tǒng)計與數(shù)據(jù)科學(xué)學(xué)院 烏魯木齊 830012)

(puyonglin1991@foxmail.com)

近年來，隨著各種功能強大的高速互聯(lián)技術(shù)的出現(xiàn)，物聯(lián)網(wǎng)場景下產(chǎn)生的數(shù)據(jù)量日益增多，對計算能力的需求日益增長，高性能集群由于其高性價比、高可用性以及可擴展性等特點[1]已成為商業(yè)應(yīng)用與學(xué)術(shù)研究的基礎(chǔ)架構(gòu).但是各種高性能集群在處理數(shù)據(jù)時產(chǎn)生的高能耗問題同樣不容忽視.高德納(Gartner)公司指出預(yù)計到2015年，全球數(shù)據(jù)中心占比71%的大型數(shù)據(jù)中心其電費支出超過1 262億美元[2]，而預(yù)計2020年，全球數(shù)據(jù)中心的能耗產(chǎn)值為20 000億kW·h[3].我國數(shù)據(jù)中心的總耗電量同樣驚人，截至2018年中國數(shù)據(jù)中心的總耗電量為1 608.89億kW·h，占全國總用電量的2.35%[4].高額的能耗成本已對社會與環(huán)境造成巨大影響，因此解決IT行業(yè)的高能耗問題已經(jīng)刻不容緩.

希捷(Seagate)公司與IDC聯(lián)合發(fā)布的《數(shù)據(jù)時代2025》白皮書中預(yù)測，2025年全球數(shù)據(jù)量將達(dá)到163ZB.其中，超過25%的數(shù)據(jù)將成為實時數(shù)據(jù)，而物聯(lián)網(wǎng)實時數(shù)據(jù)占比將達(dá)到實時數(shù)據(jù)的95%[5].針對大數(shù)據(jù)處理的高性能集群一般分為批量計算框架與流計算框架2類.其中批量計算框架由于存在先存儲后計算的特性無法滿足實時數(shù)據(jù)的處理需求；而流計算框架由于其強大的實時性，為實時大數(shù)據(jù)分析提供了良好的平臺層解決方案[6].但是流式計算在高速處理實時數(shù)據(jù)的過程中同樣伴隨著高能耗的問題[7]，因此流計算框架的節(jié)能優(yōu)化是一個亟待解決的問題.

目前針對大數(shù)據(jù)流式處理的平臺主要以Apache Storm框架[8]為主.Storm是一個主從式架構(gòu)、開源、橫向擴展性良好且容錯能力強的分布式實時處理平臺，其編程模型簡單，支持包含Java在內(nèi)的多種編程語言，且數(shù)據(jù)處理高效.與不開源的Puma[9]以及社區(qū)冷淡的S4[10]相比，Storm具有更活躍的社區(qū)發(fā)展；與屬于微批的Spark Streaming[11]框架相比，Storm具有更穩(wěn)定的集群性能；與后起之秀Flink[12]與Heron[13]相比，Storm具有更成熟的平臺架構(gòu)和更廣泛的產(chǎn)業(yè)基礎(chǔ).目前Storm憑借低延遲、高吞吐的性能優(yōu)勢以及高效的容錯機制[14]，已經(jīng)成為華為、百度以及小米等企業(yè)針對流數(shù)據(jù)處理業(yè)務(wù)的最佳選擇，被譽為“實時處理領(lǐng)域的Hadoop”[15].

在Storm框架中，流式作業(yè)(拓?fù)?中的1個任務(wù)通常運行于1個工作線程內(nèi)，1個工作進(jìn)程包含有多個工作線程.但當(dāng)Storm集群拓?fù)湓谔幚砣蝿?wù)出現(xiàn)計算資源不足或拓?fù)鋱箦e時，缺乏合理的應(yīng)對策略，從而對集群拓?fù)淙蝿?wù)處理的計算延遲與能耗造成影響，具體體現(xiàn)有2點：1)集群拓?fù)湓趫?zhí)行任務(wù)時，工作節(jié)點可能會出現(xiàn)資源瓶頸的問題，工作節(jié)點的資源接近溢出，其功率不斷增大，集群的計算延遲不斷上升，對集群的性能與能耗造成巨大影響；2)拓?fù)湓趫?zhí)行任務(wù)時，由于網(wǎng)絡(luò)等問題而出現(xiàn)錯誤，需要終止拓?fù)鋬?nèi)的任務(wù)并從磁盤重新讀取數(shù)據(jù)，但是從磁盤讀取數(shù)據(jù)存在較高的計算延遲與能耗，會對集群拓?fù)淙蝿?wù)的正常執(zhí)行造成一定的影響.因此，為了解決該問題.本文提出基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略(energy-efficient strategy based on data recovery in Storm, DR-Storm)，該策略在降低集群出現(xiàn)過高計算延遲的基礎(chǔ)上，保證集群拓?fù)淙蝿?wù)的順利執(zhí)行并有效節(jié)約能耗.

本文的主要貢獻(xiàn)包括3個方面：

1) 通過分析Storm框架的任務(wù)邏輯，建立任務(wù)分配模型，用于描述集群內(nèi)工作節(jié)點間任務(wù)分配的邏輯關(guān)系，為后續(xù)監(jiān)控集群拓?fù)鋬?nèi)的元組信息提供幫助，并為研究集群拓?fù)鋬?nèi)的任務(wù)執(zhí)行情況奠定了理論基礎(chǔ).

2) 根據(jù)任務(wù)分配模型，建立了拓?fù)湫畔⒈O(jiān)控模型，通過監(jiān)控反饋信息判斷是否終止拓?fù)鋬?nèi)的任務(wù)，并進(jìn)一步建立數(shù)據(jù)恢復(fù)模型，其中是否對集群拓?fù)溥M(jìn)行數(shù)據(jù)恢復(fù)由拓?fù)湫畔⒈O(jiān)控模型反饋的元組信息決定.在確定終止集群任務(wù)后，對集群拓?fù)溥M(jìn)行數(shù)據(jù)恢復(fù).

3) 根據(jù)拓?fù)湫畔⒈O(jiān)控模型與數(shù)據(jù)恢復(fù)模型，建立能耗模型，并在此基礎(chǔ)上提出基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略，該策略包括吞吐量檢測算法與數(shù)據(jù)恢復(fù)算法，其中吞吐量檢測算法通過監(jiān)控拓?fù)鋬?nèi)的元組信息計算集群吞吐量，判斷是否終止集群拓?fù)鋬?nèi)的任務(wù)；而數(shù)據(jù)恢復(fù)算法根據(jù)吞吐量檢測算法執(zhí)行情況，確定是否對集群拓?fù)溥M(jìn)行數(shù)據(jù)恢復(fù).此外，實驗選取4個代表不同作業(yè)類型的基準(zhǔn)測試[16]，從不同角度驗證了算法的有效性.

1 相關(guān)工作

目前針對Storm，F(xiàn)link，Spark Streaming，Heron等主流大數(shù)據(jù)流式計算框架的節(jié)能研究相對較少.但是IT行業(yè)日益增長的高能耗問題，已經(jīng)嚴(yán)重制約著平臺的發(fā)展.因此針對大數(shù)據(jù)流式計算框架的節(jié)能優(yōu)化已經(jīng)刻不容緩，是未來重要的研究方向.目前針對大數(shù)據(jù)流式計算框架的節(jié)能研究主要集中于硬件節(jié)能[17]、軟件節(jié)能[18]與軟硬件結(jié)合[19]3種方法.

硬件的節(jié)能主要基于2種思路：1)通過用低能耗、高效率的電子元件替換高能耗、低效率的電子元件[20]；2)對集群的節(jié)點電壓進(jìn)行縮放管理[21].2種思路的節(jié)能效果顯著，但是由于其價格高昂，且對節(jié)點電壓進(jìn)行縮放管理存在較大誤差，因此不適合部署在大規(guī)模的集群當(dāng)中.蒲勇霖等人[22]通過對Storm集群工作節(jié)點的內(nèi)存電壓進(jìn)行動態(tài)調(diào)節(jié)，在不影響集群性能的條件下分別節(jié)約了系統(tǒng)28.5%與35.1%的能耗.Shin等人[23]提出了一種混合內(nèi)存的節(jié)能策略，通過用低能耗高效率的PRAM(parallel random access machine)替換高能耗低效率的DRAM(dynamic random access memory)，從而達(dá)到提高集群性能并降低能耗的目的.實驗結(jié)果表明該策略降低了集群36%～42%的能耗.Pietri等人[24]通過將流式處理平臺的部分CPU替換成GPU，使得CPU與GPU進(jìn)行混合，從而減少了集群處理圖數(shù)據(jù)的能耗，實驗結(jié)果表明在節(jié)約9.69%能耗的前提下減少了8.63%的訪問時間.文獻(xiàn)[25]通過使用動態(tài)電壓頻率縮放技術(shù)(dynamic voltage frequency scaling, DVFS)，對集群節(jié)點的CPU電壓進(jìn)行了動態(tài)縮放管理，以此達(dá)到了節(jié)能的效果.文獻(xiàn)[26-28]通過替換高能耗、低效率的電子元件，在提高集群性能的基礎(chǔ)上節(jié)約了能耗.

軟件與軟硬件結(jié)合的節(jié)能策略是目前研究的重點，其中軟件的節(jié)能主要根據(jù)建立能耗感知模型[29]與通過資源調(diào)度[30]提高集群的能效，以達(dá)到節(jié)能的目的.文獻(xiàn)[31]根據(jù)分析Spark Streaming框架的基本特性，提出一種自適應(yīng)調(diào)度作業(yè)的節(jié)能策略，該策略通過在集群中建立能耗感知模型，對集群內(nèi)的數(shù)據(jù)信息進(jìn)行實時捕捉，從而分析集群任務(wù)的實際運行情況，根據(jù)不同任務(wù)的執(zhí)行結(jié)果對集群的性能與能耗進(jìn)行調(diào)控.實驗表明該策略降低了集群的時間開銷并節(jié)約了能耗.文獻(xiàn)[32]提出一種作用于Spark Streaming的能耗分析基準(zhǔn)測試方法，該方法通過使用機器學(xué)習(xí)算法，查找集群內(nèi)數(shù)據(jù)流的大小與通信開銷的平衡，實驗結(jié)果表明當(dāng)集群內(nèi)數(shù)據(jù)流的大小與通信開銷達(dá)到平衡時，集群執(zhí)行任務(wù)的功耗最小.

文獻(xiàn)[7]對流式大數(shù)據(jù)處理的框架進(jìn)行了優(yōu)化，提出了一種基于Storm框架的實時資源調(diào)度節(jié)能策略，該策略通過構(gòu)建Storm的能耗、響應(yīng)時間以及資源利用率之間的數(shù)學(xué)關(guān)系，獲得了滿足高能效和低響應(yīng)時間的條件，并以此建立了實時資源調(diào)度模型，該模型在實現(xiàn)最佳能效的前提下，對集群的資源進(jìn)行調(diào)度.然而該策略還存在2點值得探討：1)節(jié)能策略只考慮了CPU的資源利用率與能耗，忽視了集群其他電子元件(內(nèi)存、網(wǎng)絡(luò)帶寬與磁盤等)的資源利用率與能耗.由于流式處理集群的實時性較高，其他電子元件的資源利用率與能耗對其影響巨大而不容忽視；2)該節(jié)能策略使用自己定義的拓?fù)?，而非公認(rèn)的數(shù)據(jù)集，因此缺乏一定的通用性.

軟硬件結(jié)合的節(jié)能主要通過對資源遷移后節(jié)點的電壓進(jìn)行動態(tài)縮放管理[33]或關(guān)閉其空閑的節(jié)點[34]，以達(dá)到節(jié)能的效果.文獻(xiàn)[35]通過分析流式大數(shù)據(jù)的自身特性，設(shè)計了2種節(jié)能算法，即能量感知副本算法與性能和能量均衡副本算法.2種節(jié)能算法根據(jù)集群任務(wù)的實際運行情況，對任務(wù)完成后或不執(zhí)行任務(wù)處理的節(jié)點進(jìn)行降壓處理，以此達(dá)到節(jié)能的目的.文獻(xiàn)[36]通過分析Spark Streaming框架在執(zhí)行任務(wù)時性能與能耗的權(quán)衡，提出一種基于調(diào)度工作負(fù)載的高效節(jié)能策略.該策略通過建立時間序列預(yù)測模型對集群任務(wù)的處理時間與能耗進(jìn)行捕捉，并使用DVFS技術(shù)來調(diào)節(jié)集群節(jié)點的電壓，以此達(dá)到降低集群能耗的目的.

文獻(xiàn)[19]從集群拓?fù)淙蝿?wù)處理的彈性出發(fā)，提出一種針對流式大數(shù)據(jù)平臺的彈性能耗感知節(jié)能策略(keep calm and react with foresight:strategies for low-latency and energy-efficient elastic data stream processing, LEEDSP)，該策略通過建立能耗感知模型，對集群的任務(wù)處理進(jìn)行彈性調(diào)節(jié)，以實現(xiàn)提高集群吞吐量并節(jié)約能耗的目的.但是該節(jié)能策略并不是始終有效的，這是由于大數(shù)據(jù)流式處理平臺的任務(wù)一旦提交，將持續(xù)運行下去，而長時間運行節(jié)能策略會導(dǎo)致集群拓?fù)鋬?nèi)的任務(wù)處理出現(xiàn)不平衡，從而嚴(yán)重影響集群拓?fù)淙蝿?wù)的正常執(zhí)行.

文獻(xiàn)[37]針對Storm框架在進(jìn)行數(shù)據(jù)處理時存在高能耗的問題，提出數(shù)據(jù)遷移合并節(jié)能策略(energy-efficient strategy for data migration and merging in Storm, DMM-Storm)，該策略通過設(shè)計資源約束模型與最優(yōu)線程數(shù)據(jù)重組原則，對集群內(nèi)的資源進(jìn)行遷移，并使用DVFS技術(shù)對遷移資源后工作節(jié)點的CPU進(jìn)行電壓縮放管理，有效降低了集群的能耗與節(jié)點間的通信開銷.但是仍存在2點有待優(yōu)化：其一為該節(jié)能策略對集群拓?fù)涮幚砣蝿?wù)的實時性造成一定影響；其二為使用DVFS技術(shù)調(diào)節(jié)集群節(jié)點CPU的電壓存在較大的偶然性，且技術(shù)的實現(xiàn)難度較高不適合部署于大規(guī)模集群當(dāng)中.

與上述研究成果相比，本文的不同之處在于：

1) 文獻(xiàn)[19,23-36]均未考慮任務(wù)遷移后，對集群工作節(jié)點的資源占用(CPU、內(nèi)存與網(wǎng)絡(luò)帶寬等)是否造成影響，而文獻(xiàn)[7]忽視了除CPU之外，其他電子元件對集群工作節(jié)點資源占用的影響.本文通過建立資源約束模型，避免了集群在進(jìn)行任務(wù)處理時對節(jié)點資源占用造成的影響.

2) 文獻(xiàn)[37]存在影響集群性能的問題，且節(jié)點CPU電壓的調(diào)節(jié)存在偶然性.本文通過減少集群拓?fù)淙蝿?wù)處理的延遲，在提高集群性能的同時節(jié)約了集群的能耗.此外，并未對節(jié)點CPU的電壓進(jìn)行調(diào)節(jié)，避免了因動態(tài)調(diào)節(jié)CPU電壓而對集群拓?fù)湔?zhí)行任務(wù)造成影響.

3) 實驗選取Intel公司Zhang[16]發(fā)布在GitHub上的4組Benchmark進(jìn)行測試，而非自己定義的拓?fù)洌虼烁哂泄J(rèn)性.此外，本文與LEEDSP[19]，DMM-Storm[37]進(jìn)行實驗對比，驗證了節(jié)能策略的效果.

2 問題建模與分析

為了量化集群拓?fù)鋱?zhí)行任務(wù)的能耗，本節(jié)首先建立Storm的任務(wù)分配模型、拓?fù)湫畔⒈O(jiān)控模型以及數(shù)據(jù)恢復(fù)模型，并在此基礎(chǔ)上建立能耗模型.其中Storm的任務(wù)分配模型描述了拓?fù)渲泄ぷ鞴?jié)點與各個任務(wù)之間的對應(yīng)關(guān)系，為后續(xù)判斷集群拓?fù)涞娜蝿?wù)執(zhí)行奠定了基礎(chǔ)；拓?fù)湫畔⒈O(jiān)控模型通過定義集群工作節(jié)點的資源約束設(shè)置滑動時間窗口，并計算集群吞吐量，確定集群拓?fù)淙蝿?wù)的執(zhí)行情況，以此判斷是否終止拓?fù)鋬?nèi)的任務(wù)；數(shù)據(jù)恢復(fù)模型將集群內(nèi)的數(shù)據(jù)備份到內(nèi)存，根據(jù)信息監(jiān)控模型的反饋信息，確定是否進(jìn)行數(shù)據(jù)恢復(fù)，并根據(jù)數(shù)據(jù)存儲限制對節(jié)點內(nèi)備份的數(shù)據(jù)進(jìn)行實時刪除；能耗模型通過任務(wù)的執(zhí)行時間與功率計算集群能耗，為節(jié)能策略的實現(xiàn)提供了理論依據(jù).

Fig. 1 Data allocation in the topology圖1 拓?fù)鋬?nèi)的數(shù)據(jù)分配

2.1 Storm的任務(wù)分配模型

在Storm框架中，1個流式作業(yè)由1個稱為拓?fù)?topology)的有向無環(huán)圖構(gòu)成，其中由數(shù)據(jù)源編程單元Spout和數(shù)據(jù)處理編程單元Bolt這2類組件(component)共同構(gòu)成了有向無環(huán)圖的頂點，各組件之間通過不同的流組模式發(fā)送和接收數(shù)據(jù)流，構(gòu)成了有向無環(huán)圖的邊.為了提高集群拓?fù)涞膱?zhí)行效率，需要滿足每個組件在同一時刻創(chuàng)建多個實例，稱之為任務(wù)(task).1個任務(wù)運行于1個工作線程(executor)內(nèi)，是各組件最終執(zhí)行的代碼單元.拓?fù)涮峤坏郊汉?，任?wù)將分布到各個工作節(jié)點中，并開始進(jìn)行任務(wù)的處理和任務(wù)間數(shù)據(jù)流的傳輸工作.令Storm集群工作節(jié)點的集合為N={n1,n2,…,n|N|}，且工作節(jié)點內(nèi)存在組件的集合為C={c1,c2,…,c|C|}，由于每個組件都可同時創(chuàng)建多個實例，則組件ci創(chuàng)建的第j個實例作為任務(wù)tij(若組件ci創(chuàng)建的實例數(shù)為1，則將該任務(wù)簡化為任務(wù)ti)，由此存在T(N)={ti1,ti2,…,tin}表示工作節(jié)點分配到拓?fù)涞娜蝿?wù)集合.圖1為集群拓?fù)鋬?nèi)的任務(wù)分配情況，共由3個工作節(jié)點、12個實例與19條有向邊組成.其中節(jié)點集合為N={n1,n2,n3}，各工作節(jié)點內(nèi)的任務(wù)集合為Tn1={ta,td1,tf1,th1}，Tn2={tb,td2,tf2,th2}，Tn3={tc,te,tg,ti}.

2.2 拓?fù)湫畔⒈O(jiān)控模型

(1)

(2)

(3)

此外，集群拓?fù)湓趫?zhí)行任務(wù)時可能會出現(xiàn)節(jié)點丟失(報錯)的問題，則集群拓?fù)渚蜁釛壴摴?jié)點(不再向該節(jié)點分配任務(wù))，此時集群內(nèi)工作節(jié)點的資源占用率會迅速升高，從而接近工作節(jié)點資源占用的極限(該現(xiàn)象被稱為工作節(jié)點的資源瓶頸)，進(jìn)而影響任務(wù)的順利執(zhí)行，并提高工作節(jié)點執(zhí)行任務(wù)的功率.為解決這一問題，需要設(shè)置滑動時間窗口計算集群吞吐量，從而實時反饋拓?fù)鋱?zhí)行任務(wù)的信息，對任務(wù)的執(zhí)行情況進(jìn)行判斷.滑動時間窗口的設(shè)置可用定義2表示：

定義2.滑動時間窗口.滑動時間窗口的取值可通過定義時間窗口的初始值對額外增加的網(wǎng)絡(luò)資源占用率與系統(tǒng)延遲的影響確定.令滑動時間窗口的初始值為wori，額外增加的網(wǎng)絡(luò)資源占用率為oext，系統(tǒng)計算延遲為tdel，則滑動時間窗口的初始值對額外增加的網(wǎng)絡(luò)資源占用率與系統(tǒng)計算延遲的影響為

(4)

其中,a表示其他因素如拓?fù)淙蝿?wù)處理帶來的影響，為常數(shù).為選擇對額外增加的網(wǎng)絡(luò)資源占用率與系統(tǒng)延遲影響最小的時間窗口取值，則可通過式(5)獲得其相應(yīng)窗口

Ii=min(I1,I2,…,In).

(5)

通過式(5)可知，當(dāng)時間窗口為Ii時，其取值對額外增加的網(wǎng)絡(luò)資源占用率與系統(tǒng)延遲的影響最小，此時對應(yīng)的時間窗口取值為wi.本文滑動時間窗口的取值通過4.1節(jié)進(jìn)行測試.此外在實際應(yīng)用中，可將不同數(shù)值帶入式(4)(5)，通過多次訓(xùn)練，確定合適的時間窗口取值.

為保障拓?fù)鋱?zhí)行任務(wù)時Storm集群的性能不受影響，需要對拓?fù)鋬?nèi)的每個tuple進(jìn)行標(biāo)記，使其在單位時間內(nèi)以心跳信息形式進(jìn)行信息反饋，并通過計算集群吞吐量判斷拓?fù)淙蝿?wù)的執(zhí)行情況，從而確定是否結(jié)束拓?fù)鋬?nèi)的任務(wù).圖2為時間窗口的設(shè)置與集群吞吐量的計算示意圖，令滑動時間窗口的長度為w(單位為s)，數(shù)據(jù)的標(biāo)記信息為Mlab，發(fā)送信息的節(jié)點為NWorkNode，接收信息的節(jié)點為NNimbus，則滑動時間窗口的信息反饋為

(6)

(7)

Fig. 2 Time window setting and cluster throughput computing圖2 時間窗口的設(shè)置與集群吞吐量的計算

此外，檢測集群吞吐量存在2個限制條件：1)因節(jié)點丟失等問題而出現(xiàn)資源瓶頸，導(dǎo)致集群吞吐量低于原集群吞吐量的最低值；2)因網(wǎng)絡(luò)等問題而出現(xiàn)拓?fù)鋱箦e，集群吞吐量為零.因此為檢測集群吞吐量是否受限制條件的影響，需要設(shè)置集群吞吐量的下限，令集群吞吐量存在1個閾值下限為pval，為保障集群拓?fù)鋬?nèi)的任務(wù)順利執(zhí)行，則：

(8)

因此，根據(jù)式(8)對集群拓?fù)鋱?zhí)行任務(wù)進(jìn)行判斷，確定是否終止集群拓?fù)鋬?nèi)的任務(wù).

2.3 數(shù)據(jù)恢復(fù)模型

Storm集群在進(jìn)行數(shù)據(jù)的傳輸與處理時，數(shù)據(jù)通過磁盤發(fā)送至集群拓?fù)?根據(jù)2.2節(jié)可知，當(dāng)集群出現(xiàn)資源瓶頸或拓?fù)鋱箦e時，終止集群任務(wù)，但由于從磁盤內(nèi)讀取數(shù)據(jù)，整個集群的計算延遲與能耗開銷相對較大，因此建立數(shù)據(jù)恢復(fù)模型，使集群通過內(nèi)存讀取數(shù)據(jù)，以此減少不必要的計算延遲與能耗開銷.

定義3.內(nèi)存數(shù)據(jù)存儲.為減少由于數(shù)據(jù)從磁盤讀取而產(chǎn)生不必要的計算延遲與能耗開銷，現(xiàn)選擇內(nèi)存資源占用率最小的節(jié)點作為備份節(jié)點，用于數(shù)據(jù)的存儲，具體的計算為

Fig. 3 Data monitoring and recovery in the topology圖3 拓?fù)鋬?nèi)數(shù)據(jù)監(jiān)控與恢復(fù)

(9)

(10)

此外，將磁盤內(nèi)的數(shù)據(jù)存儲至備份節(jié)點內(nèi)存，會增加額外的節(jié)點間通信開銷，但由于出現(xiàn)資源瓶頸或拓?fù)鋱箦e等問題而終止集群任務(wù)后，數(shù)據(jù)從備份節(jié)點內(nèi)存讀取相比于從磁盤讀取降低了延遲，因此這部分額外增加的節(jié)點間通信開銷對集群拓?fù)淙蝿?wù)處理的影響可忽略不計.

為計算集群數(shù)據(jù)恢復(fù)的時間，令拓?fù)鋸膬?nèi)存讀取數(shù)據(jù)的時間為Timeram，滑動時間窗口信息反饋的時間為Timewin，終止集群任務(wù)的時間為Timeter，則拓?fù)鋸膬?nèi)存恢復(fù)數(shù)據(jù)的時間Timeres為

Timeres=Timewin+Timeter+Timeram.

(11)

此外，由于滑動時間窗口信息反饋的時間與終止集群任務(wù)的時間非常短，可忽略不計，則化簡式(11)可得:

Timeres=Timeram.

(12)

為計算集群數(shù)據(jù)傳輸與處理的總時間，令拓?fù)鋸拇疟P讀取數(shù)據(jù)的時間為Timedisk，由于集群拓?fù)鋽?shù)據(jù)傳輸與處理的時間為Timepro，則集群數(shù)據(jù)傳輸與處理的總時間Timetot為

Timetot=Timedisk+Timepro.

(13)

此外，若原集群拓?fù)湓趫?zhí)行任務(wù)時因網(wǎng)絡(luò)等問題而出現(xiàn)拓?fù)鋱箦e的問題，令報錯前數(shù)據(jù)傳輸與處理的時間為Timebef，報錯后數(shù)據(jù)傳輸與處理的時間為Timeaft，由于拓?fù)鋱箦e之后，集群拓?fù)鋬?nèi)的數(shù)據(jù)需要重新讀取，因此，數(shù)據(jù)傳輸與處理的時間與原集群拓?fù)淙蝿?wù)處理的時間相等，即

Timeaft=Timepro.

(14)

由于拓?fù)鋱箦e后，原集群拓?fù)鋸拇疟P讀取數(shù)據(jù)，即

(15)

(16)

(17)

則當(dāng)出現(xiàn)資源瓶頸時，集群數(shù)據(jù)傳輸與處理的總時間為

(18)

其中,p′表示原集群拓?fù)湓趫?zhí)行任務(wù)出現(xiàn)資源瓶頸時集群的平均吞吐量.

若原集群拓?fù)湓趫?zhí)行任務(wù)出現(xiàn)拓?fù)鋱箦e或資源瓶頸時，集群使用數(shù)據(jù)恢復(fù)模型，則同理可得集群數(shù)據(jù)傳輸與處理的總時間Time?tot為

(19)

(20)

則集群使用數(shù)據(jù)恢復(fù)模型后，減少的計算延遲Timesave為

(21)

其中,式(21)內(nèi)的參數(shù)與式(16)(18)(20)相同.

2.4 能耗模型

針對流式處理集群建立能耗模型首先需要注意是否影響集群的性能，而降低集群能耗一般從2個角度出發(fā)：1)提高集群拓?fù)淙蝿?wù)處理的速度，減少任務(wù)處理的時間；2)降低集群拓?fù)淙蝿?wù)處理的功率.因此需要引入經(jīng)典的能耗模型，即

Energy=Power×Time,

(22)

其中,Energy表示集群拓?fù)淙蝿?wù)處理的能耗，Power表示集群拓?fù)淙蝿?wù)處理的功率，Time表示集群拓?fù)鋱?zhí)行任務(wù)的總時間.現(xiàn)將式(13)代入式(22)，化簡可得:

Energy=Power×(Timedisk+Timepro).

(23)

若集群拓?fù)湓谌蝿?wù)處理的過程中出現(xiàn)拓?fù)鋱箦e，則系統(tǒng)的能耗為

(24)

其中,Energy1表示出現(xiàn)拓?fù)鋱箦e后集群的能耗，Power1表示出現(xiàn)拓?fù)鋱箦e后集群的平均功率.若集群拓?fù)湓谌蝿?wù)處理的過程中出現(xiàn)資源瓶頸，則系統(tǒng)的能耗為

(25)

其中,Energy2表示出現(xiàn)資源瓶頸后集群的能耗，Power2表示出現(xiàn)資源瓶頸后集群的平均功率.若原集群拓?fù)湓趫?zhí)行任務(wù)出現(xiàn)拓?fù)鋱箦e或資源瓶頸時，使用數(shù)據(jù)恢復(fù)模型，則系統(tǒng)的能耗為

Energy3=

(26)

其中,Energy3表示使用數(shù)據(jù)恢復(fù)模型后集群的能耗，Power3表示使用數(shù)據(jù)恢復(fù)模型后集群的平均功率.則集群使用數(shù)據(jù)恢復(fù)模型后，節(jié)約的能耗Energysave為

(27)

其中,式(27)內(nèi)的參數(shù)與式(24)～(26)相同.

3 節(jié)能策略分析

在理論模型的基礎(chǔ)上，提出基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略，該策略包括吞吐量檢測算法與數(shù)據(jù)恢復(fù)算法，通過在原集群拓?fù)鋱?zhí)行任務(wù)出現(xiàn)拓?fù)鋱箦e或資源瓶頸時，終止拓?fù)鋬?nèi)的任務(wù)并通過備份節(jié)點內(nèi)存讀取數(shù)據(jù)，以此降低了系統(tǒng)計算延遲與能耗開銷.該策略主要分為4個步驟:

1) 選擇內(nèi)存資源占用率最低的工作節(jié)點作為備份節(jié)點，并對備份節(jié)點的內(nèi)存進(jìn)行邏輯分割以用于數(shù)據(jù)存儲.

2) 根據(jù)拓?fù)湫畔⒈O(jiān)控模型判斷集群拓?fù)涫欠癯霈F(xiàn)資源瓶頸或拓?fù)鋱箦e.

3) 根據(jù)數(shù)據(jù)恢復(fù)模型從備份節(jié)點的內(nèi)存向集群拓?fù)渥x取數(shù)據(jù).

4) 根據(jù)節(jié)能策略計算集群的延遲與能耗開銷.

具體流程圖如圖4所示:

Fig. 4 Flowchart of energy-efficient strategy圖4 節(jié)能策略流程圖

3.1 吞吐量檢測算法

為監(jiān)控集群拓?fù)湓趫?zhí)行任務(wù)時是否會出現(xiàn)資源瓶頸或拓?fù)鋱箦e的問題，需要設(shè)計吞吐量檢測算法.其中該算法需要對集群拓?fù)鋬?nèi)的元組進(jìn)行標(biāo)記，并根據(jù)計算集群吞吐量判斷拓?fù)鋬?nèi)的任務(wù)執(zhí)行情況.該算法保證集群的實際吞吐量低于閾值下限時，終止拓?fù)鋬?nèi)的任務(wù).由于需要對整個集群拓?fù)鋬?nèi)的數(shù)據(jù)信息進(jìn)行遍歷，因此需要確定工作節(jié)點與各個任務(wù)之間的對應(yīng)關(guān)系.具體情況在算法1中描述.

算法1.吞吐量檢測算法.

輸入：集群拓?fù)涞娜蝿?wù)集合T(N)={ti1,ti2,…,tin}、時間窗口長度w、數(shù)據(jù)的標(biāo)記信息Mlab、集群實際吞吐量p、集群吞吐量的閾值下限pval；

輸出：判斷是否終止集群拓?fù)鋬?nèi)的任務(wù).

① newMlab(labletuple)；*對集群內(nèi)的元組信息進(jìn)行標(biāo)記*

②WindowLength=w；*滑動時間窗口的長度為w*

③ fortid=ti1toT(N).tindo

④NWordNode=NNimbus；*工作節(jié)點將數(shù)據(jù)信息匯總至主控節(jié)點*

⑤ 心跳信息轉(zhuǎn)化為集群吞吐量；

⑥ 根據(jù)式(7)計算集群吞吐量；

⑦ switchpval=pthen

⑧ case1：

⑨pval-p=pval；*出現(xiàn)拓?fù)鋱箦e*

⑩ 終止集群拓?fù)鋬?nèi)的任務(wù)；

算法1的輸入?yún)?shù)為集群拓?fù)涞娜蝿?wù)集合、時間窗口長度、數(shù)據(jù)的標(biāo)記信息、集群實際吞吐量以及集群吞吐量的閾值下限；輸出參數(shù)為判斷是否終止集群拓?fù)鋬?nèi)的任務(wù).行①②表示對集群拓?fù)鋬?nèi)的元組進(jìn)行標(biāo)記，并設(shè)置滑動時間窗口的長度；行③④表示遍歷整個集群拓?fù)鋬?nèi)的任務(wù)信息，并以心跳信息的形式返回Nimbus節(jié)點；行⑤⑥表示心跳信息轉(zhuǎn)換為集群吞吐量，并根據(jù)式(7)計算集群的實際吞吐量，以判斷拓?fù)鋬?nèi)的任務(wù)實際運行情況；行⑦～表示集群實際吞吐量與閾值下限進(jìn)行對比，共存在3種情況，當(dāng)出現(xiàn)拓?fù)鋱箦e與資源瓶頸時，終止集群拓?fù)鋬?nèi)的任務(wù)，當(dāng)集群實際吞吐量高于或等于閾值下限時，集群拓?fù)鋬?nèi)的任務(wù)正常執(zhí)行.

由算法1可知，DR-Storm首先需要確定集群是否出現(xiàn)資源瓶頸與拓?fù)鋱箦e，由此判斷是否終止集群拓?fù)鋬?nèi)的任務(wù).為滿足監(jiān)控集群拓?fù)鋬?nèi)的數(shù)據(jù)信息，需要對其元組進(jìn)行標(biāo)記，并設(shè)置滑動時間窗口，其中滑動時間窗口的取值通過式(4)(5)選擇確定.按照心跳信息的形式對主控節(jié)點進(jìn)行反饋，根據(jù)反饋結(jié)果計算集群實際吞吐量，并與集群吞吐量的閾值下限進(jìn)行對比，以此判斷集群任務(wù)處理的狀態(tài).

基于Storm的節(jié)能策略首先需要判斷是否影響集群的性能，而Storm集群默認(rèn)的輪詢調(diào)度策略，其時間復(fù)雜度為O(n).算法1首先對集群拓?fù)涞脑M進(jìn)行標(biāo)記并設(shè)置滑動時間窗口的長度，其時間復(fù)雜度為O(1)；其次算法1需要對整個集群拓?fù)鋬?nèi)的數(shù)據(jù)信息進(jìn)行遍歷，并以心跳信息的形式返回Nimbus節(jié)點，類似于輪詢調(diào)度算法，因此其時間復(fù)雜度為O(n)；最后算法1通過計算集群實際吞吐量，并與閾值下限進(jìn)行對比，確定拓?fù)鋬?nèi)的任務(wù)實際運行情況，從而判斷是否終止集群拓?fù)鋬?nèi)的任務(wù)，其時間復(fù)雜度為3O(1).則算法1的時間復(fù)雜度T(A)為

T(A)=O(1)+O(n)×3O(1)=O(n).

(28)

3.2 數(shù)據(jù)恢復(fù)算法

為滿足算法1終止任務(wù)后恢復(fù)集群拓?fù)鋬?nèi)的數(shù)據(jù)，提出數(shù)據(jù)恢復(fù)算法.該算法主要由3部分組成：1)根據(jù)工作節(jié)點的內(nèi)存資源占用率選擇備份節(jié)點，并對備份節(jié)點的內(nèi)存進(jìn)行邏輯劃分；2)備份節(jié)點存儲數(shù)據(jù)后要滿足節(jié)點資源約束；3)集群拓?fù)鋬?nèi)的數(shù)據(jù)處理完成后，實時刪除備份節(jié)點內(nèi)存儲的數(shù)據(jù).具體情況在算法2中描述.

算法2.數(shù)據(jù)恢復(fù)算法.

輸出：集群拓?fù)鋬?nèi)的任務(wù)順利執(zhí)行.

② 根據(jù)式(9)確定集群備份節(jié)點；

③ end for

⑤ 磁盤向備份節(jié)點的內(nèi)存發(fā)送數(shù)據(jù)；

⑥ 備份節(jié)點的內(nèi)存資源占用滿足式(10)；

⑦ if集群出現(xiàn)拓?fù)鋱箦ethen

⑧ 集群拓?fù)鋸膫浞莨?jié)點內(nèi)存讀取數(shù)據(jù)；

⑨ end if

⑩ if集群出現(xiàn)資源瓶頸then

算法2的輸入?yún)?shù)為節(jié)點的內(nèi)存資源占用率集合；輸出參數(shù)為集群拓?fù)鋬?nèi)的任務(wù)順利執(zhí)行.行①～③表示通過遍歷集群節(jié)點內(nèi)存資源占用選擇備份節(jié)點；行④～⑥表示邏輯分割備份節(jié)點的內(nèi)存，使磁盤向備份節(jié)點的內(nèi)存發(fā)送數(shù)據(jù)時滿足式(10)；行⑦～表示集群出現(xiàn)拓?fù)鋱箦e或資源瓶頸時，拓?fù)鋸膫浞莨?jié)點內(nèi)存讀取數(shù)據(jù)；行表示集群完成數(shù)據(jù)恢復(fù)后，根據(jù)算法1重新判斷是否出現(xiàn)拓?fù)鋱箦e或資源瓶頸；行表示實時刪除備份節(jié)點內(nèi)存儲的數(shù)據(jù)，防止因集群備份節(jié)點內(nèi)存空間不足而造成資源瓶頸的問題.

由算法2可以看出，數(shù)據(jù)恢復(fù)算法根據(jù)算法1執(zhí)行情況判斷是否對拓?fù)鋬?nèi)的數(shù)據(jù)進(jìn)行恢復(fù).數(shù)據(jù)恢復(fù)算法首先根據(jù)集群內(nèi)節(jié)點的內(nèi)存資源約束，確定備份節(jié)點用于數(shù)據(jù)存儲.其次若反饋信息顯示集群拓?fù)涑霈F(xiàn)資源溢出或拓?fù)鋱箦e，則通過備份節(jié)點內(nèi)存向集群拓?fù)渥x取數(shù)據(jù)，并將其元組重新返回算法1進(jìn)行標(biāo)記.數(shù)據(jù)恢復(fù)算法保證了可以快速恢復(fù)集群拓?fù)鋬?nèi)的數(shù)據(jù)，進(jìn)而減少集群的計算延遲.

為確定數(shù)據(jù)恢復(fù)算法對集群性能帶來的影響，現(xiàn)計算數(shù)據(jù)恢復(fù)算法的時間復(fù)雜度.1)算法2通過遍歷節(jié)點內(nèi)存資源占用率確定備份節(jié)點，其時間復(fù)雜度為O(n)；2)算法2確定備份節(jié)點的內(nèi)存滿足資源約束，其時間復(fù)雜度為O(1)；3)判斷集群是否出現(xiàn)拓?fù)鋱箦e，從而進(jìn)行數(shù)據(jù)恢復(fù)，其時間復(fù)雜度為O(1)；4)判斷集群是否出現(xiàn)資源瓶頸，從而進(jìn)行數(shù)據(jù)恢復(fù)，其時間復(fù)雜度為O(1)；此外集群完成數(shù)據(jù)恢復(fù)后，重新將任務(wù)返回算法1，其時間復(fù)雜度為O(1)；最后算法2實時刪除備份節(jié)點內(nèi)存儲的數(shù)據(jù)，其時間復(fù)雜度為O(1).則算法2的時間復(fù)雜度T(B)為

T(B)=O(n)+5O(1)=O(n).

(29)

此外，DR-Storm由算法1與算法2組成，則該策略的時間復(fù)雜度T(C)為

T(C)=O(n)+O(n)=O(n).

(30)

3.3 算法的部署與實現(xiàn)

在Storm的基本架構(gòu)中，1個完整的流式作業(yè)通常由主控節(jié)點(運行Nimbus進(jìn)程)、工作節(jié)點(運行Supervisor進(jìn)程)與關(guān)聯(lián)節(jié)點(運行Zookeeper進(jìn)程)協(xié)同完成計算.其中Nimbus進(jìn)程為Storm框架的核心，負(fù)責(zé)接受用戶提交的拓?fù)洳⑾蚬ぷ鞴?jié)點分配任務(wù)；Supervisor進(jìn)程負(fù)責(zé)監(jiān)聽Nimbus進(jìn)程分配的任務(wù)并啟動工作進(jìn)程及工作線程；Zookeeper進(jìn)程負(fù)責(zé)其他節(jié)點的分布式協(xié)調(diào)工作，并存儲整個集群的狀態(tài)信息與配置信息.為了部署與實現(xiàn)基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略，本研究在Storm原有架構(gòu)基礎(chǔ)上新增了4個模塊，如圖5所示.各模塊功能介紹如下：

1) 負(fù)載監(jiān)控器(load monitor).負(fù)責(zé)監(jiān)控集群拓?fù)湫畔?、工作?jié)點的各類資源占用信息.具體實現(xiàn)需添加在拓?fù)浣M件各Spout的open()和nextTuple()方法以及各Bolt的prepare()和execute()方法中.

2) 數(shù)據(jù)庫(database).負(fù)責(zé)收集負(fù)載監(jiān)控器發(fā)送的信息與拓?fù)淙蝿?wù)分配信息，并實時更新.

3) 滑動時間窗口模塊(slide time window module).部署算法1，通過標(biāo)記集群拓?fù)湓M，并讀取數(shù)據(jù)庫的信息，設(shè)置滑動時間窗口的長度，執(zhí)行吞吐量檢測算法.

4) 數(shù)據(jù)恢復(fù)模塊(data recovery module).部署算法2，通過算法1返回心跳信息的結(jié)果，執(zhí)行數(shù)據(jù)恢復(fù)算法.

Fig. 5 Improved architecture of Storm圖5 改進(jìn)后的Storm框架

此外，代碼編譯完成后，通過打jar包分組至主控節(jié)點Nimbus的STORM_HOMElib目錄下，并在confstorm.yaml中配置好相關(guān)參數(shù)后運行.

本文提出算法1與算法2設(shè)計并實現(xiàn)了基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略，減少了集群的計算延遲，并節(jié)約了能耗.

4 實驗結(jié)果及數(shù)據(jù)分析

為了驗證DR-Storm的計算延遲與能耗，本文通過設(shè)置對比實驗，分別將DR-Storm與原集群及其相關(guān)研究成果進(jìn)行對比.實驗選擇4組代表不同作業(yè)類型的標(biāo)準(zhǔn)Benchmark進(jìn)行測試，最后對實驗結(jié)果進(jìn)行討論與分析.

4.1 實驗環(huán)境

實驗搭建的集群由19臺同構(gòu)的PC機組成.其中Storm集群包含1個主控節(jié)點(運行Nimbus進(jìn)程、UI進(jìn)程與數(shù)據(jù)庫)、16個工作節(jié)點(運行Supervisor進(jìn)程)以及3個關(guān)聯(lián)節(jié)點(運行Zookeeper進(jìn)程).此外，集群每臺PC機的網(wǎng)卡配置為100 Mbps LAN；內(nèi)存為8 GB；硬盤容量為250 GB，轉(zhuǎn)速為7 200 rmin，接口為SATA3.0.除硬件配置外，各節(jié)點軟件配置相同，具體結(jié)果如表1與表2所示：

Table 1 Hardware Configuration of Storm Cluster表1 Storm集群的硬件參數(shù)配置

Table 2 Software Configuration of Storm Cluster表2 Storm集群的軟件參數(shù)配置

此外，為了檢驗不同基準(zhǔn)測試下節(jié)能策略的效果，實驗選取Intel公司Zhang[16]發(fā)布在GitHub上的4組Benchmark進(jìn)行測試，分別為CPU敏感型(CPU-sensitive)的WordCount、網(wǎng)絡(luò)帶寬敏感型(network-sensitive)的Sol、內(nèi)存敏感型(memory-sensitive)的RollingSort以及Storm在真實場景下的應(yīng)用RollingCount.表3為4組基準(zhǔn)測試各項參數(shù)的基本配置，部分參數(shù)需要進(jìn)一步說明如下：component.xxx_num為集群內(nèi)組件的并行度；Sol中的topology.level為集群拓?fù)涞膶哟?，由?個Spout對應(yīng)2個Bolt，因此集群拓?fù)涞膶哟卧O(shè)置為3；topology.works統(tǒng)一設(shè)置為16，表示集群內(nèi)1個工作節(jié)點內(nèi)僅分配1個工作進(jìn)程；topology.acker.executors統(tǒng)一設(shè)置為16，表示滿足集群數(shù)據(jù)流的可靠傳輸；最后統(tǒng)一設(shè)置每個message.size等于1個tuple的大小.

為對比DR-Storm的效果，本文還與LEEDSP[19]，DMM-Storm[37]進(jìn)行了對比實驗.其中LEEDSP的核心思想是彈性調(diào)節(jié)集群節(jié)點的資源，并通過DVFS技術(shù)動態(tài)調(diào)節(jié)節(jié)點CPU的電壓，以此達(dá)到節(jié)能的效果，且該策略為流式處理節(jié)能策略的主要代表，適用于大多數(shù)流式處理平臺(如Storm，Spark Streaming[11]，F(xiàn)link[12]等)；DMM-Storm的核心思想為使用DVFS降低被遷移任務(wù)后工作節(jié)點的電壓而達(dá)到節(jié)能的效果.此外DMM-Storm由關(guān)鍵線程中的數(shù)據(jù)遷移合并節(jié)能算法(energy-efficient algorithm for data migration and merging among critical executor， EDMMCE)與非關(guān)鍵線程中的數(shù)據(jù)遷移合并節(jié)能算法(energy-efficient algorithm for data migration and merging among non-critical executor， EDMMNE)組成.為保證在同等條件下驗證本文策略的有效性，LEEDSP，DMM-Storm的相關(guān)參數(shù)與DR-Storm保持一致.

Table 3 Configuration of Benchmarks表3 基準(zhǔn)測試參數(shù)配置

為選擇合適的時間窗口用于檢測集群拓?fù)鋬?nèi)數(shù)據(jù)的信息，本文以WordCount為例在集群默認(rèn)調(diào)度策略下，根據(jù)增加的網(wǎng)絡(luò)資源占用率與系統(tǒng)延遲對集群性能的影響選擇合適的時間窗口長度，具體的結(jié)果如表4所示：

Table 4 Choose of Time Windows表4 時間窗口的選擇

其中I的取值根據(jù)式(4)(5)確定.根據(jù)表4可知，當(dāng)時間窗口長度為10 s，20 s時，集群增加的網(wǎng)絡(luò)資源占用率較大，且I值較高.其原因為時間窗口取值較低而導(dǎo)致集群內(nèi)數(shù)據(jù)庫的讀寫過于頻繁，讀寫數(shù)據(jù)庫產(chǎn)生的網(wǎng)絡(luò)資源占用率相對較大，從而對集群拓?fù)鋬?nèi)的任務(wù)處理性能造成影響.當(dāng)時間窗口長度為40 s，50 s時，集群內(nèi)增加的系統(tǒng)延遲與I值較高，已影響到集群拓?fù)鋬?nèi)的任務(wù)正常執(zhí)行.其原因為集群內(nèi)數(shù)據(jù)庫的讀寫過于緩慢，影響拓?fù)鋬?nèi)數(shù)據(jù)信息的獲取時間，進(jìn)而延誤了DR-Storm的觸發(fā)時間，造成影響集群性能的問題.綜上所述，時間窗口的取值設(shè)置為30 s，在該時間窗口長度下能夠較好滿足實驗的執(zhí)行.同理可得Sol，RollingSort，Rolling-Count的時間窗口長度.

此外，為便于數(shù)據(jù)統(tǒng)計，以下測試均設(shè)置metrics.poll=5 000，metrics.time=300 000，其單位為ms，即每組實驗每5 s進(jìn)行1次采樣，時長為5 min.

4.2 工作節(jié)點的資源約束測試

為執(zhí)行DR-Storm首先需要查找集群內(nèi)的備份節(jié)點用于數(shù)據(jù)的存儲，而備份節(jié)點則需要根據(jù)集群內(nèi)工作節(jié)點的內(nèi)存資源占用情況確定.此外，為滿足集群內(nèi)的任務(wù)順利執(zhí)行，需要確定原集群內(nèi)各節(jié)點的資源占用情況.具體結(jié)果如圖6所示.

Fig. 6 Resources utilization of 16 work nodes in the original cluster圖6 原集群16個工作節(jié)點的資源占用率

圖6為集群運行4組基準(zhǔn)測試后，16個節(jié)點的平均資源占用情況.由圖6可知，運行4組基準(zhǔn)測試，集群內(nèi)工作節(jié)點的資源占用率主要集中于40%～70%，滿足集群拓?fù)鋬?nèi)的任務(wù)正常執(zhí)行.由式(9)與圖6(c)可知，不同的基準(zhǔn)測試由于其拓?fù)洳煌?，?jié)點平均內(nèi)存資源占用率的最低值也不相同.其中原集群在WordCount下，9號節(jié)點的平均內(nèi)存資源占用率最低為42.8%；原集群在Sol下，7號節(jié)點的平均內(nèi)存資源占用率最低為42.3%；原集群在Rolling-Sort下，12號節(jié)點的平均內(nèi)存資源占用率最低為44.3%；原集群在RollingCount下，15號節(jié)點的平均內(nèi)存資源占用率最低為45.7%.則根據(jù)不同的基準(zhǔn)測試，選擇平均內(nèi)存資源占用率最低的節(jié)點為備份節(jié)點.為確定備份節(jié)點的內(nèi)存進(jìn)行數(shù)據(jù)存儲后，備份節(jié)點是否滿足資源約束，具體結(jié)果在圖7顯示.

Fig. 7 Memory resources utilization after the backupnode store data圖7 備份節(jié)點存儲數(shù)據(jù)后的內(nèi)存資源占用率

圖7為集群內(nèi)備份節(jié)點存儲數(shù)據(jù)后節(jié)點的平均內(nèi)存資源占用率.根據(jù)圖7可知，集群內(nèi)4個備份節(jié)點的平均內(nèi)存資源占用率遠(yuǎn)高于原集群的相同節(jié)點，其內(nèi)存資源占用率主要集中于80%～90%.其原因為備份節(jié)點的部分內(nèi)存用于數(shù)據(jù)存儲，由于集群拓?fù)湮窗l(fā)生改變，則集群節(jié)點數(shù)據(jù)的處理未發(fā)生改變，因此備份節(jié)點的內(nèi)存資源占用率等于原節(jié)點用于數(shù)據(jù)處理的內(nèi)存資源占用率與備份節(jié)點用于數(shù)據(jù)存儲的內(nèi)存資源占用率之和，滿足式(10).

為檢測執(zhí)行DR-Storm對集群性能造成的影響，需要測試集群的平均吞吐量.現(xiàn)計算原集群出現(xiàn)資源瓶頸、拓?fù)鋱箦e與執(zhí)行DR-Storm時對集群平均吞吐量的影響，具體結(jié)果如圖8所示.

Fig. 8 Comparison of throughput under different benchmarks圖8 在不同的基準(zhǔn)測試下比較吞吐量

圖8為集群執(zhí)行3組(WordCount，Sol，Rolling-Sort)基準(zhǔn)測試后，策略對集群平均吞吐量的影響.由圖8可知，在95 s前集群的吞吐量基本相同，這是由于集群在出現(xiàn)資源瓶頸或拓?fù)鋱箦e前，未觸發(fā)DR-Storm，拓?fù)淙蝿?wù)始終執(zhí)行默認(rèn)處理機制.

在95 s左右，由于出現(xiàn)節(jié)點計算資源不足或網(wǎng)絡(luò)故障等原因，而造成資源瓶頸或拓?fù)鋱箦e的問題，其原因為節(jié)點間的數(shù)據(jù)傳輸量較大，容易導(dǎo)致集群內(nèi)網(wǎng)絡(luò)傳輸出現(xiàn)擁擠現(xiàn)象，造成節(jié)點間計算資源不足或網(wǎng)絡(luò)故障的問題.由于在95 s左右發(fā)生網(wǎng)絡(luò)擁擠現(xiàn)象，故通過執(zhí)行DR-Storm，重啟集群拓?fù)渚徑饩W(wǎng)絡(luò)傳輸壓力，解決網(wǎng)絡(luò)擁塞的問題.

集群執(zhí)行DR-Storm的平均吞吐量為68 927 tuples，70 913 tuples，51 855 tuples，相比于原集群拓?fù)鋱箦e，執(zhí)行DR-Storm時集群的平均吞吐量略高于原集群拓?fù)鋱箦e.這是由于原集群出現(xiàn)拓?fù)鋱箦e，集群拓?fù)鋸拇疟P讀取數(shù)據(jù)，而執(zhí)行DR-Storm，集群拓?fù)鋸膬?nèi)存讀取數(shù)據(jù)，數(shù)據(jù)恢復(fù)過程中的時間間隔較短，故對集群吞吐量的影響較小.相比于原集群資源瓶頸，執(zhí)行DR-Storm時集群的平均吞吐量遠(yuǎn)高于原集群資源瓶頸，這是由于原集群出現(xiàn)資源瓶頸時，節(jié)點的各類資源占用率不斷升高，集群拓?fù)涞娜蝿?wù)處理出現(xiàn)擁擠，集群默認(rèn)策略的時間復(fù)雜度不斷上升，集群拓?fù)淙蝿?wù)執(zhí)行效率不斷下降，集群的吞吐量降低，而執(zhí)行DR-Storm時，集群拓?fù)湓诮?jīng)歷短暫重啟后迅速恢復(fù)了其吞吐量.因此原集群資源瓶頸時，執(zhí)行DR-Storm的吞吐量遠(yuǎn)高于原集群.此外，集群執(zhí)行DR-Storm在95 s～115 s之間的集群吞吐量從0逐步上升，其原因為這段時間內(nèi)終止了集群拓?fù)鋬?nèi)的任務(wù)，并從備份節(jié)點內(nèi)存重新讀取任務(wù)，但是由于從內(nèi)存讀取數(shù)據(jù)時間間隔相對較短，因此對集群整體性能的影響較小.

4.3 節(jié)能策略的實驗結(jié)果與分析

針對DR-Storm的效果可通過系統(tǒng)延遲與能耗2個標(biāo)準(zhǔn)進(jìn)行評估.

1) 系統(tǒng)延遲

系統(tǒng)延遲是評估策略是否影響集群性能的重要指標(biāo)之一，本文根據(jù)式(16)(18)(20)對單位時間內(nèi)集群拓?fù)淙蝿?wù)處理的延遲進(jìn)行計算，具體結(jié)果如圖9所示.此外還可通過Storm框架自身提供的Storm UI[8]進(jìn)行統(tǒng)計.

Fig. 9 Comparison of system latency under different benchmarks圖9 在不同的基準(zhǔn)測試下比較系統(tǒng)的延遲

圖9為在各基準(zhǔn)測試(WordCount,Sol,Rolling-Sort)下，單位時間內(nèi)集群拓?fù)淙蝿?wù)處理的延遲.由圖9可知，95 s前DR-Storm與原集群拓?fù)淙蝿?wù)處理的延遲基本相同，這是由于集群拓?fù)湓谶@段時間內(nèi)進(jìn)行任務(wù)部署，且集群并未觸發(fā)資源瓶頸與拓?fù)鋱箦e.95s后觸發(fā)資源瓶頸與拓?fù)鋱箦e，集群執(zhí)行DR-Storm的平均延遲為660.2 ms，256.2 ms，143.9 ms，相比于原集群出現(xiàn)資源瓶頸其延遲降低了69.7%，67.9%，69.6%.這是由于原集群出現(xiàn)資源瓶頸各節(jié)點的計算資源不足，致使拓?fù)鋬?nèi)的任務(wù)處理速度受到影響，故集群計算資源越來越接近溢出導(dǎo)致系統(tǒng)延遲不斷上升，集群于95 s～125 s內(nèi)，共耗時約30 s，執(zhí)行DR-Storm，使集群延遲在140 s后逐步趨于穩(wěn)定，最終導(dǎo)致執(zhí)行DR-Storm的計算延遲遠(yuǎn)低于原集群.此外，集群執(zhí)行DR-Storm存在1個峰值，這是由于執(zhí)行策略在95 s左右終止了集群拓?fù)鋬?nèi)的任務(wù)，并通過備份節(jié)點的內(nèi)存對拓?fù)鋬?nèi)的任務(wù)進(jìn)行重新部署，但由于時間間隔較短，因此對整個集群拓?fù)鋬?nèi)的任務(wù)處理影響較小.相比于原集群出現(xiàn)拓?fù)鋱箦e其延遲降低了31.4%，27.5%，22.3%，其原因為雖然原集群出現(xiàn)拓?fù)鋱箦e延遲趨于穩(wěn)定后與執(zhí)行DR-Storm基本相同，但由于原集群在終止任務(wù)后從磁盤對拓?fù)鋬?nèi)的任務(wù)進(jìn)行部署，時間間隔為95 s～155 s，共耗時約60 s，且存在峰值為3 821 ms，1 342 ms，763 ms，嚴(yán)重影響了集群拓?fù)淙蝿?wù)的正常處理，因此DR-Storm的效果優(yōu)于原集群.此外3組基準(zhǔn)測試的延遲并不相同，這是由于不同基準(zhǔn)測試的拓?fù)洳⒉幌嗤?，且?jié)點內(nèi)的線程數(shù)量也不相同，但并不影響集群拓?fù)淙蝿?wù)的執(zhí)行結(jié)果.圖10為集群在實際應(yīng)用場景下拓?fù)淙蝿?wù)處理的延遲.

Fig. 10 Comparison of system latency under the RollingCount圖10 在RollingCount下比較系統(tǒng)的延遲

如圖10所示，集群在RollingCount下執(zhí)行DR-Storm的平均延遲為497.2 ms，相比于原集群出現(xiàn)資源瓶頸與拓?fù)鋱箦e其延遲降低了72.4%，26.7%，因此與原集群相比，執(zhí)行DR-Storm具有更好的集群性能.

2) 集群能耗

集群能耗是反映節(jié)能策略效果的重要指標(biāo)之一，本文通過拓?fù)鋱?zhí)行任務(wù)的功率與時間相乘計算集群的能耗，并根據(jù)式(27)計算執(zhí)行DR-Storm相比于原集群節(jié)約的能耗.此外引入LEEDSP，DMM-Storm與DR-Storm作對比，以驗證DR-Storm的實際效果.為計算集群能耗需要統(tǒng)計單位時間內(nèi)集群執(zhí)行不同策略的功率，具體結(jié)果如圖11所示：

Fig. 11 Comparison of power on RollingCount among different strategies圖11 RollingCount在不同策略下的功率對比

圖11為在RollingCount下集群執(zhí)行不同策略的功率對比.根據(jù)圖11可知，集群執(zhí)行DR-Storm的平均功率為1 073.34 W；原集群出現(xiàn)拓?fù)鋱箦e與資源瓶頸的平均功率分別為1 103.69 W，1 244.01 W；執(zhí)行LEEDSP拓?fù)鋱箦e與資源瓶頸的平均功率分別為1 070.43 W，1 207.03 W；執(zhí)行EDMMNE拓?fù)鋱箦e與資源瓶頸的平均功率分別為984.89 W，1 268.70 W；執(zhí)行EDMMCE拓?fù)鋱箦e與資源瓶頸的平均功率分別為1 004.97 W，1 274.21 W.

根據(jù)11(a)可知，執(zhí)行DR-Storm相比于原集群的功率降低了2.7%，13.7%，且在95 s前原集群與DR-Storm的功率基本相等.這是由于95 s前并未出現(xiàn)拓?fù)鋱箦e與資源瓶頸，DR-Storm尚未觸發(fā).95 s后集群功率波動較大，其原因為在95s后集群出現(xiàn)拓?fù)鋱箦e與資源瓶頸，執(zhí)行DR-Storm拓?fù)浣K止任務(wù)后，從備份節(jié)點內(nèi)存讀取數(shù)據(jù).原集群出現(xiàn)拓?fù)鋱箦e終止任務(wù)后，從磁盤讀取數(shù)據(jù)，而從內(nèi)存讀取數(shù)據(jù)消耗的功率小于磁盤內(nèi)讀取數(shù)據(jù)，故集群功率趨于穩(wěn)定后執(zhí)行DR-Storm的功率略低于原集群出現(xiàn)拓?fù)鋱箦e.原集群出現(xiàn)資源瓶頸，節(jié)點的資源占用持續(xù)上升，導(dǎo)致集群的功率不斷升高，因此原集群出現(xiàn)資源瓶頸的功率遠(yuǎn)高于DR-Storm.

根據(jù)11(b)可知，DR-Storm，LEEDSP出現(xiàn)拓?fù)鋱箦e的功率接近，低于LEEDSP出現(xiàn)資源瓶頸的功率，其原因為當(dāng)集群出現(xiàn)資源瓶頸時，LEEDSP無法進(jìn)行資源調(diào)度，節(jié)能策略失效，故與原集群出現(xiàn)資源瓶頸相同，節(jié)點的功率迅速上升.此外，雖然LEEDSP出現(xiàn)拓?fù)鋱箦e與DR-Storm的功率接近，但由于LEEDSP進(jìn)行資源調(diào)度，集群功率存在1個峰值，影響集群拓?fù)淙蝿?wù)的正常執(zhí)行，且LEEDSP由于使用DVFS技術(shù)調(diào)節(jié)節(jié)點電壓，集群節(jié)點的功率波動較大，非常不穩(wěn)定，不適合部署在大規(guī)模的集群當(dāng)中.

根據(jù)11(c)可知，DR-Storm的功率高于DMM-Storm出現(xiàn)拓?fù)鋱箦e，低于DMM-Storm出現(xiàn)資源瓶頸的功率，這是由于當(dāng)集群節(jié)點出現(xiàn)資源瓶頸時，集群節(jié)點內(nèi)的任務(wù)無法正常進(jìn)行遷移，故DMM-Storm失效，集群節(jié)點功率急速上升.雖然集群出現(xiàn)拓?fù)鋱箦e時，DMM-Storm的功率低于DR-Storm，但DMM-Storm的功率因任務(wù)遷移同樣存在峰值，影響集群拓?fù)淙蝿?wù)的正常執(zhí)行.此外當(dāng)出現(xiàn)資源瓶頸時，DMM-Storm完全失效，存在一定的缺陷，且DVFS的實現(xiàn)較為困難，因此同樣不適合部署在大規(guī)模的集群當(dāng)中.為計算集群的能耗，需要對集群內(nèi)的功率進(jìn)行累加求和，具體結(jié)果如圖12所示：

Fig.12 Comparison of energy consumption on RollingCount among different strategies圖12 RollingCount在不同策略下的能耗對比

圖12為在RollingCount下集群執(zhí)行不同策略的能耗對比.根據(jù)圖12可知，集群在單位時間內(nèi)執(zhí)行DR-Storm的能耗為4.50 MJ；原集群拓?fù)鋱箦e與資源瓶頸的能耗為5.07 MJ，9.79 MJ；執(zhí)行LEEDSP拓?fù)鋱箦e與資源瓶頸的能耗分別為4.62 MJ，9.73 MJ；執(zhí)行EDMMNE拓?fù)鋱箦e與資源瓶頸的能耗分別為4.03 MJ，10.22 MJ；執(zhí)行EDMMCE拓?fù)鋱箦e與資源瓶頸的能耗分別為4.18 MJ，10.22 MJ.

圖12(a)為集群出現(xiàn)拓?fù)鋱箦e后不同策略的能耗對比，與原集群相比，執(zhí)行DR-Storm的能耗降低了11.2%，但是在95 s～135 s內(nèi)，DR-Storm的能耗在所有策略當(dāng)中最高，這是由于執(zhí)行數(shù)據(jù)恢復(fù)算法，集群拓?fù)鋬?nèi)的數(shù)據(jù)從備份節(jié)點內(nèi)存中讀取，且拓?fù)鋬?nèi)的數(shù)據(jù)恢復(fù)時間較快，故集群節(jié)點的功率未下降至最低值，其他策略通過磁盤恢復(fù)集群拓?fù)鋬?nèi)的數(shù)據(jù)，拓?fù)鋬?nèi)的數(shù)據(jù)恢復(fù)時間較慢，集群內(nèi)的功率降低至最低值，因此其他策略(包括原集群)在這段時間內(nèi)的能耗低于DR-Storm.135 s后，執(zhí)行DR-Storm的能耗趨于穩(wěn)定，對于集群拓?fù)淙蝿?wù)的整體處理影響較小.LEEDSP，DR-Storm的能耗接近，而DMM-Storm的能耗低于DR-Storm，但是由于LEEDSP，DMM-Storm都是使用DVFS技術(shù)進(jìn)行電壓調(diào)節(jié)，功率的獲取存在較大的偶然性且容易對集群拓?fù)淙蝿?wù)的正常執(zhí)行帶來影響(LEEDSP容易帶來拓?fù)淙蝿?wù)處理出現(xiàn)失衡的問題，DMM-Storm容易影響集群拓?fù)淙蝿?wù)處理性能的問題)，進(jìn)而影響節(jié)能策略的實際效果.

圖12(b)為集群出現(xiàn)資源瓶頸后不同策略的能耗對比，與原集群相比，執(zhí)行DR-Storm的能耗降低了54.1%，這是由于隨著集群內(nèi)節(jié)點資源占用的不足，節(jié)點的功率持續(xù)上升，導(dǎo)致集群的能耗不斷增大.LEEDSP，DMM-Storm都是對資源遷移后的節(jié)點進(jìn)行電壓縮放管理，但由于節(jié)點的資源占用已達(dá)到瓶頸，無法進(jìn)行資源的遷移，故節(jié)能策略失效，集群還是按照系統(tǒng)默認(rèn)機制進(jìn)行任務(wù)的處理，與原集群的能耗基本相等.

此外，根據(jù)集群內(nèi)功率與系統(tǒng)延遲的降低情況可以確定，當(dāng)集群出現(xiàn)資源瓶頸時，執(zhí)行DR-Storm的系統(tǒng)延遲每降低72.4%，功率下降13.7%，則集群的能耗節(jié)約54.1%；當(dāng)集群出現(xiàn)拓?fù)鋱箦e時，執(zhí)行DR-Storm的系統(tǒng)延遲每降低26.7%，功率下降2.7%，則集群的能耗節(jié)約11.2%.因此，相比于原集群，本文提出的DR-Storm具有更好的節(jié)能效果.

5 總結(jié)與展望

高能耗問題已經(jīng)成為制約綠色流式計算平臺發(fā)展的主要障礙之一，Storm作為最受企業(yè)界與學(xué)術(shù)界追捧的大數(shù)據(jù)流式計算平臺之一，在最初設(shè)計時并未考慮高能耗的問題，以至于影響平臺其他領(lǐng)域的發(fā)展.針對這一問題，本文通過研究Storm的框架結(jié)構(gòu)與拓?fù)溥壿?，建立了任?wù)分配模型、拓?fù)湫畔⒈O(jiān)控模型、數(shù)據(jù)恢復(fù)模型以及能耗模型，并進(jìn)一步提出了基于Storm平臺的數(shù)據(jù)恢復(fù)節(jié)能策略，該策略由吞吐量檢測算法與數(shù)據(jù)恢復(fù)算法組成，在減少系統(tǒng)計算延遲的前提下，降低了集群的功率，并節(jié)約了能耗.最后，實驗通過4組基準(zhǔn)測試從資源占用、吞吐量、系統(tǒng)延遲與能耗的角度驗證了策略的效果.

下一步的研究工作主要包括3個方面：

1) 將DR-Storm部署到更為復(fù)雜的商業(yè)環(huán)境，使其具有更為廣闊的應(yīng)用場景.

2) 與其他節(jié)能策略融合使用，達(dá)到雙重的節(jié)能效果.

3) 替換高能效的電子元件，在滿足節(jié)能的前提下，提高集群的性能.