Storm 平臺下的線程重分配與數據遷移節能策略?

蒲勇霖 ,于 炯 ,魯 亮 ,李梓楊 ,卞 琛 ,廖 彬

1(新疆大學 信息科學與工程學院,新疆 烏魯木齊 830046)

2(中國民航大學 計算機科學與技術學院,天津 300300)

3(廣東金融學院 互聯網金融與信息工程學院,廣東 廣州 510521)

4(新疆財經大學 統計與數據科學學院,新疆 烏魯木齊 830012)

目前,隨著互聯網的高速發展與平民化,智能醫療、智能汽車、智能家居以及智能工業等物聯網場景[1]下產生的數據量日益增多,并與互聯網共同成為了各行各業大數據的主要來源.但是隨著大數據的飛速發展,大規模的數據中心在全球范圍內廣泛的部署,使其高能耗、高污染的問題日漸突出[2].據2014 年數據中心能耗現狀白皮書指出:全球數據中心2013 年的耗電量為8 102.5 億kWh,其中IT 設備與軟件的能耗占數據中心總能耗的45.5%[3].而到2015 年,Gartner 統計全球大型數據中心的電費支出超過1 262 億美元[4].我國數據中心電力的消耗同樣驚人,截止到2011 年底,我國數據中心的總量達到43 萬個,其中數據中心的耗電量,占據全國電力總消耗的1.5%,并且所占比例仍在逐年上升[5].綜上所述,解決大數據處理的高能耗問題已經刻不容緩.

希捷(Seagate)公司與IDC 聯合發布的《數據時代2025》白皮書中預測:2025 年,全球數據量將達到163ZB,比2016 年創造出的數據量增加10 倍.其中,超過25%的數據將成為實時數據,而物聯網實時數據占比將達到實時數據的95%[6].針對大數據處理的高性能集群一般分為批量計算框架與流計算框架兩類,其中,批量計算框架由于存在先存儲后計算的特性,無法滿足實時數據的處理需求;而流計算框架由于其強大的實時性,為實時大數據分析提供了良好的平臺層解決方案.但是流式計算在高速處理實時數據的同時伴隨著高能耗的問題[7],已經給產業界帶來了巨大的能耗開銷.特別在2017 年后,針對大數據流式處理節能計算的研究[8]已經逐漸增多,其研究價值已被廣大的科研人員認可.因此,大數據流式處理節能計算不僅減少了能源消耗保護環境,而且具有廣闊的研究價值與應用前景.

目前,主流IT 企業(如華為、百度以及小米等)針對大數據流式處理的業務主要以Apache Storm 框架[9]為主.雖然主流IT 企業的部分流式處理業務已被遷移至Flink[10]、Spark Streaming[11]和Heron[12]等框架,但其核心的流式處理業務還是基于Storm 完成的.這是由于與目前主流的Flink 與后起之秀Heron 相比,Storm 具有更成熟的平臺架構和更廣泛的產業基礎;與屬于微批的框架Spark Streaming 相比,Storm 具有更好地實時性;與不開源的Puma[13]以及社區冷淡的S4[14]相比,Storm 具有更廣闊的發展前景.此外,Storm 為適應業界的需求而不斷更新其版本,展現出強大的生命力.Storm 是一個主從式架構、開源、橫向擴展性良好且容錯能力強的分布式實時處理平臺,其編程模型簡單,支持包含Java 在內的多種編程語言,且數據處理高效.目前,Storm 已經廣泛運用到銀行金融[15]、臨床醫療[16]、社交網絡[17]等行業進行實時大數據分析,并廣泛運用到機器學習算法、分布式遠程調用等領域進行理論研究[18].Storm 因其廣泛的業界認可度,而被譽為“實時處理領域的Hadoop”.

在Storm 集群中,通常使用有向無環圖(directed acyclic graph,簡稱DAG)表示一個流式作業(拓撲)內數據的相互關聯性,其中,DAG 的頂點表示工作線程及數據的處理,DAG 的邊表示數據的相互依存性及頂點間的通信.Storm 集群采用輪詢調度策略(round-robin,簡稱RR),并將DAG 中的任務平均分配到各工作節點之中.然而,Storm 的發展也面臨著一定的挑戰.首先,Storm 通過RR 將任務均勻分配到各節點中,但是不同的任務對于節點計算資源的需求有所差異,如果節點的計算資源無法滿足任務的需求,則會導致節點資源溢出與集群計算延遲升高的問題,進而影響集群的性能,并產生高能耗的問題.因此,通過研究任務調度優化策略從而最大化利用Storm 集群的實時計算能力,是目前亟待解決的問題.其次大多數任務調度優化策略主要通過遷移計算負載來提高集群性能,但是無法對降低流式處理的高能耗帶來幫助.因此,本文通過降低集群節點間的通信開銷,在減少集群計算延遲的基礎上,有效節約了能耗.

本文針對上述問題,其主要工作如下.

(1) 通過研究Storm 集群的拓撲(topology)結構,建立DAG、線程內的數據分配與路徑開銷這3 個基本模型,從邏輯上將Storm 集群的拓撲運行情況與數據分配策略表示出來,為尋找最優的數據遷移方式創造了條件,并為節能策略的提出奠定了理論基礎.

(2) 根據3 個基本邏輯模型以及集群內數據的傳輸及處理情況,建立了資源約束模型,通過3 個條件證明了資源約束模型的必要性,并進一步建立最優線程重分配模型,其中,線程的最優分配由資源約束模型、通信成本、RR 與CPU 優先級決定.在滿足資源約束的條件下,實現了數據的遷移.

(3) 通過對集群內的數據進行分析,根據資源約束模型與最優線程重分配模型,提出了Storm 平臺下的線程重分配與數據遷移節能策略(energy-efficient strategy based on executor reallocation and data migration in Storm,簡稱ERDM),該策略包括資源約束算法與數據遷移算法,其中,資源約束算法根據節點資源約束判斷工作節點是否允許數據遷移;數據遷移算法根據資源約束模型和最優線程重新分配模型,確定了集群中數據的遷移情況.此外,實驗通過4 組基準測試[19],從不同角度驗證了算法的有效性.

本文第1 節針對目前國內外節能計算的相關研究進行總結與分析.第2 節對Storm 平臺進行建模并給出相關定義.第3 節詳細介紹ERDM 的算法并建立能耗模型.第4 節進行實驗對比并對實驗結果進行分析.第5 節對本文進行總結并對下一步工作進行展望.

1 相關工作

傳統的大數據平臺一直專注于延遲、容錯性以及彈性計算等方面,但是隨著IT 行業能耗的不斷增加,高能耗以及散熱問題已經開始制約大數據平臺性能的進一步發展.因此,大數據平臺的發展目標已經逐步轉移到功耗與能效方面.目前,用于大數據流處理平臺的節能策略主要集中在硬件[20]與軟件[21]兩個方面.

硬件的節能策略主要體現在替換高能耗的電子元件[22]與對集群電源電壓進行縮放管理[23],以達到節能的效果.該方法節能效果顯著且操作簡單,但其價格高昂不適合部署于大規模的集群當中.Wang 等人[24]使用了動態電壓頻率縮放技術(dynamic voltage frequency scaling,簡稱DVFS),通過動態管理集群節點CPU 的電壓,以實現節能的目的.Pietri 等人[25]通過將流式處理平臺的部分CPU 替換成GPU,使得CPU 與GPU 進行混合,從而減少了集群處理圖數據的能耗.實驗結果表明,在節約9.69%能耗的前提下,減少了8.63%訪問時間.文獻[26?28]通過替換高能耗的電子元件,從而提高了集群的能效,以達到節能的目的.軟件的節能策略主要體現在建立能耗模型[29]以及通過資源調度[30]提高集群的能效,以達到節能的效果.Cordeschi 等人[31]從虛擬化數據中心(virtualized networked data center,簡稱VNetDC)的角度出發,提出一種在SaaS 模型下,針對實時處理應用的最小化能耗調度策略.該研究針對流式大數據傳輸不穩定、不可控以及實時數據量大等特性,在不影響響應時間約束條件的前提下,計算了最小化網絡傳輸的總能耗.Cheng 等人[8]從流計算平臺的本質出發,提出一種基于Spark Streaming自適應調度作業的節能策略.該策略通過在集群中構建一個實時能耗分析模型,并對數據流信息進行實時的捕捉分析,根據分析結果對數據進行預處理,以此提高了集群性能并減少了部分時間開銷,達到了節能的效果.文獻[32]提出一種作用于Spark Streaming 的能耗分析基準測試方法,該方法通過使用機器學習算法,查找集群內數據流的大小與通信開銷的平衡.實驗結果表明,當集群內數據流的大小與通信開銷達到平衡時,集群執行任務的功耗最小.Maroulis 等人[33]根據分析Spark Streaming 在執行任務時性能與能耗的權衡,提出一種基于調度工作負載的高效節能策略.該策略通過建立時間序列預測模型來捕獲任務的執行時間與能耗,并通過使用DVFS技術來將集群的能耗降至最低.Veiga 等人[34]設計了一種作用于Flink 的能耗評估工具,該工具通過分析集群執行任務的工作負載,以找到不同條件下的集群能耗,為后期設計基于Flink 的節能策略奠定了基礎.文獻[35]提出一種可同時兼顧低延遲與低能耗的彈性數據流處理策略(keep calm and react with foresight:strategies for lowlatency and energy-efficient elastic data stream processing,簡稱LEEDSP),該策略通過使用DVFS 技術,建立了一種彈性自適應性的能耗感知模型.該模型通過合理分配集群資源,在提高集群的吞吐量的同時,減少任務執行的延遲,以此節約了集群的能耗.

文獻[7]提出一種流式大數據處理環境下的實時資源調度節能策略(re-stream),該策略通過構建CPU 利用率、響應時間以及能耗間的數學關系,以此獲得了滿足高能效與低響應時間的條件,從而實現了節能的目的.然而,該節能策略仍存在以下兩點值得討論:(1) 該策略僅考慮集群CPU 的能耗問題,但對于集群其他電子元件的能耗并未做敘述;(2) 該策略僅使用自己定義的拓撲,并非公認的測試數據集.此外,除了集群自身算法,并未作其他對比實驗,因此節能策略缺乏一定的通用性.

文獻[36]針對Storm 在遭遇資源瓶頸與網絡報錯時,缺乏合理應對手段,提出了基于數據恢復的節能策略.該策略通過監控集群拓撲內任務的執行吞吐量,判斷任務的實際運行情況,確定是否終止集群內的任務,并根據數據恢復模型還原集群內的數據.該策略不僅有效降低了集群因資源瓶頸與網絡報錯而帶來的額外資源與能耗的開銷,而且提高了集群任務處理的性能.此外,該策略具有兩個明顯的優點:(1) 從內存重新恢復讀取數據,有效地避免了從磁盤讀取數據資源與能耗的峰值問題;(2) 該策略可以與其他節能策略進行融合,達到雙重節能的效果.但也存在集群未發生資源瓶頸與網絡報錯,導致節能策略失效的問題.

文獻[37]根據Storm 平臺在進行數據處理時存在高能耗的問題,提出了工作節點內存電壓調控節能策略(energy-efficient strategy for work node by DRAM voltage regulation in Storm,簡稱WNDVR-Storm).該策略通過對集群內的數據流設置閾值,從而對集群工作節點數據處理能力進行判別,動態調節工作節點的內存電壓,以達到節能的目的.該節能策略不僅有效降低了集群的能耗,而且在一定程度上對集群的負載均衡進行了優化,但是還存在以下兩點不足:(1) 動態調節工作節點的內存電壓存在一定的偶然性,且實現難度較高;(2) 若集群規模較大且工作節點過多,存在節能算法失效的可能.

與已有成果相比,本文的不同之處在于.

(1) 文獻[8,31?35]均是從集群整體的特性進行分析,并未細化各部件對集群的影響,如網絡帶寬、CPU 等部件對集群的影響.本文從網絡帶寬、CPU 以及內存這3 個方面進行分析建模,確定因數據遷移而對集群各部件造成的影響,從而確保在不同場景下均能使節能策略順利執行.

(2) 文獻[7]通過對集群進行任務遷移調度而達到節能的效果,但并未考慮因任務遷移調度而帶來各工作節點計算資源不足的問題,存在資源溢出的風險.本文通過建立資源約束模型,預防了集群數據處理的資源溢出問題.

(3) 文獻[37]通過對工作節點的內存電壓進行動態調節而達到了節能的效果,但是動態調節工作節點的內存電壓存在較大誤差,且會對集群性能造成一定的影響.本文由于是軟件方面的節能策略,因此不存在動態調壓的問題.此外,本文通過數據遷移算法減少了節點間的通信開銷,在降低集群計算延遲的前提下節約了能耗.

(4) 實驗選取Intel 公司Zhang 等人[19]發布在GitHub 上的Storm-benchmark-master 基準測試,而非已有文獻中作者自己定義的拓撲結構,因此更具有通用性.此外,將ERDM 與大數據流式計算框架Storm 的任務遷移策略(task migration strategy in big data stream computing with Storm,簡稱TMSH-Storm)[18]、LEEDSP[35]以及WNDVR-Storm[37]進行對比,驗證了策略的有效性.

2 問題建模與分析

為了確定Storm 集群默認調度策略的能耗問題,建立了DAG、線程內數據分配與路徑開銷這3 個基本模型,并進一步設計了資源約束模型、最優線程重分配模型與數據遷移模型,為節能策略的設計與實現提供了理論依據.

2.1 基礎邏輯模型

在流式處理中,通常用數據流圖處理多個連續并行的任務,將其表示為DAG.則在Storm 集群中的流式作業可用定義1 表示.

定義1(DAG).在Storm 集群中,每個流應用程序的邏輯通常由DAG[7]描述,而DAG 由頂點與邊構成.則令DAG=(C(G),B(G)),其中,C(G)={c1,c2,…,cn}表示由n個組件(component)構成的集合,包括數據源編程單元(spout)與數據處理編程單元(bolt)兩類;B(G)={b1,2,b1,3,…,bn?1,n}為有向邊的集合,表示各組件間的數據傳輸鏈路.如果?bi,j∈B(G)且i≠j,則ci,cj∈C(G)表示數據從ci發出由cj接收.則組件與有向邊的對應關系可通過圖1 表示.

Fig.1 A logical DAG of a stream application圖1 流應用的邏輯DAG

為提高Storm 集群的執行效率,需要滿足同一時刻執行多個組件,即?cj∈C(G),E(C)={ej1,ej2,…,ejn}.其中,每個元素eji為一個線程(executor),且eji表示組件cj運行第i個線程.圖2 為Storm 集群數據處理及傳輸示意圖,由11 個線程與20 條有向邊組成.其中,{ea,eb,…,ei}為線程集合,且線程ea與eb通過拓撲鏈路發送數據,而后續線程接收上游線程發送的數據.以此類推,完成整個拓撲.

Fig.2 Data processing and transmission in Storm cluster圖2 Storm 集群數據處理及傳輸

此外,令線程ea為線程{ec,ed1,ed2}的父線程,則線程{ec,ed1,ed2}是線程ea的子線程.線程eb為線程{ed1,ed2,ee}的父線程,則線程{ed1,ed2,ee}是線程eb的子線程.以此類推,完成父線程與子線程間的對應關系.

定義2(線程內的數據分配).令N(C)={n1,n2,…,nm}為集群工作節點集合,且每個工作節點內存在多個線程,由定義1 可知,工作節點的數據均勻分配到集群的線程上.記工作節點分配給線程eji的數據為dji(若線程的并行度為1,則該線程上的數據為dj),則集合Dn={dj1,dj2,…,djn}表示工作節點分配到線程上的數據集合.圖3 為線程內數據的分配示意圖,由3 個節點與11 個線程組成.其中,N={n1,n2,n3}表示工作節點的集合,而線程內的數據為

此外,為消除節點內部進程間通信開銷,圖3 為各工作節點僅分配一個工作進程(worker),因此,拓撲中的通信開銷可分為兩類:一類為類似于數據dd1與數據df1之間的節點內部線程間通信;一類為類似于數據dd2與數據df1之間的節點間通信.無論集群拓撲內如何傳輸數據,凡存在直接對應關系,都符合上述傳輸方式.

定義3(路徑開銷).令集合B(p(eji,emn))存在一條子路徑p(eji,emn),表示從頂點eji開始到頂點emn結束.則需要滿足的條件為:如果?k,則bj,k∈p(eji,emn),bk,i∈p(eji,emn).由此,對于?bj,i∈p(eji,emn)都存在.此外,對于?bk,l∈p(eji,emn),如果k≠j,則?m與bm,k∈p(eji,emn);如果i≠j,則?m與bl,m∈p(eji,emn).

Fig.3 Allocation of data in executor圖3 線程內的數據分配

路徑開銷lp(eji,emn)表示從頂點eji到頂點emn內所有線程與有向邊的開銷之和,則

令整個拓撲存在n條路徑,則拓撲執行關鍵路徑l(Gp)為

此外,根據工作節點是否位于關鍵路徑上,將工作節點分為關鍵節點與非關鍵節點;根據線程是否位于關鍵節點,將線程分為關鍵節點上的線程與非關鍵節點上線程,簡稱關鍵線程與非關鍵線程.

以圖4 為例,定義一條拓撲執行關鍵路徑為ea→ed1→ef2→eh,則工作節點n1與n2為關鍵節點,工作節點n3為非關鍵節點.

Fig.4 Topology execution of critical path data transmission and processing圖4 拓撲執行關鍵路徑的數據傳輸及處理

2.2 資源約束模型

定義4(資源約束).為滿足Storm集群進行數據遷移時各工作節點的資源需求,需設置工作節點計算資源集合為,則工作節點CPU、內存以及網絡帶寬這3 類計算資源占用的極限為其中,表示工作節點CPU 資源占用率的極限為表示工作節點內存資源占用率的極限為表示工作節點網絡帶寬資源占用率的極限為.若線程所在工作節點的CPU 資源占用率為(單位%),內存資源占用率為(單位%),網絡帶寬資源占用率為(單位%),由于Storm 集群拓撲一旦提交數據將源源不斷產生,且持續運行下去,因此為確保集群的高效運行,且工作節點的資源不會溢出,這3 類資源需要滿足如下條件:

為保證集群拓撲能夠正常運行,則集群工作節點各類計算資源需要滿足資源約束.本文將滿足工作節點CPU 的正常計算稱為符合CPU 資源臨界原則,將滿足工作節點內存的正常計算稱為符合內存資源臨界原則,將滿足工作節點網絡帶寬的正常傳輸稱為符合網絡帶寬資源臨界原則.此外,具體結果在第4.2 節體現.

定理1.當集群準備進行數據遷移時,判斷被選中節點資源是否滿足CPU 資源臨界原則、內存資源臨界原則以及網絡帶寬資源臨界原則:若滿足,則允許節點遷入數據.即,數據遷入原則tr 需要滿足如下條件:

證明:根據定義4 可知,當節點遷入數據后,該工作節點CPU 的計算資源占用率小于極限值時,工作節點的CPU 可以正常計算.則稱滿足CPU 資源臨界原則,即

由于當流式處理集群執行任務時,拓撲一旦提交將持續運行下去,即

同理可得,滿足內存資源臨界原則,即

同理可得,滿足網絡帶寬資源臨界原則,即

僅符合以上3 條原則,允許節點遷入數據,即得到定理1.□

2.3 最優線程重分配模型

根據第2.1 節與第2.2 節建立最優線程重分配模型,該模型通過定義3 與定義4 確定非關線程的分配情況,并生成新的拓撲路徑,為建立數據遷移模型做鋪墊.

根據定義3 可知,集群內的工作節點包括關鍵節點與非關鍵節點兩類,集群內的線程包括關鍵線程與非關鍵線程兩類,而集群拓撲內的通信開銷由節點間通信開銷、節點內部進程間通信開銷與節點內部線程間的通信開銷這3 部分組成.

定義5(最優線程重分配).現對非關鍵線程進行重分配,首先需要考慮集群內工作節點的資源占用率,在滿足資源約束的條件下,為減少節點間的通信開銷,需要將非關鍵線程重新分配到運行其父線程的關鍵節點上.此外,在進行非關鍵線程重新分配時,除了需要滿足資源約束模型,還需要防止非關鍵線程分配出現扎堆現象.其原因為線程在進行重分配時,一般傾向于往通信開銷較小的節點分配.由于上游非關鍵線程已經進行重分配,則下游非關鍵線程優先考慮分配到上游非關鍵線程所在的關鍵節點上.為避免上述情況,故非關鍵線程重分配需要加入RR 與CPU 優先級(工作節點中CPU 的利用率最低)兩個限制條件.

如果一個非關鍵子線程僅存在一個關鍵父線程,則將非關鍵子線程重新分配到運行其關鍵父線程的關鍵節點上;如果一個非關鍵子線程存在兩個或多個關鍵父線程,則為防止扎堆現象的出現,首先需要考慮RR,在滿足RR 的條件下,優先將非關鍵子線程重新分配到CPU 利用率最低的關鍵父線程所在的關鍵節點上;如果運行父線程的關鍵節點的資源利用率達到極限,則同樣為防止扎堆現象的出現,在滿足RR 的條件下,優先將非關鍵子線程重新分配到CPU 利用率最低的關鍵節點上.

以圖4 為例,n1與n2為關鍵節點,n3為非關鍵節點,且n1存在3 個線程,n2存在4 個線程,則非關鍵子線程ec被分配到n1,而非關鍵子線程ei被分配到n1,即

如果n1與n2內的線程數量相等,且n1的CPU 占用率高于n2,則非關鍵子線程ei被分配到n2,即

如果n1的資源占用率已達到極限,則非關鍵子線程ec在滿足RR 與CPU 優先級的前提下分配到關鍵節點ni,即

此外,選擇CPU 優先級為評判指標,是由于CPU 的利用率對集群的性能影響最大.

2.4 數據遷移模型

根據第2.3 節可知,集群已生成新的拓撲路徑.現通過最優線程重分配模型建立數據遷移模型,將原非關鍵線程上的數據遷移到對應的關鍵線程中.

若父線程eab傳輸給非關鍵子線程eji數據的大小為dji,在完成非關鍵子線程重分配后,父線程對子線程的數據分配發生改變,類似數據流dji從eji遷移到e′ji,即

根據定義4 可知,數據遷入存在資源約束的問題,需要滿足數據遷入原則tr,即

定理2.根據定義3 可知,原集群的路徑成本為Wcost,數據遷移完成后集群的路徑成本為Wc′ost,則

證明:根據定義3 可知,集群的路徑成本由節點間通信開銷、節點內部進程間通信開銷、節點內部線程間的通信開銷與線程的計算開銷這4 部分組成.其中,節點間通信開銷為;節點內部線程間的通信開銷為;線程的計算開銷為;由于每個節點僅分配一個進程,則節點內部進程間的通信開銷為0.令節點間存在n條路徑,節點內部線程間存在m條路徑.集群拓撲數據遷移完成后,共有s條節點間路徑發生改變,其中有d條節點間路徑變為節點內部線程間路徑,有c條節點間路徑變為新的節點間路徑.則當前節點間的通信成本為,即

此外,根據定理2 可知,集群內節點間的通信開銷降低.由于集群內所有的線程都是通過路徑相互關聯的,而非關鍵線程被重新分配,則在拓撲結構上,位于非關鍵線程下游所有線程(包括位于關鍵路徑上的線程)的數據都將提前到達.因此集群內所有路徑的計算延遲降低,進而達到提高集群性能的目的.

3 節能策略分析

基于以上理論分析,提出Storm 平臺下的線程重分配與數據遷移節能策略,該節能策略包括資源約束算法與數據遷移算法,在減少通信開銷的前提下,提高了集群性能,并節約了集群的總能耗.圖5 為節能策略流程圖.

Fig.5 Flowchart of energy-efficient strategy圖5 節能策略流程圖

該策略主要分為以下5 個步驟.

步驟1:通過負載監控器獲得原系統拓撲路徑以及數據傳輸與處理的基本信息.

步驟2:根據集群內數據的傳輸與處理,確定工作節點的資源約束.

步驟3:根據資源約束、通信成本、RR 與CPU 優先級,確定非關鍵線程的分配情況.

步驟4:根據資源約束模型與最優線程重分配模型,確定集群內數據的遷移情況.

步驟5:根據節能策略計算集群的路徑成本與總能耗.

3.1 資源約束算法

為確定集群內工作節點的資源約束,采用資源約束算法,其中需要考慮工作節點CPU、內存與網絡帶寬的資源占用率.該算法保證集群關鍵節點在滿足資源約束的條件下進行數據遷移.此外,當關鍵節點的一類資源占用率達到極限時,則將該節點設置為極限節點,表示無法再將數據遷入該節點,因此需要重新選擇關鍵節點.具體的算法描述在算法1 中體現.

算法1 的輸入參數為關鍵節點的極限資源、關鍵節點的初始資源與關鍵節點遷入數據后增加的資源;輸出參數為允許關鍵節點遷入數據;初始化為極限節點集合.算法的第1 行、第2 行表示對關鍵節點ni是否為極限節點進行判斷:若為極限節點,則該節點不能被遷入數據;否則,需要判斷工作節點數據遷入是否滿足3 條原則.算法的第5 行～第9 行表示對關鍵節點是否滿足CPU 資源臨界原則進行判斷:若滿足,則判斷之后的兩條原則;否則,節點數據遷入不滿足tr.算法的第10 行～第14 行表示在滿足CPU 資源臨界原則后,對關鍵節點是否滿足內存資源臨界原則進行判斷:若滿足內存資源臨界原則,進入下一環節;否則,節點數據遷入不滿足tr.算法的第15 行～第19 行表示在滿足之前的兩條原則后,對關鍵節點是否滿足網絡帶寬資源臨界原則進行判斷:若滿足,則被選節點允許數據遷入;否則,節點數據遷入不滿足tr.

Storm 框架節能策略首先需要考慮算法對集群性能的影響,原集群內拓撲處理任務為輪詢調度算法,其時間復雜度為O(n).算法1 首先需要對關鍵節點是否為極限節點進行判斷,其時間復雜度為O(1);其次,算法1 的本質為依次判斷數據遷入節點是否滿足3 條原則,其時間復雜度為3O(1);最后,由于需要遍歷整個集群滿足3 條原則的關鍵節點,類似于輪詢調度算法,因此時間復雜度為O(n).則算法1 的時間復雜度T(A)為

3.2 數據遷移算法

數據遷移算法主要包括兩部分組成:其一為數據的遷移需要滿足資源約束條件;其二為接收數據的節點需要滿足最優線程重分配.該調度算法可以根據重寫Storm 平臺的IScheduler 接口[9]來實現.具體的算法描述在算法2 中體現.

算法2 的輸入參數為重分配后的線程集合與關鍵節點CPU 的優先級;輸出參數為生成一條新的拓撲路徑用于數據的傳輸與處理.算法的第1 行表示判斷關鍵節點是否滿足資源約束條件;算法的第3 行～第10 行表示需要減少集群內節點間的通信開銷,并預防非關鍵線程重分配出現扎堆現象;算法的第11 行～第15 行表示避免關鍵節點出現資源溢出現象,并預防非關鍵線程重分配出現扎堆現象;算法的第16 行表示重新計算Zookeeper內狀態信息到節點的映射關系,為保證數據遷移后數據處理的一致性做鋪墊;算法的第 19 行表示更新Zookeeper 的配置文件,防止因拓撲的記憶功能而影響到集群數據的傳輸與處理.

為保證數據遷移后數據處理的一致性與正確性,在將數據從非關鍵線程內遷出時,第一,需要選擇合適的關鍵節點并建立關鍵線程;第二,通過非關鍵線程的父線程將待處理的數據復制兩份分別發送至兩個子線程中,并由原非關鍵線程繼續處理數據,實時產生計算結果并發送至新增的關鍵線程;第三,將集群拓撲內的狀態信息存儲至HDFS;第四,修改Zookeeper 內狀態信息到節點的映射關系,同時,由新增的關鍵線程以異步的方式從HDFS中拉取對應的狀態信息,并執行狀態的合并;第五,通過非關鍵線程的父線程將待處理的數據發送至新增的關鍵線程中,由新增的關鍵線程執行數據處理并向下游線程輸出計算結果,以此來保證數據遷移后數據處理的一致性與正確性.

為確定數據遷移算法對時間開銷帶來的影響,算法2 首先判斷了關鍵節點是否滿足算法1,其時間復雜度為O(1);其次,算法2 通過遍歷整個集群查找合適的關鍵節點來解決非關鍵子線程的重分配問題,其時間復雜度為O(n);此外,算法2 在遍歷整個集群過程中,通過不同的限制條件確定最合適的關鍵節點來進行非關鍵子線程的重分配,其時間復雜度為3O(1);最后,算法2 在非關鍵子線程分配完成后,將數據遷入相對應的關鍵線程,并更新Zookeeper 的配置文件,其時間復雜度為O(1).則算法2 的時間復雜度T(B)為

此外,ERDM 由算法1 與算法2 組成,則ERDM 的時間復雜度T(C)為

3.3 節能模型

在Storm 集群中,能耗一般分為基礎能耗與動態能耗兩種.其中,基礎能耗為物理機的待機能耗,一般來說,同一類型物理機的待機能耗是一個固定常量;動態能耗是任務執行時集群產生的能耗,通常根據任務、功率與時間的不同,產生的動態能耗不同,因此動態能耗是一個變量.令單位時間t(s)內基礎能耗為,動態能耗為,則集群的總能耗Et為

其中,式(33)中的相關參數與式(4)與式(23)相同.式(33)表示集群拓撲執行節能策略后節約的能耗.

3.4 算法的部署與實現

一個完整的Storm 集群由主控節點、工作節點與關聯節點這3 類節點組成,其中,主控節點上運行Nimbus后臺服務,是Storm 集群的中心,負責接受用戶提交的拓撲并為工作節點分配任務;工作節點上運行Supervisor后臺服務,負責監聽主控節點分配的數據并開啟工作進程及工作線程;關聯節點上運行Zookeeper 后臺服務,負責主控節點和工作節點間所有的關聯協調,存儲整個集群的狀態信息與數據分配信息.為部署與實現Storm 平臺下的線程重分配與數據遷移節能策略,需要重寫Storm 平臺org.apache.storm.scheduler.IScheduler 接口[9]中的schedule 方法,其原型為public void schedule(topologies topologies,cluster cluster).本文在Storm 集群原有框架的基礎上新增了6 個模塊,如圖6 所示.

Fig.6 Improved architecture of Storm圖6 改進后的Storm 框架

新增模塊的功能介紹如下.

(1) 負載監控器:在一定的時間窗口內,收集各線程CPU、內存和網絡帶寬的資源占用信息以及各線程間數據流的大小.由于每個工作節點僅分配一個進程,因此可用線程監測的方法對任務運行時的各類信息進行采樣與分析.各線程的CPU 資源占用大小,可通過Java API 函數中ThreadMXBean 類的getThreadCpuTime(long id)方法獲得其CPU 的占用時間,并與其所處工作節點的CPU 主頻相乘獲得;各線程的內存資源占用大小,可通過jmap -heap 指令進行檢測;各線程的網絡帶寬占用信息,可通過實際測得的線程間數據流傳輸速率與實驗中設置的元組大小進行累加,并由簡單估算求得;線程間傳輸的數據流大小可使用計數器變量統計各線程接收到的上游線程發送的元組數量,并與時間窗口容量相除獲得數據流傳輸速率.最后,CPU 的占用率與數據傳輸速率通過nmon[38]軟件獲取,并由Excel 表格導出.具體實現需添加在拓撲組件中各Spout 的open(?)和nextTuple(?)方法以及各Bolt 的prepare(?)和execute(?)方法中.

(2) 數據庫:存儲主控節點傳來的數據分配信息和負載監控器傳來的各類資源占用信息以及集群拓撲信息,并實時更新.

(3) 配置文件更新:針對算法2 造成的集群路徑的改變,實時更新Zookeeper 的配置文件,防止因Zookeeper的記憶功能而出現數據傳輸錯誤的問題.

(4) 數據遷移模塊:部署算法1 與算法2,負責讀取數據庫中的各類信息,并執行數據遷移算法.該模塊為本文算法部署的核心環節,亦是集群執行節能策略的基礎.

(5) 分布式存儲:存儲集群拓撲內的狀態信息,并在算法2 執行過程中,以異步的方式從HDFS 中拉取對應的狀態信息,保證了數據遷移后數據處理的一致性和正確性.

(6) 自定義調度器:覆蓋Nimbus 節點默認的調度策略,讀取數據遷移模塊內的決策并執行.此外,代碼編譯完成后,將其打jar 包至主控節點Nimbus 的STORM_HOME/lib 目錄下,并在/conf/storm.yaml 中配置好相關參數后運行.

此外,本文的負載監控器與工作節點上運行的任務分別位于同一臺物理節點的兩個不同進程中,由于兩個進程之間的內存區域互相隔離,負載監控進程并不會使用工作進程的內存區域,故對節點的內存資源開銷沒有影響;負載監控器與節點的工作進程位于相同的工作節點,則不存在網絡帶寬的開銷;負載監控器收集信息所占用的CPU 資源非常少,因此對節點CPU 資源開銷的影響可忽略不計;負載監控器收集信息會上傳至數據庫,且負載監控器與數據庫位于不同的工作節點,故存在一定網絡帶寬的開銷,該網絡帶寬的開銷與時間窗口設置的大小相關,具體結果在第4.1 節體現.

本文提出了算法1 與算法2,設計并實現了Storm 平臺下的線程重分配與數據遷移節能策略,減少了集群內的通信開銷,提高了集群性能,并節約了能耗.

4 實驗結果及數據分析

為評估集群執行ERDM 的性能與能耗,本節首先討論了集群的實驗環境與參數集,然后對實驗結果進行討論與分析.

4.1 實驗環境

為驗證ERDM 的有效性,實驗搭建的Storm 集群包括19 臺PC 機,其中1 臺PC 機上運行1 個Nimbus 進程、1 個UI 進程與數據庫.16 臺PC 機上運行Supervisor 進程,3 臺PC 機上運行Zookeeper 進程.此外,每臺PC 機的網卡統一為100Mb/s LAN,且內存統一為8GB.根據不同節點的運行狀況,具體環境配置見表1 和表2.

Table 1 Hardware configuration of Storm cluster表1 Storm 集群的硬件配置

Table 2 Software configuration of Storm cluster表2 Storm 集群的軟件配置

此外,為在各類不同資源開銷下驗證ERDM 的有效性,實驗選取Intel 公司Zhang 等人[19]發布在GitHub 上的4 組基準測試,分別為CPU 敏感型(CPU-sensitive)的WordCount、網絡帶寬敏感型(network-sensitive)的Sol、內存敏感型(memory-sensitive)的RollingSort 以及Storm 在真實場景下的應用RollingCount.為消除節點內部進程間的通信開銷,執行各基準測試需滿足工作節點與工作進程的數量保持一致(即一個工作節點內僅分配一個工作進程),其余參數保留其默認值,具體的參數配置見表3.

表3 中的component.xxx_num為基準測試的組件并行度,Sol 中的topology.level為拓撲的層次,需要與component.xxx_num結合在一起分析.由于拓撲存在Spout 與Bolt 兩種組件,且1 個Spout 對應2 個Bolt,因此拓撲的層次設置為3.其中,1 個Spout 組件運行著50 個實例,2 個Bolt 組件運行著100 個實例.topology.works統一設置為16,表示各基準測試運行時,一個工作節點內僅分配一個工作進程;topology.acker.executors統一設置為 16,表示保證集群內數據流的可靠傳輸;此外,為防止數據傳輸因超時而發生重傳,需要通過多次實驗驗證結果,實驗結果為topology.max.spout.pending統一設置為200;最后,統一設置每個message.size等于一個tuple 的大小.

Table 3 Configuration of benchmarks表3 基準測試參數配置

為了驗證ERDM 的效果,本文還與TMSH-Storm[18]、LEEDSP[35]和WNDVR-Storm[37]進行了對比實驗.其中,

?TMSH-Storm 的核心思想是:對集群的任務調度進行優化,繼而達到提高集群性能的目的.

?LEEDSP 的核心思想是:彈性調節集群節點的資源,并通過DVFS 技術動態調節節點CPU 的電壓,以此達到節能的效果.且該策略為流式處理節能策略的主要代表,適用于大多數流式處理平臺(如Storm、Flink[10]以及Spark Streaming[11]等).

?WNDVR-Storm 的核心思想為:通過動態調節工作節點的內存電壓而達到節能的效果,且WNDVRStorm 由非關鍵路徑內存電壓調節(DRAM voltage regulation on non-critical path,簡稱DVRNP)與關鍵路徑內存電壓調節(DRAM voltage regulation on critical path,簡稱DVRCP)兩種算法組成.

此外,為保證在同等條件下驗證本文策略的效果,TMSH-Storm、LEEDSP 以及WNDVR-Storm 的相關參數與ERDM 保持一致.

為選擇合適的時間窗口用于監控集群內各節點資源的負載信息,本文以WordCount 為例,在系統默認調度策略下,根據額外增加的網絡開銷與系統延遲為條件選擇合適的時間窗口取值,具體的結果見表4.

Table 4 Choose of time windows表4 時間窗口的選擇

根據表4 可知,當時間窗口為10s 與20s 時,集群內額外增加的網絡開銷較大.其原因為:時間窗口取值較低而導致集群內數據庫的讀寫過于頻繁,讀寫數據庫產生的網絡開銷相對較大,從而影響集群拓撲內任務的正常執行,造成無法觸發ERDM 的問題.當時間窗口為40s 和50s 時,集群內額外增加的系統延遲較高,已影響到集群拓撲內的任務正常執行.其原因為:集群內數據庫的讀寫過于緩慢而延后了ERDM 的觸發時機,進而影響集群拓撲內的任務執行效率,造成影響集群性能的問題.綜上所述,時間窗口的取值設置為30s,在該時間窗口下能夠較好滿足實驗的執行.此外,同理可得Sol、RollingSort 以及RollingCount 的時間窗口取值.

4.2 數據遷移有效性測試

為便于觀察集群內數據遷移完成后,關鍵節點的資源占用情況,首先需要確定集群內的節點類型,即關鍵節點與非關鍵節點.根據表1 可知,共存在16 個工作節點.為查找集群內關鍵節點與非關鍵節點的分布情況,則通過Storm UI 檢測集群執行4 個基準測試后的實驗結果,具體實驗結果如圖7 所示.

Fig.7 Node distribution under different benchmarks圖7 不同基準測試下的節點分布情況

由圖7 可以看出:集群執行不同的基準測試關鍵節點與非關鍵節點分布并不相同,WordCount 下集群存在2個非關鍵節點與14 個關鍵節點,Sol 下集群存在3 個非關鍵節點與13 個關鍵節點,RollingSort 下集群存在2 個非關鍵節點與14 個關鍵節點,RollingCount 下集群存在2 個非關鍵節點與14 個關鍵節點.此外,為對比數據遷移完成后,各工作節點資源占用率的變化,需要對原集群各工作節點的資源占用率進行檢測,具體結果如圖8 所示.

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

圖8 為原集群運行4 個基準后,16 個工作節點(關鍵節點和非關鍵節點)的平均資源占用率.如圖8 所示,原集群16 個工作節點3 類資源的平均占用率主要集中在50%～70%,這為集群執行數據遷移奠定了基礎.數據遷移完成后,各基準測試根據節點分布對16 個工作節點資源占用率的平均值進行觀測,驗證資源約束算法的實際效果.具體結果如圖9 所示.

Fig.9 Resources utilization of 16 work nodes after the cluster data migration圖9 集群數據遷移后16 個工作節點的資源占用率

如圖9 所示,數據遷移完成后,集群16 個工作節點3 類資源的平均占用率主要集中在80%～100%.圖9 中缺失的部分為非關鍵節點,表示非關鍵線程重分配后,非關鍵節點已不存在線程與數據,因此予以刪除.此外,非關鍵節點在集群拓撲中的分布并不相同,表示運行不同基準測試下的拓撲并不相同.

為確定集群在執行算法時,算法的響應時間對集群性能的影響,現通過測試一個元組從Spout 出發到最終被集群拓撲處理完成后所產生的時長,以此反映集群數據的處理效率.

圖10 統計了WordCount、Sol 與RollingSort 這3 種基準測試在系統默認的調度策略與ERDM 下的延遲.

Fig.10 Comparison of system latency under different benchmarks圖10 在不同的基準測試下系統延遲的比較

如圖10 所示,3 種基準測試下集群執行ERDM 的平均延遲為801.33ms,279.28ms,131.02ms,與Storm 默認的調度策略相比,平均降低了6.3%,8.7%,10.4%.這是由于節點間的通信開銷降低而導致集群路徑的延遲下降.在105s 前存在一個峰值,且Storm 默認的調度策略與ERDM 的延遲基本相同,表示集群在提交各拓撲時的部署過程,并且105s 前集群統一遵循Storm 默認的調度策略.在105s 時,集群觸發數據遷移算法,數據的傳輸延遲出現峰值.這是由于數據遷移算法根據集群CPU、網絡帶寬與內存的負載以及線程間數據流的大小情況,對所有包含線程的工作節點資源進行重新分配,相當于對集群的任務進行初始化分配,此時集群的開銷較大,因此導致數據流因無法被及時處理而使延遲急劇上升.根據圖10 可知,3 種基準測試下集群觸發數據遷移算法后,其平均延遲高于Storm 默認的調度策略的時長為[105s,135s],共耗時約30s;但是由于時間間隔相對較短,故對整個集群拓撲數據處理性能造成的影響可忽略不計.此外,3 種基準測試的延遲并不相同,這是由于不同的基準測試,組件中包含的線程數量并不相同,但對實驗的結果不會造成影響.綜上所述,數據遷移算法在執行過程中并不會對集群數據傳輸與處理的實時性造成影響.

此外,可通過使用布隆過濾器對集群拓撲內的數據進行預處理,刪除數據集內的重復數據,導致集群拓撲單位時間內處理及傳輸的數據量減少,從而降低了在執行ERDM 過程中集群拓撲數據傳輸延遲過長的問題.

4.3 節能策略的實驗結果與分析

ERDM 的評估標準主要體現在集群性能與能耗兩個指標.

(1) 集群性能

集群執行ERDM 后的性能由集群節點間的通信開銷判斷,集群性能可通過單位時間內數據的傳輸與處理速率決定.具體結果如圖11 所示.此外,集群性能也可由Storm UI(Storm 平臺提供)進行計算.引入TMSH-Storm與ERDM 作對比,以驗證ERDM 的實際效果.

Fig.11 Comparison of data processing and transmission rate under different benchmarks圖11 在不同的基準測試下比較數據傳輸與處理速率

如圖11 所示,集群在執行ERDM 后,各基準測試(WordCount、SOL、RollingSort)在單位時間內的數據傳輸與處理速率得到了改善.執行ERDM 后,集群中數據傳輸與處理速率的平均值為77 572(tuple/s),76 471(tuple/s)和59 763(tuple/s),與Storm 默認的調度策略相比提高了13.7%,13.3%和18.2%.其原因為:與Storm 默認的調度策略相比,由于執行ERDM 減少了節點間的通信開銷,降低了路徑的計算延遲,從而導致集群數據傳輸與處理的總時間減少.因此,集群中數據傳輸與處理的速率得到了改善,單位時間內使集群增加了數據流的大小.集群執行TMSH-Storm 后,數據傳輸與處理速率的平均值為80 170(tuple/s),81 639(tuple/s)和62 647(tuple/s),與ERDM相比提高了3.3%,4.9%和5.3%.但是執行TMSH-Storm 時,集群數據傳輸與處理速率的波動較大.這是由于TMSH-Storm 在任務遷移過程中并未考慮線程遷移出現扎堆現象,導致任務并未按照原定計劃進行遷移,從而增加了額外的節點間通信開銷,故對集群數據傳輸與處理的速率造成了一定的影響.此外,從優化的角度來看,拓撲內線程的總數為326 個、286 個和318 個.執行ERDM 后,集群重新分配非關鍵線程的個數為17 個、21 個和15 個,其中,從節點間的數據傳輸改變為線程之間數據傳輸的線程個數為14 個、18 個和12 個,且平均完成一次線程之間數據傳輸的改變可降低節點間的通信成本為0.8%,1.1%和1.5%.因此,集群平均節約的通信成本為11.2%,19.8%和18%.圖12 顯示了在實際應用場景下集群拓撲內數據傳輸與處理速率.

如圖12 所示,在執行ERDM 運行RollingCount 后,集群中數據傳輸與處理速率的平均值為57 530(tuple/s),與Storm 默認的調度策略相比提高了12.5%.在執行TMSH-Storm 運行RollingCount 后,由于集群數據傳輸與處理速率波動較大的原因,其平均值為59 800(tuple/s),相比于Storm 默認的調度策略提高了15.8%.兩種策略的差距較小,但是ERDM 的穩定性更佳.此外,拓撲內線程的總數為266 個,執行ERDM 后,集群重新分配非關鍵線程的個數為14 個,其中,從節點間的數據傳輸改變為線程之間數據傳輸的線程個數為11 個,且平均完成一次線程之間數據傳輸的改變可降低節點間的通信成本為1.3%,則集群平均節約的通信成本為14.3%.因此,相比于Storm 默認的調度策略,本文提出的ERDM 具有更好的集群性能.

Fig.12 Comparison of data processing and transmission rate under the RollingCount圖12 在RollingCount 下比較數據傳輸與處理速率

(2) 集群能耗

集群能耗反映了集群中數據傳輸與處理總的能量消耗.本文通過集群拓撲中數據傳輸與處理的功率與總成本開銷相乘,以計算集群能耗.具體節約的能耗可通過式(33)計算.此外,引入WNDVR-Storm、LEEDSP 與ERDM 作對比,以驗證ERDM 的實際效果.具體的實驗結果如圖13 所示.

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

如圖13 所示,在執行ERDM 運行RollingCount 后,集群的平均功率為1 065.37W,執行Storm 默認調度策略的平均功率為1 063.15W,執行DVRNP 與DVRCP 的平均功率為1 045.32W 與1023.17W,執行LEEDSP 的平均功率為1 073.71W.相比于Storm 默認的調度策略,在105s 前,兩種算法的功率基本相等,其原因為數據遷移算法尚未觸發.但在[105,115s]內執行ERDM,功率急劇升高.其原因為:在[105s,115s]內集群拓撲執行數據遷移算法,工作節點的資源占用率消耗巨大,導致集群功率急速上升.而115s 后,數據遷移算法執行完畢,集群功率逐漸降低,并于130s 后趨于穩定,因此不會對單位時間內的集群功率造成影響.與WNDVR-Storm 相比,執行ERDM 的平均功率高于WNDVR-Storm,但是執行WNDVR-Storm 的功率波動較大,非常不穩定,且策略實現較為困難,不適合在大規模集群中使用.與LEEDSP 相比,執行ERDM 的平均功率略低于LEEDSP.其原因為:LEEDSP 并未考慮除CPU 之外部件(如內存與網絡帶寬等)的功率問題,然而Storm 集群拓撲在執行任務時,內存與網絡帶寬的功率相對較高是不容忽視的.此外,使用DVFS技術調節節點CPU電壓存在較大的偶然性,非常不穩定,且技術實現較為困難,同樣不適合部署在大規模地集群當中.為計算集群的能耗,需要對集群內的功率進行積分,具體結果如圖14 所示.

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

圖14 為RollingCount 在不同策略下集群處理相同數據量的能耗,其中,執行ERDM 集群的能耗為5 286.8KJ,執行Storm 默認調度策略的能耗為7 270.3KJ,執行DVRNP 與DVRCP 的能耗為6 317.3KJ 與6 031.5KJ,執行LEEDSP 的能耗為 5 934.7KJ.與 Storm 默認調度策略相比,執行 ERDM 集群能耗節約了 27.3%.但是在[4300000tuple,6000000tuple]內,集群執行ERDM 的能耗高于Storm 默認的調度策略.其原因為在[4300000tuple,6000000tuple]內集群拓撲執行數據遷移算法,導致集群能耗升高.而在[9000000tuple,15000000tuple]執行ERDM的能耗遠低于Storm 默認的調度策略,其原因為數據遷移算法執行完畢,由于路徑的計算延遲減少導致集群拓撲內的數據傳輸與處理速率高于Storm 默認的調度策略,因此相同數據量下能耗遠低于Storm 默認的調度策略.與WNDVR-Storm 相比,執行ERDM 集群的能耗略低于WNDVR-Storm,但是執行WNDVR-Storm 的能耗上升幅度不斷變化且逐漸升高.這是由于隨著集群數據量的不斷增大,數據量始終超過額定閾值,導致 WNDVR-Storm 基本失效.與LEEDSP 相比,執行ERDM 集群的能耗始終低于LEEDSP.這是由于LEEDSP 并未考慮內存與網絡帶寬等部件的能耗,且執行LEEDSP 內資源調度算法的能耗高于執行ERDM 內數據遷移算法的能耗.此外,隨著節點數的增加,集群內存與網絡帶寬的能耗比重會不斷增大,從而始終影響LEEDSP 的節能效果.為量化集群內數據的傳輸與處理時間與能耗的關系,需要集群在相同數據量下對ERDM 與Storm 默認調度策略進行對比,具體的實驗結果如圖15 所示.

Fig.15 Comparison of data processing and transmission time under the RollingCount圖15 在RollingCount 下比較數據傳輸與處理時間

圖15 為RollingCount 在相同數據量下兩種策略的時間對比,其中,15 000 000 tuple 下執行ERDM 集群的時間為216s,而執行Storm 默認調度策略的時間為300s.與Storm 默認調度策略相比,相同數據量下執行ERDM 集群拓撲中數據的傳輸與處理時間提高了28%.因此可以確定:在相同條件下,集群數據傳輸與處理的時間每提高1%,則集群的能耗降低1%.綜上所述,相比于Storm 默認的調度策略,本文提出的ERDM 具有更好的節能效果.

5 總結與展望

高能耗問題,是限制大數據流式處理平臺發展的主要障礙之一.Storm 是大數據流式處理中最具代表性的平臺之一,但是在最初的設計中并未考慮能耗問題,從而導致目前高能耗問題始終制約其發展.針對這一問題,本文通過研究Storm 集群的拓撲結構,建立了資源約束模型與最優線程重分配模型,并進一步提出了Storm 平臺下的線程重分配與數據遷移節能策略.該策略由資源約束算法與數據遷移算法組成,使集群在減少節點間通信成本的前提下,縮短了數據傳輸與處理的時間,并節約了能耗.最后,實驗通過4 組基準測試,從資源占用、性能與能耗的角度驗證了策略的有效性.

下一步的研究工作主要包括以下4 個方面:(1) 將ERDM 進一步部署到更為復雜的商業應用領域,使其可以在更廣闊的應用場景下使用;(2) 將布隆過濾器運用到集群,通過對集群拓撲內的數據進行預處理,刪除數據集內的重復數據,使集群單位時間內處理及傳輸的數據量減少,從而降低了集群延遲,并節約了能耗;(3) 目前,Storm 集群內部的電子元件限制了性能與能效的發展,可通過替換高能效的電子元件,以提高集群的性能,并節約能耗;(4) 目前,集群拓撲內的進程與線程的數量需要用戶手動設置,研究拓撲內組件并行度自適應調節的調度算法,由此提高了資源利用率,并節約了能耗.