梁秋紅，郝雅萍

(1.運城廣播電視大學 成教部，山西 運城 044000;2.朔州師范高等?？茖W校 教務處，山西 朔州 036000)

隨著計算機科學技術的快速發(fā)展，物聯(lián)網、社交網絡等在各個領域都得到廣泛的應用，每天都會產生海量數據，人們已經逐步進入了大數據時代。大數據時代如何高效處理海量數據已經成為當前工業(yè)界以及學術界重點研究的方向。大數據的計算模式包含批量計算、流式計算、交互計算、圖計算等，以批量計算、流式計算為主[1-2]。批量計算一般處理存儲在數據庫中的海量數據，適合應用在實時性較低的環(huán)境下，常見的有Hadoop生態(tài)系統(tǒng)；流式計算以數據流的方式計算進入到內存中的工作節(jié)點，只要數據源保持活動狀態(tài)，就會持續(xù)不斷地生成數據且無需進行存儲，適用于實時性要求較高且處理窗口局部數據的應用領域中。流式大數據平臺可以顯著提升在線數據密集型應用的用戶體驗，廣泛應用在各類實時性非常嚴格的行業(yè)領域中，例金融銀行、股市分析等[3]。

1 Storm模型框架

一個完整的Storm分布式系統(tǒng)由4類節(jié)點組成，分別為：

(1)主控節(jié)點。用戶會將拓撲作業(yè)提交給主控節(jié)點，直接將任務分配給工作節(jié)點，提供狀態(tài)獲取接口。

(2)工作節(jié)點。它是Supervisors運行的后臺節(jié)點，完成Nimbus分配任務的監(jiān)聽動作，屬于分布式部署。

(3)控制節(jié)點。它是一個Web服務器，將計算結果反饋給用戶，并提供給制定端口網頁服務。

(4)協(xié)調節(jié)點。負責所有節(jié)點的協(xié)調配置管理，也是維持Storm系統(tǒng)穩(wěn)定、實用性的關鍵因素。

2 任務調度優(yōu)化

2.1 Storm基本模型

2.1.1 Storm拓撲邏輯模型

拓撲結構一般都是應用二元組(C,S)來描述，其中C={c1,c2,…,c|c|}表示拓撲頂點集合，每個頂點表示1個組件，符號定義為Spout或Bolt；S={s1,2,s1,3,…,s|C|-i,|C|}表示拓撲中有向邊集合，每個組件表示相鄰組件間的數據流傳遞。當si,j∈S→ci,cj∈C,i≠j，即表示ci組件發(fā)送了數據，并由cj接收。因此就可以定義拓撲邏輯模型為具備上述特征的有向無環(huán)圖[4-6]。

圖1為一個拓撲邏輯模型，圖中組件集為{ca,cb,…,cg}，數據流集為{sa,c,sa,d,…,se,g}。數據初始頂點Spout為ca,cb，主要功能為數據的輸入以及發(fā)送到流式計算群待處理；其余的節(jié)點表示為Bolt，主要功能為接收上一組件數據并將計算結果發(fā)送給下一組件；數據流的終端節(jié)點cf,cg直接將結果展示給用戶或保存到數據庫中。

圖1 Storm拓撲邏輯模型

假設任意組件ci，cj,ck,cj是ci,ck的中間組件，組件ci發(fā)送的數據可以經過cj組件到達ck組件，則表示組件cj的關聯(lián)組件為ci,ck。例如圖1中cd組件的關聯(lián)組件為ca,cb,cg；cc組件的關聯(lián)組件為ca,cf。

2.1.2 流任務

在拓撲邏輯模型中，每個組件都可以并行處理多個任務，且每個任務由一個工作線程處理。而對于其中任意的組件ci∈C，存在任務Ei={et1,ei2,…,ei|Ti|}，當中eij表示ci運行的第j個任務，尤其是任務數量為1的組件ci，則可以直接定義Ei={ei1}=ei。其中任務關聯(lián)則表示存在上一任務流和下一任務流之間存在較大的數據流關聯(lián)。圖2為圖1中的任務拓撲實例模型，其中組件ca有3個任務：ed1，ed2,ed3,任務關聯(lián)以ed1為例，它的關聯(lián)任務分別為ea,eb,ef1,ef2。子拓撲中各個組件必須存在數據流，即子拓撲中任務是可以數據流動。

圖2 拓撲流結構

2.2 任務調度策略

在Storm集群中，資源都是由工作節(jié)點Supervisor構成的，slot表示任務工作節(jié)點內存資源，每個slot表示一個內存資源，且每個slot都只能被一個線程(Work)占用。在每個slot中每個Work則會包含多個Executor執(zhí)行器，當中每個Executor執(zhí)行器有很多個Task任務。Storm默認的調度器為EventScheduler，它是通過輪詢策略來搜索集群中所有拓撲結構的工作節(jié)點，并將資源較為均勻地分配給任務進程[7]。

上述任務調度策略較為簡單，任務分配較為均勻，已經應用到較多的場景中，但該上述資源分配調度只是平均分配集群資源，并沒有充分考慮到具體任務對于磁盤、內存、CPU等需求都不一樣，甚至子拓撲結構的關聯(lián)任務需求資源都不一樣，這就會給流式數據任務調度性能造成非常大的影響。例如當某些業(yè)務對于CPU的需求較高時，若采用上述任務調度策略就會致使子拓撲中任務都運行在同一個工作節(jié)點中，很容易發(fā)生集群工作節(jié)點負載不均衡的現(xiàn)象。

2.3 任務調度策略優(yōu)化

為了更好地解決上述任務分配不均勻以及負載不均衡的問題，提出直接分配固定節(jié)點的分配調度策略，該任務分配調度策略將子拓撲中的計算組件強制運行在一個固定機器上，且分配計算任務較為簡單的子拓撲，這就可以促進組件的維護管理；基于負載均衡策略，將子拓撲中多個線程都均衡分配給集群的各個工作節(jié)點，確保組件可以獲取得到相似的線程數量，降低同性資源競爭，將一些對CPU需求較大的相似組件分配到不同任務處理，以此來獲取得到更加均衡的資源調度[8]。

2.3.1 直接分配固定節(jié)點的任務分配調度策略

基于固定節(jié)點的直接分配調度策略，將子拓撲的組件線程都分配到一個固定的物理節(jié)點上，避免元組在不同節(jié)點間進行傳輸，提高任務調度的運維管理能力。子拓撲中組件固定分配給某一個物理節(jié)點，當數據臨近該物理節(jié)點，就可以直接就近分配給該節(jié)點，以此來降低帶寬開銷；計算得到的數據結果Bolt直接分配給該節(jié)點，提升數據存儲速度。具體任務調度優(yōu)化步驟如下：

(1)目標定位。判斷需求子拓撲是否已經上傳到集群資源上，并從Storm拓撲模型中找到需求子拓撲進行下一步任務分配。

(2)確定目標是否需要分配。根據定位到的目標子拓撲，判斷其是否已經被任務調用分配過：已經被調用過，則進入下一步；否則分配調度資源。

(3)定位目標線程。要對需求子拓撲中線程進行分配調度，已經被分配過線程不能被調度。

(4)目標組件分配確認。根據得到的需求子拓撲所有組件的線程，并確認目標組件是否要被分配資源。

(5)工作節(jié)點定位。在確認目標組件需要分配資源后，找到分配的相關執(zhí)行器，接下來定位子拓撲進程節(jié)點。

(6)得到目標資源。根據上述定位到的目標進程得到相關資源slot，并判斷slot資源是否可以滿足子拓撲需求，當無法滿足時要將已經被占用的slot釋放，供需求子拓撲調用。

(7)分配調度。循環(huán)上述過程，并將所有非目標子拓撲的任務調度都分配給Storm的調度管理器EventSchedule實現(xiàn)。

2.3.2 基于負載均衡的任務調度策略

負載均衡的任務調度策略應用貪心算法思想，在每次對任務進行調度時盡可能分配slot數量最多的節(jié)點。定義符號Li(i=1,2,…,t)表示第i個子拓撲需求進程數量，Ki(i=1,2,…,t)表示第i個子拓撲需求線程數量。任務調度策略步驟如表1。

表1 基于負載均衡的任務調度策略

3 實驗和評價

3.1 實驗環(huán)境

實驗所用的Storm環(huán)境搭建在Linux虛擬機中，Linux虛擬機數量為6；Storm集群由1個Nimbus節(jié)點、5個Supervisor節(jié)點構成；內存為8G；CPU為4核；每臺服務器硬盤大小為80G。

3.2 數據時間性能測試

將本文任務調度算法應用在實時性要求較高的交通領域中，并從中獲取得到上百億海量的車牌識別數據，并將其輸入到集群系統(tǒng)中。將集群計算組件Bolt并行度設置為5，以此來測試集群計算時間，即一條實時數據從傳輸到計算識別完成所需的時間。從圖3可以看出，數據處理時間基本為0.6 ms，波動范圍很小，表明本系統(tǒng)可以實時計算處理高并發(fā)數據流，具備非常好的時間效率。

圖3 不同數據并發(fā)量下的計算時間

3.3 直接分配固定節(jié)點的任務分配調度策略評價

將某一個子拓撲作業(yè)“List”中的所有進程分配到工作節(jié)點“storm-node”上，且該作業(yè)任務提交給Nimbus節(jié)點上，將并行度設置為5。表2表示各個工作節(jié)點的使用情況：在storm-node工作節(jié)點上只有一個進程，即list；其他工作都沒有工作，即集群中其他的slot都是閑置的。

表2 直接分配固定節(jié)點的任務分配調度策略調度結果

通過將子拓撲list的并發(fā)度定義為2，4，6，8，并將該list提交到集群中，并分別將引用storm默認的調度器以及直接分配固定節(jié)點的任務分配調度策略進行識別時延對比，實驗結果如圖4所示。根據圖4可知，直接分配固定節(jié)點的任務分配調度策略因降低了各個數據在網絡關聯(lián)度，明顯降低了數據處理時延。

圖4 不同并發(fā)下的兩種調度器的處理時延

3.4 基于負載均衡的任務調度策略評價

為了更好地測試集群負載均衡任務調度策略的正確性，在當前集群環(huán)境中配置以下任務負載，并實時記錄各個集群的使用情況。

(1)創(chuàng)建一個子拓撲T1，包含了一個spout(1個任務)，兩個bolt(均為8個task)，定義并發(fā)度為4；

(2)創(chuàng)建一個子拓撲T2，包含了spout(1個任務)，3個bolt(前兩個bolt為8個task，第三個bolt為1個task)，定義并發(fā)度為3；

(3)創(chuàng)建一個子拓撲T3，包含了spout(1個任務)，2個bolt(均為8個task)，定義并發(fā)度為3。

在提交每個子拓撲作業(yè)后，集群中節(jié)點slot數量的使用情況如表3。分析表3可知，在完成T3子拓撲提交后，集群中每個節(jié)點都應用了2個slot。由此可得基于負載均衡的任務調度可以將子拓撲中作業(yè)進程平均分配給各個工作節(jié)點，且在任務調度時，選擇可用資源數量最大的節(jié)點進行分配。

表3 基于負載均衡的任務調度策略

4 結論

Storm是當前處理流式大數據的主要框架，已經被廣泛應用在實時性要求較高的領域行業(yè)中。Storm自帶任務分配調度器沒有考慮現(xiàn)實環(huán)境中任務需求以及負載均衡，會對任務調度性能產生比較大的影響。提出兩種優(yōu)化調度策略來解決上述問題，實驗結果表明具備較好的實時處理效率。