基于Storm的自適應彈性資源分配策略組件實現

李麗娜 劉世龍 馬鈺博 靳德政 李念峰

摘要： 針對Storm平臺的靜態資源分配問題，提出一種分布式自適應彈性資源分配策略，能最優滿足應用的資源需求. 基于該策略，結合Storm的資源分配機制、 應用編程接口和用戶界面的參數，實現了一個面向Storm的彈性資源分配組件，支持應用資源的自適應動態調整. 實驗結果表明，在真實的流數據集上，分布式最優策略與中值式動態資源分配策略和Storm的靜態資源分配策略相比，在吞吐量、 丟失率和資源利用率上均有優勢. 同時，該自適應彈性資源分配組件能很好地與Storm系統交互，為其他彈性資源調度組件開發提供了可借鑒的解決方案.

關鍵詞： 流數據處理； 資源分配； 彈性調度； 組件實現

中圖分類號： TP391? 文獻標志碼： A? 文章編號： 1671-5489（2023）02-0384-09

Component Implementation of Adaptive ElasticResource Allocation Strategy Based on? Storm

LI Lina1，LIU Shilong1，MA Yubo1，JIN Dezheng2，LI Nianfeng1

（1. College of Computer Science and Technology，Changchun University，Changchun 130022，China;

2. College of Cyber Security，Changchun University，Changchun 130022，China）

收稿日期： 2021-11-22.

第一作者簡介： 李麗娜（1978—），女，漢族，博士，副教授，從事分布式系統和深度學習的研究，E-mail： liln@ccu.edu.cn. 通信作者簡介：

李念峰（1974—），男，漢族，博士，教授，博士生導師，從事分布式系統和區塊鏈的研究，E-mail： linf@ccu.edu.cn.

基金項目： 吉林省自然科學基金（批準號： YDZJ202101ZYTS191）、 吉林省科技廳重點研發項目（批準

號： 20210201083GX）和教育部產學研創新項目（批準號： 2020HYB03002; 2021ALA03004）.

Abstract： Aiming at the problem of? static resource allocation of the Storm platform，we proposed a distributed adaptive elastic resource allocation strategy，

which could? optimally meet the resource requirements of applications. Based on this strategy，combined with the resource allocation mechanism，application prog

ramming interface and user interface parameters of Storm，an elastic resource allocation component deployed in Storm was implemented to support adaptive and dyna

mic adjustment of application resources. The experimental results show that on the real stream data set，compared with the middle-value dynamic resource alloca

tion strategy and the static resource allocation strategy of Storm，this distributed optimal strategy has advantages in throughput，loss rate and resource utiliz

ation. Meanwhile，this adaptive elastic resource allocation component can well interact with the Storm system，providing a reference solution for the development of other elastic resource scheduling components.

Keywords： stream data processing; resource allocation; elastic scheduling; component implementation

Storm［1］是一個開源、 擴展性良好且容錯能力強的分布式實時處理平臺，其編程模型簡單，支持多種編程語言，數據處理高效，但在資源調度上存在缺陷，即靜態的資源分配和輪詢式資源放置無法適應時變的流數據［2-3］. 其中靜態資源分配是首要解決的問題［4］. Storm的資源分配以線程為單位，如果應用分配的線程數量較少，則并行執行的任務也隨之變少，應用的處理能力變弱，反之亦然［5］. 在Storm中，應用分配的線程數量在應用部署時指定，并且在運行期間不能修改，稱為靜態的資源分配. 由于流數據的時變特性，該資源分配方法將導致出現下列情況： 當數據流速過低時，線程處于空閑狀態，導致浪費資源； 當數據流速過高時，任務節點進入超載狀態，應用性能下降. 因此，根據流數據的實時變化，實現彈性資源分配［6-7］組件，動態地調整線程的數量，支持以較小的資源使用代價滿足應用性能的需求，已成為Storm資源調度亟待解決的問題.目前，基于Storm平臺的資源調度策略組件研究較多，但多數工作主要關注如何優化資源配置，較少研究彈性資源分配組件. T-Storm［8］設計并實現了一種通信感知的任務配置方法，減少了節點間的通信量和節點數量，并保證節點不過載； R-Storm［9］實現了一種資源感知的調度方法，能最大化資源利用率，同時最小化應用的網絡延遲，進而提高任務的吞吐量. 類似地，文獻［10］也實現了一種資源感知調度，并考慮減少組件之間的網絡傳輸距離，提高了系統的吞吐量和資源利用率； D-Storm［11］同時考慮了任務的資源需求和任務間的交互情況，將通信量大的任務盡量放置到同一節點，從而減少節點間通信開銷； 文獻［12］提出并實現了一種自適應的資源調度方案，該方案能較好地適應負載變化，支持有狀態操作的遷移，并解決了資源競爭問題，在滿足應用資源需求的同時，提高了資源利用率； 文獻［13］針對集群通信開銷大和負載不均衡問題，設計了一種基于拓撲結構的任務調度策略，提高了系統的實時性和平均吞吐量； 文獻［14］提出了一個最優化的線程重分配與數據遷移節能策略，降低了節點間的通信開銷和能耗，從而提升了集群的性能； 文獻［15］提出了一種基于動態拓撲的流計算性能優化方法，增強了適應數據變化的動態資源調整能力，提高了應用的吞吐量和數據處理速度. 上述工作較好地解決了Storm的資源配置問題，只有文獻［15］考慮了彈性資源分配，即自適應地調整任務的并發度，但未優化資源調整數量，且資源重分配方式較復雜，引入了額外的開銷.

本文借鑒文獻［6］關于彈性資源分配策略的研究工作，結合Storm的資源分配機制和用戶界面（user interface，UI）參數，設計并實現一個基于Storm的彈性資源分配策略組件. 該組件以減少數據丟失率并提高資源利用率為目標，通過應用編程接口（application programming interface，API）實時監控應用的運行狀態，并根據應用中每個任務節點的狀態數據計算最優化的線程并行度，同時，調用Storm默認的rebalance命令重新部署資源分配，能以較低的重配置開銷更好地適應流數據的變化.

1 Storm資源分配機制

1.1 Storm拓撲的構建和部署

在Storm中，應用/實例以拓撲（有向無環圖）的形式表示，由Spout組件和Bolt組件構成（表示為節點），組件之間通過數據流關聯（表示為有向邊）. 其中，Spout從外部數據源讀取數據，并轉換為拓撲內部的源數據，Bolt執行不同的數據處理任務，并將數據處理結果傳遞給下游的Bolt或用戶. 在應用拓撲中，數據以元組作為基本單元，連續的元組組成數據流［2］. 以單詞統計應用（以下稱WordCount應用）為例，如圖1所示，該應用拓撲由KafkaSpout，Split（Bolt），Count（Bolt）三個組件構成. 其中，數據源是數據流，如Twitter中發表的文章，先存入數據庫文件，并調用Python組件將數據存入Kafka的隊列中，再提供給KafkaSpout使用. 在數據處理部分，KafkaSpout作為應用的Spout，將數據源的數據封裝為元組形式（任務1），即句子，并采用隨機分組策略將句子輸出給Bolt組件Split； SplitBolt將獲取的句子劃分為新的元組（任務2），即單詞，再通過字段分組策略發送給另一個Bolt組件Count; 最后，Count將同一單詞計數并輸出計數值給用戶（任務3）. Storm拓撲的創建過程如下： 首先，用戶通過topologyBuilder類中的方法設置應用拓撲包含的組件，其中，setSpout方法設置Spout組件，setBolt方法設置Bolt組件； 其次，調用createTopology方法返回StormTopology對象，該對象作為拓撲提交方法submitTopology的輸入參數； 最后，將應用拓撲組件打包成jar包上傳到服務器（主節點）上.

在Storm系統中，用戶將應用拓撲提交給主節點上的Nimbus進程（負責資源分配和任務調度）并建立拓撲的本地目錄； 分布式協調服務軟件Zookeeper負責保存Nimbus與監督進程Supervisor的狀態信息，并分配應用的任務到從節點的工作進程上，同時啟動拓撲； 從節點上的Supervisor啟動/停止工作進程，獲取Zookeeper分配的任務，并在工作進程中啟動線程（Executor）執行任務（線程與任務是一對一關系），同時建立任務之間的通信； 最后，應用的數據處理結果由Nimbus返回給用戶［5］. 整個應用的部署過程，包括系統中各部分之間的關系如圖2所示.

1.2 Storm拓撲調整

在拓撲運行過程中，可通過rebalance命令調整組件執行任務所需的線程數量，即并行度，包括擴展和收縮，如圖3所示.

由圖3可見，Bolt組件任務初始分配3個線程，在進行擴展或收縮調整后，分別重分配4個線程和2個線程，即并行度對應地由3變為4和2. 組件并行度調整需經歷3個狀態轉換［2］：

首先，執行kill-transition方法將拓撲的狀態由activated改為killed，即經過kill-time的時間重新啟動拓撲; 然后，拓撲的狀態變為do-rebalance，并通過Zookeeper將任務進行重新分配. 一旦執行rebalance命令，Spout組件會立即

停止發送數據，并通過Storm的ack/fail機制保證已經發送的數據都會得到處理，防止在進行組件的并行度擴展或收縮時發生數據丟失.

2 彈性資源分配算法

2.1 算法思想

本文借鑒文獻［6］的方法，設計一個基于Storm的分布式最優彈性資源分配算法. 該算法的核心思想是： 每個組件根據輸入元組數據量大小，動態地調整組件分配的線程數量，減少數據丟失，并提高Storm系統的資源利用率. 最優算法的設計包括以下4個步驟：

1） 獲取組件的輸入元組數量；

2） 計算組件的輸入緩存占用率；

3） 判斷組件是否需要調整； 4） 確定組件重分配的線程數量.

2.1.1 組件輸入數據量

本文面向連續的流式數據源，每個組件處理的數據均為連續的數據流（元組流）. 將組件的輸入數據流離散為連續的固定時間窗口Δt內的數據塊，其中時間窗口Δt也是資源重分配的時間間隔. 在每個時間窗口Δt，需要計算數據塊的大小，即組件的輸入數據量，該值通過Storm UI的監控參數獲取.

2.1.2 輸入緩存占用率

在Storm中，每個組件Ei分配的所有線程共用一個輸入緩存，用于存儲組件的輸入元組并分發給線程處理. 如果元組的輸入速率大于處理速率，則未處理的元組會暫存于緩存中，二者的差值越大，緩存的元組越多，甚至發生數據丟失； 反之，若緩存處于空置狀態，則線程出現空閑，存在資源浪費的現象. 因此，緩存占用狀態成為衡量組件是否進行資源調整的重要指標. 本文將輸入緩存占用率定義為緩存中元組的數量與緩存容量的比值，最小值為0，表示為

Ri（n）=（Ii（n）-Pi（n））×Δt+Ri（n-1）×BsBs，（1）

其中： Ri（n）和Ri（n-1）分別表示組件Ei在時間窗口n和n-1的緩存占用率; Δt表示時間窗口的大小，可根據實際需要設置； Ii（n）表示組件Ei在窗口n的元組輸入速率； Pi（n）表示組件Ei在窗口n的元組處理速率，Pi（n）=PE×Ni（n），PE為線程的處理速率，Ni（n）是組件Ei在窗口n的線程數量； Bs表示輸入緩存的容量，所有組件相同.

2.1.3 資源調整判定

在算法中，定義3個閾值： α，β，υ，其中： α和β分別是輸入緩存占用率的上、 下限閾值，用于觸發組件的擴展調整和收縮調整； υ是輸入緩存占用率的基準閾值，限制資源分配的數量，保證系統的資源利用率. 當輸入緩存占用率Ri（n）大于上限閾值α時，觸發擴展調整，增加組件并行度； 當輸入緩存占用率Ri（n）小于下限閾值β時，進行收縮調整，減少并行度.

2.1.4 確定線程數量

在并行度調整過程中，采用最優化方法確定線程重分配的數量，在減少數據丟失量的同時，增大應用的資源利用率. 為提高資源利用率，調整后的組件處理能力至少應保證緩存占用率達到基準閾值υ. 在時間窗口n中，組件所需的并行線程數量為

Ni（n）=Di（n）PE×Δt，Di（n）>0，1，Di（n）≤0，（2）

其中Di（n）表示組件在當前窗口n需要處理的數據量，包括窗口n的輸入數據和窗口n-1的緩存數據，同時減去基準閾值對應的緩存數據，即Di（n）=Ii×Δt+Bs×Ri（n-1）-Bs×υ.

2.2 算法偽代碼

算法1 OERA（optimal elastic resource allocation）算法.

輸入： Ri（n-1），Ri（n），Bs，PE，Ni（n），n，Δt，α，β，υ;

輸出： Ni（n）;

步驟1） IF n==1 THEN

步驟2） Ri（n-1）=0; //初始化緩存占用率

步驟3） WHILE （Ei未終止） //組件Ei每隔Δt進行一次資源重分配，直到組件的任務終止

步驟4） 計算窗口n內輸入數據量Si（n）; //通過Storm UI獲取

步驟5） Ii（n）=Si（n）/Δt; //計算組件Ei在窗口n的輸入速率Ii（n）

步驟6） Pi（n）=PE×Ni（n）; //計算窗口n的處理速率Pi（n）

步驟7） 利用式（1）計算組件Ei的緩存占用率Ri（n）; //資源重分配判定依據

步驟8） IF Ri（n）>α或Ri（n）<β THEN //進行資源重分配（擴展或收縮）判斷

步驟9） 利用式（2）計算組件Ei重分配的資源量Ni（n）; //資源重分配計算規則

步驟10） Ri（n-1）=Ri（n）; //保存窗口n的緩存占用率，作為n+1時間窗口的前一個窗口緩存占用率

步驟11） n=n+1; //計算下一個時間窗口n+1

步驟12） RETURN Ni（n）.

2.3 算法分析

在OERA算法中，每個組件在時間窗口n進行一次資源重分配數量計算，其中僅需要計算1次輸入數據量、 1次輸入速率、 1次處理速率和1次緩存占有率，進行1次資源調整判斷，并計算1次或0次重分配資源量，共需要時間為O（1）. 因此，在每個時間窗口n，OERA算法的時間復雜度均為O（1）. 由于每個組件獨立地計算資源重分配數量，因此整個應用的所有組件并行地執行OERA算法，應用在時間窗口n的資源重分配時間復雜度也是O（1），具有很小的執行開銷.

3 彈性資源分配組件實現

本文的組件實現主要包含兩部分： 1） 數據監控接口，用于獲取應用拓撲運行中的監控數據，如吞吐量、 處理延遲和線程數量等，通過向Storm的API接口發送網絡請求實現； 2）彈性資源分配類，處理監控接口獲得的數據，結合彈性資源分配算法判斷組件當前狀態是否需要調整，并計算調整后的線程數量，再通過調用Shell執行調整命令，進行資源重配置.

3.1 數據監控接口

在數據監控部分，需要從Storm UI獲取組件的狀態數據，時間窗口Δt的大小設為10 min，與Storm UI的監控時間相同. 狀態數據主要包括拓撲ID、 元組累計傳輸總數transferred、 線程數executors和元組處理延遲executeLatency. 實現過程如下： 首先，通過API接口中的request方法向Storm UI發送監控請求，請求格式為requests.get（“http：//IP： 端口號/api/v1/topology/Topology-Id”），其中，IP是當前Nimbus節點的IP地址，端口號是在storm.yaml文件中配置的ui.server參數，Topology-Id是當前監控的拓撲運行時的ID； 其次，設置Bolts和Spouts監控的節點，即res.json（ ）［“bolts”］和res.json（ ）［“spouts”］； 最后，通過spouts［“性能參數”］和bolts［“性能參數”］的方式，設置transferred，executors，executeLatency等監控參數.

輸入緩存尺寸，即線程的接收隊列大小，對應屬性Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE，通過Storm.yaml文件的conf.put方法配置.

3.2 彈性資源分配類

3.2.1 監控數據獲取和處理

在彈性資源分配類中，先通過數據監控接口分別獲取組件傳輸的元組數、 線程數和平均元組處理時間，即spouts.transferred，bolts.executors，bolts.executeLatency. 然后，將上述監控數據轉換為Storm拓撲的運行狀態數據，即資源分配算法需要的組件信息. 因此，元組輸入速率Ii（n）利用Ii（n）=（transferred（n）-transferred（n-1））/Δt計算，其中transferred（n）和transferred（n-1）分別為前n個和前（n-1）個時間窗口傳輸的元組總數. 元組處理速率Pi（n）是組件在窗口n中元組處理延遲的倒數，即Pi（n）=1/executeLatency. Bs為Storm.yaml文件中手動配置單個線程接收隊列大小與線程數的乘積. 在獲取上述狀態信息后，根據式（1）計算組件在窗口n中的輸入緩存占用率Ri（n）.

3.2.2 資源分配數量計算

在資源分配數量計算過程中，首先，通過實現繼承BaseRichSpout/BaseRichBolt類（或實現IRichSpout/IRichBolt接口）創建KafkaSpout，Split和Count組件，其中KafkaSpout組件利用nextTuple方法將數據源組織成元組并發送給Split組件，Split和Count組件分別實現分割句子和計數單詞的任務； 其次，每個組件分別調用OERA算法計算資源分配數量.

定義If_Balance（buffer_occupy）方法判斷組件是否進行資源重配置，其中參數buffer_occupy是組件的輸入緩存占用率； Resource_Count（deal_tuple）方法用于計算組件的重分配資源數量，其中deal_tuple是組件當前需要處理的數據量，返回值是資源分配數量.

3.2.3 并行度重配置

在資源重配置過程中，通過調用Shell類執行應用的組件并行度重配置. 在Shell類中，定義execCmd（CMD，DIR）方法執行調整命令，其中： CMD變量為執行并行度重配置的調整命令，在CMD變量中，由exec_list參數接收所有組件的重分配資源數量N; DIR為執行命令的絕對路徑. 在執行調整命令時，重配置拓撲并行度的整個過程延遲約為120 s.

4 實驗結果與分析

4.1 實驗設置

本文Storm集群由5個節點組成，其中1個主節點部署Nimbus，Zookeeper和Kafka，4個從節點部署Supervisor. 每個節點配置如下： AMD Ryzen 5 3500U 2.10 GHz 8核CPU， GPU為AMD Radeon（TM） Vega 8 Graphics，16 GB內存，ubuntu-20.04.2.0-desktop-amd-64操作系統. 實驗數據集來自Twitter上某篇24 h內發表的關于Covid-19的推文，先將推文數據每10 min統計一次，統計結果作為1條記錄傳入Nimbus節點上部署的Kafka［16］，再通過Kafka的消息隊列與Storm應用的Spout建立連接，作為其數據源. Kafka數據在24 h內的變化趨勢如圖4所示. 為檢驗彈性資源分配組件在不同輸入速率下的調整性能以及正確性，選擇具有代表性的8～15 h的數據作為本文的測試數據集，并將負載數據量轉換為元組數量，如圖5所示. 采用WordCount應用作為測試實例，初始時，WordCount拓撲中的組件線程數配置如下： Spout組件線程數為5，不設置setNumTask參數; Split組件線程數為5，setNumTask參數為16; Count組件線程數為12，setNumTask參數為40. 在彈性資源分配算法中，將3個閾值α，β，υ分別設為0.8，0.2，0.7.

4.2 算法性能測試

本文選擇中值動態資源分配算法（以M作為前綴）和Storm的靜態資源分配算法（以S作為前綴）作為OERA算法（以O作為前綴）的對比算法，進行吞吐量、 丟失率、 并行度和資源利用率上的性能測試. 其中： 中值動態資源分配算法是在最優資源分配算法的基礎上，選擇前一個固定時間間隔內（10Δt）所有Δt的資源分配數量中值作為后一個固定時間間隔的資源分配數量； Storm的靜態資源分配算法采用固定方式分配資源，在整個應用運行過程中保持不變.

4.2.1 吞吐量測試

吞吐量是衡量組件數據處理能力的重要指標，不同算法的吞吐量對比如圖6所示. 由圖6（A），（B）可見，由于OERA算法在拓撲運行時進行了最優的資源分配，即設置為最優的并行度，能較好與組件的數據負載相匹配，組件O-Count和O-Split的吞吐量均高于其他兩種算法的對應組件. 當輸入負載變化較大時，最優資源分配的組件能自適應地調整資源分配數量，吞吐量性能最佳，中值動態資源分配以中間值代替最優值，性能次之，而傳統的靜態資源分配不能調整組件的并行度，從而無法增加吞吐量，吞吐量性能最差. 對于整個應用，OERA算法的吞吐量性能也優于中值動態資源配置和傳統的靜態資源配置，如圖6（C）所示.

4.2.2 丟失率測試

在數據丟失率測試中，最優資源分配算法的每個組件（O-Count和O-Split）數據丟失率低于中值動態資源分配算法最多約20%，但明顯比傳統靜態資源分配算法平均減少了50%～70%，如圖7（A），（B）所示. 當輸入負載增加時，最優資源分配算法會增加組件的資源數量，從而提高其數據處理能力，減少數據丟失量； 中值動態資源分配算法也會增加組件（M-Count和M-Split）的并行度，但增加的幅度無法完全與輸入負載匹配，導致一定程度的數據丟失； 傳統的靜態分配方式保持組件（S-Count和S-Split）的并行度不變，導致節點的處理能力不夠，數據丟失嚴重. 采用OERA算法進行資源分配時，應用的平均整體數據丟失率（O-WordCount）分別低于中值動態資源分配算法（M-WordCount）和傳統靜態分配算法（S-WordCount）約30%和90%，如圖7（C）所示.

4.2.3 并行度測試

當組件的輸入負載發生變化時，不同算法的組件并行度變化和均值如圖8所示. 由圖8可見，傳統的靜態分配策略不具備資源調整特性，S-Count和S-Split組件的并行度始終保持不變. 由于Count組件的輸入負載大且變化較快（以單詞作為元組），OERA算法和中值動態資源分配算法均根據負載進行資源擴展或收縮調整，同時OERA算法的調整幅度最優且粒度更小，O-Count組件的并行度變化最頻繁，M-Count組件次之，如圖8（A）所示. 相反，Split組件的輸入負載小且變化不明顯（以句子作為元組），O-Split和M-Split組件的并行度基本保持不變，如圖8（B）所示. 對于應用，OERA算法的組件平均并行度略高于中值動態算法和傳統靜態算法，如圖8（C）所示，但保證了應用的整體性能.

4.2.4 資源利用率測試

如圖9（A），（B）所示，在資源利用率測試中，OERA算法根據輸入負載進行最優的資源分配，以最大限度地提高資源利用率，且負載量和變化幅度越大，效果越明顯，其中O-Count資源利用率始終接近于0.8，O-Split組件則平均約為0.4. 傳統靜態資源分配算法則無法在運行時調整資源數量（S-Count和S-Split），當輸入負載較大時，組件資源被完全占用，資源利用率接近100%； 隨著輸入負載逐漸變小，則可能出現資源浪費，導致應用整體的資源利用率降低. 中值動態資源分配算法兼有最優動態調整和靜態調整的特性，能在較大程度上滿足負載需求，因此，M-Count和M-Split組件的資源利用率更接近于OERA算法組件. 如圖9（C）所示，OERA的組件平均資源利用率整體上分別比中值動態算法和傳統靜態算法約提高9%和22%.

上述實驗結果表明，面向時變的輸入負載，本文設計和實現的OERA組件能自適應且準確地計算最優的組件并行度，較好地滿足了應用的數據處理需求. OERA算法在吞吐量、 丟失率和資源利用率性能上，均優于中值動態算法和靜態算法，其中吞吐量分別約提高了3%和4%，丟失率分別約降低了30%和90%，資源利用率約保持在60%，分別約提高了9%和22%. 當數據負載發生變化時，OERA算法性能最好，能最大程度地滿足負載的資源需求，中值動態算法次之，且在較大負載時性能更優. 相比之下，由于資源分配方式固定，傳統靜態算法的性能與輸入負載密切相關，過高或過低負載情況下明顯均低于OERA算法.

綜上所述，針對面向時變的大規模流數據，Storm的靜態資源分配機制導致系統資源利用率較低，甚至無法滿足應用性能需求的問題，以減少數據丟失率和提高資源利用率為目標，本文提出了一種最優的彈性資源分配算法. 通過研究Storm的資源分配機制、 API接口和UI參數，實現了一個基于Storm的自適應彈性資源分配組件. 該組件可根據輸入負載的變化動態地調整應用組件的線程資源分配. 在真實數據集上進行性能測試的結果表明，與中值動態資源分配算法和靜態資源分配算法相比，該組件在滿足應用性能需求的同時，在應用的整體性能上均占優，其中數據丟失率約降低30%和90%，資源利用率約提高9%和22%，吞吐量約提高3%和4%.

參考文獻

［1］ TOSHNIWAL A，TANEJA S，SHUKLA A，et al. Storm@t

witter ［C］//ACM SIGMOD International Conference on Management of Data. New York： ACM，2014： 147-156.

［2］ 蔡宇，趙國鋒，郭航. 實時流處理系統Storm的調度優化綜述 ［J］. 計算機應用研究，2018，35（9）： 2567-2573. （CAI Y，ZHAO G F，GUO H. Over

view of Scheduling Optimization of Real-Time Stream Processing System Storm ［J］. Computer Application Research，2018，35（9）： 2567-2573.）

［3］ MICHAEL K，MILLER K W. Big Data： New Opportunities and New Challenges ［J］. Computer，2013，46（6）： 22-24.

［4］ WEI X H，LI L N，LI X，et al. Pec： Proactive Elastic Collaborative Resource

Scheduling in Data Stream Processing ［J］. IEEE Transactions on Parallel and Distributed Systems，2019，30（7）： 1628-1642.

［5］ 張洲，黃國銳，金培權. 基于Storm的任務調度： 現狀與研究展望 ［J］. 計算機科學，

2019，46（9）： 28-35. （ZHANG Z，HUANG G R，JIN P Q. Task Scheduling on Storm： Current Situations and Research Prospects ［J］. Computer Science，2019，46（9）： 28-35.）

［6］ 李麗娜，魏曉輝，李翔，等. 流數據處理中負載突發感知的彈性資源分配 ［J］. 計算機學報，2018，41（10）： 2193-2208. （LI L N，WEI X H，LI X，et al. Elastic Resourc

e Allocation of Load Burst Perception in Streaming Data Processing ［J］. Journal of Computer Science，2018，41（10）： 2193-2208.）

［7］ 李麗娜，魏曉輝，郝琳琳，等. 大規模流數據處理中代價有效的彈性資源分配策略 ［J］. 吉林大學學報（工學版），2020，50（5）： 1832-1843. （LI L

N，WEI X H，HAO L L，et al. Cost-Effective Elastic Resource Allocation Strategy in Large-Scale Streami

ng Data Processing ［J］. Journal of Jilin University （Engineering and Technology Edition），2020，50（5）： 1832-1843.）

［8］ XU J L，CHEN Z H，TANG J，et al. T-Storm： Traffic-Aware Online Scheduling in Storm ［C］//International Conference on Distri

buted Computing Systems. Piscataway，NJ： IEEE，2014： 535-544.

［9］ PENG B，HOSSEINI M，HONG Z，et al. R-Storm： Resource-Aware Scheduling in Storm ［C］//MIDDLEWARE Conference. New York： ACM，2015： 149-161.

［10］ 劉月超，于炯，魯亮. Storm環境下一種改進的任務調度策略 ［J］. 新疆大學學報（

自然科學版），2017，34（1）： 90-95. （LIU Y C，YU J，LU L. An Improved Task Schedule Strategy in Storm Environment ［J］. Journal of Xinjiang University （Natural Science Edition），2017，34（1）： 90-95.）

［11］ LIU X Y，BUYYA R. D-Storm： Dynamic Resource-Efficient Scheduling of Stream P

rocessing Applications ［C］//IEEE 23rd International Conference on Parallel and Distributed Systems （ICPADS）. Piscataway，NJ： IEEE，2017： 485-492.

［12］ LIU S C，WENG J P，WANG J H，et al. An Adaptive Online Sc

heme for Scheduling and Resource Enforcement in Storm ［J］. IEEE/ACM Transactions on Networking （TON），2019，27（4）： 1373-1386.

［13］ 劉粟，于炯，魯亮，等. Storm環境下基于拓撲結構的任務調度策略 ［J］. 計算機應用，2018，38（12）： 133-141. （LIU S，YU J，LU L，et al. T

opology Based Task Scheduling Strategy in Storm Environment ［J］. Computer Applications，2018，38（12）： 133-141.）

［14］ 蒲勇霖，于炯，魯亮，等. Storm平臺下的線程重分配與數據遷移節能策略 ［J］. 軟件學報，2021，32（8）： 2557-2579. （PU Y L，YU J，LU L，et al. Energy-Efficient S

trategy Based on Executor Reallocation and Data Migration in Storm ［J］. Journal of Software，2021，32（8）： 2557-2579.）

［15］ 陸佳煒，吳涵，陳烘，等. 一種基于動態拓撲的流計算性能優化方法及其在Storm中的實現 ［J］. 電子學報，2020，48（5）： 878-890. （LU J W，W

U H，CHEN H，et al. A Performance Optimization Method Based on Dynamic Topology for Stream Computing and Its Implementation in Storm ［J］. Chinese Journal of Electronics，2020，48（5）： 878-890.）

［16］ 楊立鵬，張仰森，張雯，等. 基于Storm實時流式計算框架的網絡日志分析方法 ［J］. 計算機科學，2019，46（9）： 176-183. （YANG L P，ZHANG Y

S，ZHANG W，et al. Web Log Analysis Method Based on Storm Real-Time Streaming Computing Framework ［J］. Computer Science，2019，46（9）： 176-183.）

（責任編輯： 韓 嘯）