本發(fā)明屬于數(shù)據(jù)交換網(wǎng)絡領域，涉及一種基于數(shù)據(jù)流預測的storm任務伸縮調度算法。
背景技術：
：云計算、物聯(lián)網(wǎng)、社交媒體以及移動互聯(lián)網(wǎng)等新興技術和應用模式的普及和推廣，促使全球數(shù)據(jù)量急劇增加，推動人類社會進入大數(shù)據(jù)時代。在大數(shù)據(jù)背景下，數(shù)據(jù)蘊含了豐富的內涵和價值，數(shù)據(jù)的時效性越來越重要，數(shù)據(jù)的流式特征也越來越顯著，流式計算的重要性也越來越突出。業(yè)界推出了s4、spark、storm等流式計算框架。storm是個實時的、分布式的以及具備高容錯的計算系統(tǒng)。storm可以處理大批量的數(shù)據(jù)，也可以在保證高可靠性的前提下讓處理進行得更實時化，能快速處理或輸出所有信息。storm具備容錯和分布計算等特性，可以到不同的機器上進行大批量的數(shù)據(jù)處理。正因storm所表現(xiàn)出來的強大功能，使得它被廣泛應用于國內外的互聯(lián)網(wǎng)企業(yè)，如twitter、阿里巴巴、雅虎等。但在storm的應用及研究中，發(fā)現(xiàn)其在多個方面都有待完善。storm是一個實時流式計算框架，時效性要求高，而調度算法的好壞直接影響到tuple的處理時延。storm中默認的任務調度器使用輪詢調度的策略，首先是計算集群中可供分配的slot資源，并判斷當前已分配給運行topology的slot是否需要重新分配，然后對可分配的slot進行排序。計算topology的executor信息，最后將資源平均地分配給topology。在調度算法的優(yōu)化上，業(yè)界已有許多相關研究：l.aniello等提出了一種將相互通信頻率高的executor調度到同一個slot上來減少網(wǎng)絡通信的改進調度算法，分為離線版：分析topology的靜態(tài)結構，決定那些executor應該放在同一個slot；在線版：監(jiān)控executor運行時的通信情況，將通信頻率高的executor放到同一個slot。jielongxu等指出l.aniello所提出的離線處理忽視了集群中結點的負載情況和在線處理的調度算法模型缺乏有力的數(shù)學證明。作者在此基礎上進行了優(yōu)化，提出將executor按照trafficload降序排列，然后按序依次將executor分配到負載最輕的slot上，同時每個workernode上同一個topology的executor會被分配到同一個slot上和每個workernode的任務量不會過載。pengb等提出一種最大化資源利用率的同時最小化網(wǎng)絡通信來提升系統(tǒng)性能的調度算法。其要解決的核心問題是：如何找到一種task到workernode的映射，使所有的資源請求都能夠得到滿足同時結點不會出現(xiàn)資源過載。longs等結合storm的不同應用場景，如恢復歷史調度任務、單節(jié)點任務調度、資源需求調度等，對storm的資源分配和調度算法做了改進。sund等提出基于分布式qos(qualityofservice)感知的調度算法，使得storm適用于地理信息系統(tǒng)的研究中。在上述的調度算法中，是針對用戶配置好topology任務并行度的調度，忽視了用戶配置的topology中的worker數(shù)和各個組件的executor數(shù)對處理性能也有著嚴重的影響。當storm要處理的數(shù)據(jù)流比較平穩(wěn)時，存在一個較優(yōu)的各組件間的并行度關系，而用戶很難在提交topology時設置出各個組件的較優(yōu)并行度，當設置不合理時會造成tuple處理時延的增加。同時，在某些業(yè)務中，如微博中實時熱詞統(tǒng)計，storm要處理的微博數(shù)據(jù)流是實時變化的，一天中存在高峰期低峰期，并且有時會因為某個事件出現(xiàn)爆炸式的增長，此時僅僅通過上述的調度算法的優(yōu)化并不能達到目的。因此希望storm計算框架中能預測要處理的數(shù)據(jù)流，動態(tài)調整topology中各個組件的并行度，即對用戶提交的任務能進行彈性伸縮。在現(xiàn)有的關于storm彈性伸縮中，對topology中各組件間的關聯(lián)性考慮不足，同時在彈性伸縮時采用簡單的添加或較少各組件的并行度，直到獲得較優(yōu)的各組件并行度，這個過程中可能會進行多次任務調度，而每次任務調度是有時間開銷的，因此在一定程度上增加了tuple的處理時延。同時現(xiàn)有的伸縮調整都是在系統(tǒng)負載發(fā)生變化時才對用戶提交的topology中各組件的并行度進行調整，而每次的調整都需要一定的時間，因此在一定程度上來說降低了系統(tǒng)的吞吐量。技術實現(xiàn)要素：有鑒于此，本發(fā)明的目的在于提供一種基于數(shù)據(jù)流預測的storm任務伸縮調度算法，提前預測變化，根據(jù)監(jiān)控得到的運行數(shù)據(jù)快速高效的求得topology中各組件的較優(yōu)并行度，從而提高吞吐量，降低處理時延。為達到上述目的，本發(fā)明提供如下技術方案：一種基于數(shù)據(jù)流預測的storm任務伸縮調度算法，包括以下步驟：s1：設置目標函數(shù)；s2：求解topology中worker數(shù)和各個組件的executor數(shù)；s3：預測topology要處理的數(shù)據(jù)流并求解開始組件spout所需的executor數(shù)；s4：任務調度。進一步，所述s1設置目標函數(shù)為：其中，ntuple為所處理tuple的數(shù)量，trec為tuple由發(fā)送節(jié)點到處理節(jié)點所需的接受時間，tqueue為tuple到處理節(jié)點后因bolt繁忙tuple排隊的時間，tproc為tuple的邏輯處理時間，tsend為tuple處理完后形成新的tuple的發(fā)送時間。進一步，所述s2具體為：s201：確定topology中開始組件spout所需的executor數(shù)，通過公式依次求得后繼組件中的較優(yōu)的executor數(shù)；其中，nexecutori為第i個組件的executor數(shù)量，nexecutori-1為第i-1個組件的executor數(shù)量，vgenerate為前一組件的executor的tuple產生速度，通過監(jiān)控topology的運行數(shù)據(jù)然后取平均值獲得，t為一個周期開始后的時間，σ為通過多次試驗然后取得一個較優(yōu)的值，vproc為第i個組件中executor的tuple處理速度，通過監(jiān)控topology的運行數(shù)據(jù)然后取平均值獲得；s202：求得topology所需的executor總數(shù)；s203：根據(jù)storm官方建議每個worker中15個executor，求解得到topology所需的worker數(shù)。進一步，所述s3具體為：使用時間序列模型(autoregressiveinregratedmovingaverage，arima)預測topology要處理的數(shù)據(jù)量，arima(p,d,q)表示為：xt＝σ1xt-1+σ2xt-2+…+σpxt-p+ut-θ1ut-1-θ1ut-1-…-θqut，其中p為自回歸項數(shù)；q為滑動平均項數(shù)；xt-1,xt-2為xt的前期值；ut,ut-1,ut-2為xt在t期，t-1期，t-2期的隨機誤差項，是相互獨立的白噪聲序列；d是使原序列xt由非平穩(wěn)時間序列轉換為平穩(wěn)時間序列時對其成為平穩(wěn)序列所做的差分次數(shù)；σ1,σ2,…,σp為自回歸系數(shù)，θ1,θ2,…,θq為移動平均系數(shù)，是模型的待估參數(shù)。進一步，所述s4具體為：當獲得topology中各組件較優(yōu)的并行度后，進行storm任務調度；使用線上調度算法，在運行時，通過監(jiān)控獲得實時數(shù)據(jù)，包括executor的負載情況、executor的tuple接受率和發(fā)送率、集群中的節(jié)點負載；然后進行調度，在調度中最小化節(jié)點間的網(wǎng)絡通信，并保存集群中的節(jié)點負載均衡；所述線上調度算法具體為：將executor按照trafficload降序排列，然后按序依次將executor分配到負載最輕的slot上，同時每個workernode上同一個topology的executor會被分配到同一個slot上并且每個workernode不過載。本發(fā)明的有益效果在于：本發(fā)明克服了現(xiàn)有對topology中各組件間的關聯(lián)性考慮的不足，彌補了不能快速高效地求解到用戶提交topology中各組件的較優(yōu)并行度的不足，以及避免了對數(shù)據(jù)實時變化處理的忽視。本發(fā)明結合時間序列模型和線上調度算法，監(jiān)控topology的運行，建立模型，求解topology中worker數(shù)和各個組件的executor數(shù)，預測topology要處理的數(shù)據(jù)量并求解開始組件spout所需的executor數(shù)，將新得到topology任務通過storm中的線上調度策略進行調度。本發(fā)明具有提前預測變化的優(yōu)點，并能根據(jù)監(jiān)控得到的運行數(shù)據(jù)快速高效的求得topology中各組件的較優(yōu)并行度，從而提高了吞吐量，降低了處理時延。附圖說明為了使本發(fā)明的目的、技術方案和有益效果更加清楚，本發(fā)明提供如下附圖進行說明：圖1為本發(fā)明的示意圖；圖2為時間序列模型的簡圖；圖3為算法實施系統(tǒng)結構圖。具體實施方式下面將結合附圖，對本發(fā)明的優(yōu)選實施例進行詳細的描述。如圖3所示，本發(fā)明的實施包括三個模塊：topology監(jiān)控模塊、伸縮模塊和調度模塊。在topology監(jiān)控模塊中，可以調用nimbusclient的thrift接口獲取ui上對storm中各topology運行的監(jiān)控數(shù)據(jù)和ganglia集群監(jiān)控工具來獲得各節(jié)點和負載數(shù)據(jù)，然后我們將數(shù)據(jù)保存到數(shù)據(jù)庫mysql中，伸縮調整模塊在每個周期開始時通過前面周期保存在mysql中各topology的運行數(shù)據(jù)，然后通過上述模型求解該周期內topology的伸縮方案，然后進行調度。下面通過對微博中的詞語進行統(tǒng)計為例來對本發(fā)明進行具體實施說明：該實例中topology由三個組件構成，第一個組件是spout，命名為readerdata，用來讀取在kafka中的微博記錄，該實例中將讀取到的微博記錄通過nexttuple方法形成tuple發(fā)送到后面的bolt組件。第二個組件是bolt，命名為splitdata，它接收從spout發(fā)送過來的tuple，將這tuple中的微博分詞之后，將每個詞語再單獨發(fā)送出去。第三個組件也是bolt，命名為statdata，它負責接收從第二個組件發(fā)送的詞語，將這些詞語的出現(xiàn)次數(shù)進行統(tǒng)計，然后將結果寫入到日志中進行輸出。在本實例中使用kafka生產者讀取微博數(shù)據(jù)，然后發(fā)送到kafka服務器，kafka的消費者為spout，即readdata從kafka中獲取微博記錄。1、監(jiān)控模塊利用ganglia作為storm集群監(jiān)控工具，獲取storm集群中各節(jié)點的信息。同時storm集群自身會對運行的topology進行監(jiān)控，可以在stormui中查看到各個topology的運行信息，包括topology的work數(shù)、executor數(shù)、每個組件接受的tuple數(shù)、發(fā)送的tuple數(shù)、處理時間等。其中stormui中的所有數(shù)據(jù)，我們可以調用nimbusclient的thrift接口獲取，然后我們將獲取的實時數(shù)據(jù)保存到mysql數(shù)據(jù)庫中，供后面的伸縮模塊和調度模塊使用。本平臺中將監(jiān)控模塊獲取的各topology運行數(shù)據(jù)保存到mysql中，mysql數(shù)據(jù)庫在構建數(shù)據(jù)庫集群方面有著優(yōu)異的性能，可以用來解決海量數(shù)據(jù)處理中的高并發(fā)、低延遲、大體量等問題。為了降低延遲，我們采用java數(shù)據(jù)庫連接(javadatabaseconnectivity,jdbc)技術來實現(xiàn)連接的復用，這樣減少了數(shù)據(jù)庫連接和釋放的時間。在數(shù)據(jù)庫中建立表來存儲監(jiān)控得到的數(shù)據(jù)：表一監(jiān)控storm集群信息名類型idintsupervisor_numinttotal_slotintused_slotintexecutor_numint表一為監(jiān)控storm集群信息，包括從節(jié)點數(shù)量，總的slot數(shù)，可用的slot數(shù)，executor數(shù)量。表二監(jiān)控storm集群中運行的topology信息名類型idinttopology_namevarcharwork_numberintexecutor_numberinttask_numberint表二為監(jiān)控storm集群中運行的topology信息，包括topology的名稱，topology所需的work數(shù)，topology所需的executor數(shù)，topology所需的task數(shù)。表三監(jiān)控storm集群中運行topology的spout組件的信息表三為監(jiān)控storm集群中運行topology的spout組件的信息，包括spout組件的名稱，該組件所需的executor數(shù)量，該組件發(fā)送的tuple數(shù)量，該組件執(zhí)行時間。表四監(jiān)控storm集群中運行topology的bolt組件的信息名類型idintbolt_namevarcharexecutor_numberinttuple_compete_numinttuple_emitted_numinttuple_compete_numinttopology_namevarchar表四為監(jiān)控storm集群中運行topology的bolt組件的信息，包括bolt組件的名稱，該組件所需的executor數(shù)量，該組件完成的tuple數(shù)量，該組件發(fā)送的tuple數(shù)量，該組件執(zhí)行tuple所需的處理時間。表五監(jiān)控kafka中的運行信息名類型idintkafka_topologyvarcharrec_numintproc_numint表五為監(jiān)控kafka中的運行信息，包括消費的topology名稱，收到的消息數(shù)，被消費的消息數(shù)。2、伸縮模塊在該實例中，首先初始化該topology中各組件的并行度都為1。在周期t開始時進行伸縮調度或集群中某節(jié)點高負載時進行伸縮調度。在伸縮模塊中，從mysql中讀取數(shù)據(jù)，獲取參數(shù)的值，求得topology中三組件的并行度關系，然后再求得在該周期t內組件spout所需的executor數(shù)及bolt所需的executor數(shù)，最后獲得topology中各個組件較優(yōu)的并行度后，通過storm中的rebalance進行重調度。步驟一：求解topology中worker數(shù)和各個組件的executor數(shù)首先以穩(wěn)定的速率生成微博記錄到kafka，供topology中的組件spout讀取。第二個bolt組件中executor的tuple處理速度為vproc，即單位時間內處理tuple的數(shù)量。通過mysql中的統(tǒng)計值該組件完成的tuple數(shù)量tuple_complete_num可以獲得該組件的平均處理處理速率。則組件tuple處理速度為nexecutori*vproc，其中nexecutori是該組件的executor數(shù)量，即表四中executor_number的值。其前一組件spout的executor的tuple產生速度為vgenerate，即單位時間內產生tuple的數(shù)量。通過表三中spout的監(jiān)控數(shù)據(jù)tuple_emitted_num可以獲得該spout的平均產生速率。則該組件的tuple產生速度為nexecutori-1*vgeneate，其中nexecutori-1是該組件的executor數(shù)量，即表三中的executor_number的值。則由下列公式求得readerdata與splitdata的比值為x1:x2同理可求得splitdate與statdata的比值為x2:x3，則該topology中組件readerdata、splitdata、statdata的比值為：x1:x2:x3。最后求得topology所需的executor總數(shù)，根據(jù)storm官方建議每個worker中15個executor，求解得到topology所需的worker數(shù)。步驟二：預測topology要處理的數(shù)據(jù)流并求解開始組件spout所需的executor數(shù)模擬twitter一天中發(fā)微博的情況，對所發(fā)的微博記錄進行詞語統(tǒng)計。如圖2所示，在周期t開始時，使用時間序列模型arima(p,d,q)根據(jù)前面周期的數(shù)據(jù)到達速率進行預測本周期組件需要消費的數(shù)據(jù)量。在arima的各項系數(shù)p、d、q可以通過對歷史數(shù)據(jù)的訓練得到。影響時間序列的因素有很多，可能存在此消彼長、突然出現(xiàn)等現(xiàn)象，單憑一次訓練得到的模型很難反應時間序列的長期變化，因此預測模型采用邊訓練邊預測的方式，利用最新的歷史數(shù)據(jù),在預測前重新訓練，修正arima模型中各項系數(shù)，然后再進行預測得到外部數(shù)據(jù)到達kafka中的速率vcome。上一周期kafka中spout未處理完的數(shù)據(jù)量為datasurplus，可用表五中的rev_num和proc_num的差值獲得。組件spout的數(shù)據(jù)處理速率為nexucutori*vproc，其中nexecutori是組件spout的executor數(shù)量，vproc是單位時間內處理kafka中消息的數(shù)量。由下列公式知該周期開始t時間后spout組件的負載為：令load(t)＝σ1，σ1通過多次實驗取一個較優(yōu)的值，使得spout組件在該負載下，kafka中的消息能盡快得到處理，降低消息的處理時延。則由上式求得：在該周期內spout較優(yōu)的executor數(shù)y1，然后由步驟一中求得的readerdata、splitdata、statdata的比值，求得splitdata、statdata較優(yōu)的executor數(shù)分別為y2、y3。則該topology所需的executor數(shù)量為y1+y2+y3，所需的work數(shù)量為大于(y1+y2+y3)/15的最小整數(shù)。然后判斷是否需要進行伸縮調整，如果需要伸縮調整則調用storm中的reblance功能進行動態(tài)調整。3、調度模塊當調用storm中的reblance后會進行新的調度。用戶提交topology到storm集群后，計算時延在很大程度上取決于executor之間傳輸tuple的時延。線上調度算法通過減少網(wǎng)絡傳輸?shù)膖uple的數(shù)量，即將相互通信的源executor和目標executor分配到相同的workernode上，能夠極大的提升storm集群的計算性能。在統(tǒng)計微博詞語的topology中readdata的task所在的executor會發(fā)送tuple給splitdata的task所在的executor，splitdata的task所在的executor會發(fā)送tuple給statdata的task所在的executor。假設運行時readdata、splitdata、statdata中task所對應的executor分別為e1、e2、e3，那么e1、e2、e3為相互通信的executor組，為了減少網(wǎng)絡傳輸tuple的數(shù)量，應該將它們分配到同一節(jié)點上。如圖1所示，具體步驟如下：采集運行周期t內，相互通信的executor之間的tuple傳輸速率；利用采集到的信息按照executor的傳輸速率進行降序排序。循環(huán)遍歷executor，如果相互通信的executor在同一工作節(jié)點上，則對不進行調度；如果不在同一工作節(jié)點，則將相互通信的executor調度到同一工作節(jié)點上；監(jiān)控各executor所在的節(jié)點的負載進行降序排列。當相互通信的executor不在同一工作節(jié)點時調度到當前負載最低的workernode上。直到所有executor都被處理后調度結束。最后說明的是，以上優(yōu)選實施例僅用以說明本發(fā)明的技術方案而非限制，盡管通過上述優(yōu)選實施例已經對本發(fā)明進行了詳細的描述，但本領域技術人員應當理解，可以在形式上和細節(jié)上對其作出各種各樣的改變，而不偏離本發(fā)明權利要求書所限定的范圍。當前第1頁12