一種具有集群自適應性的Storm任務部署與配置平臺的制作方法
【專利摘要】一種具有集群自適應性的Storm任務部署與配置平臺，屬于實時流數據計算處理領域。通過運用此平臺，Storm集群可感知節點間內部通信量大小與剩余資源，并結合用戶發布的topology任務需求與集群剩余資源進行運行進程數目配置自調節，從而達到突破以往Storm調度方法都需要人為指定進程數目的限制。該平臺向用戶提供了一個友好的、集中式通信量監控接口，方便用戶在任務程序中調用，實現負載和資源感知。另外在此平臺內嵌實現了與以往Storm兩階段提交調度方法都不同的一階段提交調度方法，實現了同一節點不同進程之間通信量優化。本發明只需要設定基本的優化閾值參數即可實現最優化的調度，極大的便利了集群用戶和管理者。
【專利說明】
一種具有集群自適應性的Storm任務部署與配置平臺
技術領域
[0001]涉及一種具有集群自適應性的Storm任務部署與配置平臺，屬于海量數據處理、實時流計算領域。
【背景技術】
[0002]伴隨著信息科技的發展，信息呈現爆發式增長。在很多信息處理問題中都需要對流式大數據進行實時的復雜計算，這是一種新的數據模式，與傳統數據建模方式不同，這類數據適用瞬態數據流建模。例如微博熱門、購物推薦、路由器數據報的統計等場景都需要在實時流數據上進行復雜的決策。
[0003]在傳統的數據處理模式中，數據往往獨立于應用，由系統負責將數據集中存儲到磁盤中，數據是靜態的、固定的集合。而流計算的核心價值在于對海量“運動”中的數據進行連續實時處理，顯然這些數據的產生速度和規模都已超出了傳統分布式系統的處理能力。
[0004]Storm是由Twitter公司開源的針對流數據實時處理的計算框架，是工業界技術最成熟的流計算框架之一。一個基本的Storm程序topology在結構上是一個邊表示數據流，點代表計算組件的有向圖。計算組件有兩種:spout和bolt，spout是一個topology的數據tuple源頭，bolt負責接收處理。每個bolt或者spout的實例化對象被稱為一個task，一個或多個task由包含在JVM進程worker中的JAVA線程executor執行，worker對應著storm的邏輯概念slot。為保證數據處理的低延遲性，Storm對數據的處理完全基于內存。
[0005]Storm集群在流計算上有著卓越的成效，但在使用時需要用戶在topology任務中配置運行進程數目，這個設定可能會造成諸多問題。
[0006](I)運行進程數目過多，可能會導致運行topology的節點過多，通信開銷過大。這個問題同時也顯現在Storm現有的一些調度優化的方法上。所有優化方法，其調度的先提條件是由用戶決定運行進程數。如果運行進程數設定過多，會導致executor會散部到更多節點之上，這勢必會造成節點間通信量增大，無論如何進行優化，都很難達到一個理想的調度方案。
[0007 ] (2)如果運行進程數設置的過少，executor會集中到少數的一個或幾個worker，這樣一方面可能會帶來線程上下文切換的開銷，更重要的一方面是可能會導致部分節點由于運行executor超載而導致宕機。如果工作節點宕機，其上的任務會由于Storm的可靠性保障機制而得到重做，高頻率的任務重做也會導致較大的處理時延。
[0008]據我們所知，目前還沒有任何方法可以很好的解決這個難題。現有的方法都集中在對Storm任務的調度問題上，忽略了對任務進程數目的設置，它們都需要用戶在編寫topology程序時明確地指定為該任務配置的運行進程數目。這是因為現有的所有調度算法都是遵照兩階段提交的設計思想，第一階段:executor安排到worker (slot)，第二階段:worker安排到node。而executor安排到worker的前提是需要知道worker的數目。雖然這些調度算法在一定程度上能夠緩解節點過載與進程內部通信開銷等問題，但是不能從根本上解決這個問題。因為由于用戶無法實時的對集群的全局狀態信息進行掌控，在這種情況下盲目地對任務設定運行進程數目，勢必會對集群處理性能造成更嚴重的影響。
[0009]實際上，設定運行進程數目，應該結合任務本身需求以及集群剩余資源來決定。本發明致力于此難點，提出一種具有集群自適應性的Storm任務部署與配置平臺能夠很好的解決此項難題。
[0010]本平臺設計實現了對集群節點間通信量監控，并提供監控數據給調度方法，以便調度方法能夠計算出通信量最小的調度方案;設計實現了配置自調節功能，部署本平臺之后，集群可以依據監控模塊提供的集群資源信息并結合任務本身需要而計算出最佳的配置。在此配置下，結合監控到的通信量數據可以計算出真正意義上的通信量最小的最佳調度方案。在此平臺中我們也內嵌實現了基于這兩項功能而實現的一階段提交調度算法，該算法與以往的優化算法相比還有一個優勢:該算法考慮到同一節點中不同進程之間的通信，以往的優化調度算法沒有考慮此通信量，實際上，不同線程只有在同一進程中通過共享內存傳遞數據才不會產生通信量。
[0011]采用本平臺的好處有:
[0012](I)通過平臺可實現通信量優化，提高了集群處理性能。
[0013](2)簡化集群用戶操作，用戶不需在編寫topology任務時進行過多的參數配置，使用戶可以專注于topology任務的編程。
[0014](3)方便了集群管理，減少了用戶任務的不合理配置，集群也減少了節點超載宕機的可能，這樣集群更加穩定。
[0015](4)平臺向下兼容，具有很好的移植性。以往Storm組織架構不需要任何變動，只需要在原topology任務中調用本平臺API，修改一下配置文件即可使用本平臺。
【發明內容】
[0016]為克服Storm計算框架現有調度算法的種種不足以及突破必須由用戶指定運行進程數目的限制。本發明提出一種具有集群自適應性的Storm任務部署與配置平臺。通過運用此平臺，Storm集群可感知節點間內部通信量大小與剩余資源，并結合用戶發布的topology任務需求與集群剩余資源進行運行進程數目配置自調節，從而達到突破以往Storm調度方法都需要人為指定進程數目的限制。該平臺向用戶提供了一個友好的、集中式通信量監控接口，方便用戶在任務程序中調用，實現負載和資源感知。另外在此平臺內嵌實現了與以往Storm兩階段提交調度方法都不同的一階段提交調度方法，實現了同一節點不同進程之間通信量優化。與其他Storm優化調度方法復雜的參數配置要求不同，本發明只需要設定基本的優化閾值參數即可實現最優化的調度，極大的便利了集群用戶和管理者。
[0017]首先，要想實現基于內部通信量的任務調度，必須能夠在拓撲任務運行時持續監測節點間內部通信量。然而Storm計算框架源碼沒有實現相關功能或提供有關調用接口。本方法為用戶提供一個友好的、集中式的集群監控API供用戶在拓撲中調用，自動下發監測任務到集群的各個工作節點，每個工作節點都會運行一個監控線程，在拓撲運行在集群機器上時，監控線程還收集了節點CPU利用率信息和節點間通信量一起定時寫入緩存數據庫中。
[0018]其次，Storm計算框架的缺省調度方法以及其他Storm優化調度方法都依賴用戶指定運行進程個數，人為設定運行進程具有盲目性，極易造成內部通信量過大，優化效果不明顯的問題。本平臺添突破了此項限制，設計實現了任務配置自調節功能。在任務分配時依據監控功能收集到的信息以及任務本身需求，進行任務配置調整，最終為整個集群的任務調度提供一個合理的任務配置參數。
[0019]再次，Storm計算框架的缺省調度方法以及其他Storm優化調度方法通過完成executor到slot分配、slot到node的分配這兩個階段才能完成調度。這就造成了在同一工作節點上的executor可能會被分配在不同的進程中。雖然這時沒有節點通信開銷，但是會存在進程間通信開銷。從Storm源碼可以看到分配在同一個s lot中的executor是通過共享內存來傳遞數據。所以，本方法采用獨特的executor到node分配的一階段提交調度算法，確保同一拓撲任務在同一節點上的executor都會被分配到同一個slot中去，從而達到減小進程間通信開銷。
[0020 ]本發明解決技術問題所采用的技術方案是:
[0021]一種具有集群自適應性的Storm任務部署與配置平臺，架構邏輯上分為資源層、數據層、應用層、用戶層四個層次。
[0022]資源層主要包括硬件資源Storm集群以及部署在主控節點上的用以緩存監控數據以及集群資源信息的MySQL數據庫，在storm集群每個工作節點上的監控線程由拓撲任務下發時觸發;數據層通過JAVA對象從監控線程獲取數據，通過JDBC驅動對數據庫進行讀寫;數據層包括節點管理、通信量管理、數據管理三大模塊;應用層分三個子模塊:感知模塊、調度模塊、計算模塊；用戶層上，主要是監控API和集群配置文件，配置文件是集群自有配置文件storm.yaml，用戶需要在這里配置使用本方法，而監控API供用戶編程時調用；
[0023]該Storm任務部署與配置平臺的工作流程包括三個部分:
[0024](I)主要工作流程:檢測當前是否達到觸發計算重調度的時間閾值，如果沒達到則繼續調用Storm源碼中的事物調度否則開計算最佳調度方案，在計算出最佳調度方案會進行觸發調度的原因判斷，如果是由于集群中某些節點過載引起的則直接觸發重調度;如果是因為內部通信量的優化，則還需要進行一次判斷，只有優化效果超過了用戶規定的閾值，才會觸發重調度；進行重調度時，會先釋放所有工作節點上的可用端口，然后會對邏輯executor和物理executor進行匹配并按計算出的最佳分配方案進行物理安排；
[0025](2)配置調節流程:先判斷是否是初次分配，如果是初次分配，則利用初始配置嘗試進行分配，如果不能完成分配，則依據CHJ負載將超出的executor數目按比例分配到節點，增大調整這些節點上的最大可運行executor數目；如果不是初次分配，則需要獲取歷史分配方案并嘗試調整運行拓撲的節點個數，嘗試折半減少節點個數成功后，所有的executor數目按CPU負載比例調整這些節點上的可運行最大executor數目；
[0026](3)計算最佳調度方案的流程:先進行配置調節然后再轉入具體分配流程;分配流程開始是獲取內部executor通信列表，此列表的元素是executorPair，此列表由數據層的通信量管理模塊編譯所得，每個executorPair是由兩個有通信的executor組成，并記錄其間通信量，也就是傳遞的tuple個數;循環遍歷此列表，對于每個executorPair做以下處理:executorPair中的兩個executor分別為el、e2，判斷el、e2是否都未被安排，如果都未被安排，則先判斷是否有最近使用節點IastUsedNode，如果沒有最近使用節點IastUsedNode，則尋找能夠承載el和e2負載的最小負載節點IeastLoadedNode分配el、e2，如果不能找到IeastLoadedNode則el、e2分別分配到能夠負載其負載的最小負載節點，分配e2的節點被指定為最近使用節點；如果找到能夠承載el和e2負載的最小負載節點，則el、e2都分配到此節點，并將此節點指定為最近使用節點；如果存在IastUsedNode，則先要檢測IastUsedNode能否同時承載e1、e2，如果可以則都分配到IastUsedNode，如果不能則尋找能夠承載el、e2的最小負載節點IeastLoadedNode，如果存在，分配el和e2到此節點，并指定此節點為最近使用節點；如果不存在，則el、e2分開分配到不同節點，優先使用最近使用節點其次是能夠承載其負載的最小負載節點；如果el、e2至少有一個已經被安排，則獲取已經被安排的executor所在的節點列表nodeList，獲取能夠承載el、e2中較大的負載的最小負載節點IeastLoadedNode，判斷IeastLoadedNode和IastUsedNode是否在nodeList中，如果不在，則將其加入nodeList;嘗試將el、e2分配到nodeList中任意一個或兩個節點，計算分配后的內部通信量，遍歷所有的安排方法，尋找最小通信量分配方案，如果出現內部通信量一樣小的情況優先使用包含IastUsedNode的分配方案，記錄最小的內部通信量以及相應的分配方案，最后被分配的最佳安排節點被指定為最近使用節點；如此循環直至內部executor通信列表被完整遍歷，所有executor得到分配。
[0027]本項發明未改動Storm計算框架原架構，對以往的拓撲任務有良好的移植性與繼承性。本發明的方法部署實施極其便利，用戶只需在拓撲任務中調用API即可實現對內部通信量以及集群資源的監控。緩存數據庫和調度算法生成器都部署在主控節點，并且該方法支持熱插拔，用戶只需在主控節點更改配置文件即可實現方法切換。在很多環境下，Storm集群都已部署完畢并已投入生產，如果輕易改動原有的架構或者部署會給用戶帶來極大的不便，甚至造成不必要的損失。
【附圖說明】
[0028]圖1是系統架構圖
[0029]圖2是平臺工作流程圖
[0030]圖3是配置調節流程圖[0031 ]圖4是計算最佳調度流程圖
【具體實施方式】
[0032]下面結合附圖對本專利進行具體實施說明。
[0033]如圖1所示，該發明系統架構邏輯上分為資源層、數據層、應用層、用戶層四個層次。
[0034]資源層主要包括硬件資源Storm集群以及部署在主控節點上的用以緩存監控數據以及集群資源信息的MySQL數據庫，在storm集群每個工作節點上的監控線程由拓撲任務下發時觸發。
[0035]數據層通過JAVA對象從監控線程獲取數據，通過JDBC驅動對數據庫進行讀寫。數據層包括節點管理、通信量管理、數據管理三大模塊。節點管理的主要作用是從數據管理獲取節點數據，進行再封裝，以便計算最佳分配時向應用層提供多種參數情況下獲取最小負載節點的查詢服務。數據管理模塊的作用是讀寫MySQL數據庫的基本數據，作為其他模塊與數據庫交互的中介，提供了對拓撲、負載、通信量、歷史分配、節點信息的讀取和存儲服務。數據管理模塊還為算法生成器提供返回內部executor通信量列表、內部節點通信量列表、過載節點查詢服務。通信量管理為當次調度邏輯計算提供中間數據，此模塊編譯當次調度的內部executor通信量列表和內部節點通信量列表，executor的安排和移除會直接影響此模塊上的中間數據。此模塊還提供包含executor的節點查詢服務以及當前分配的查詢服務。
[0036]應用層分三個子模塊:感知模塊、調度模塊、計算模塊。感知模塊包括任務監控、進程監控、資源監控是監控API的具體實現。任務監控中的對象會封裝線程ID以及task ID，另外提供tuple發送通知函數和tuple接收記錄函數。用戶在拓撲的spout節點調用tuple發送通知函數，在bo 11節點調用tup I e接受記錄函數，從而實現線程之間傳遞的tup I e個數。進程監控模塊維護一個任務監控的列表，負責匯總線程間通信量并寫入通信量管理和數據管理模塊。具體步驟是:監控線程對b ο 11接收到的t u PI e做簡單的解析，根據t u PI e的發出executor、接收executor以及兩者之間傳遞的tuple個數編譯內部executor通信列表，然后定時寫入緩存數據庫中。資源監控是對集群工作節點的CPU負載資源、可運行線程數目的監控，采用定時上報和行為觸發兩種方式實現監控數據讀寫，資源監控線程每個一段時間收集工作節點上的負載和運行線程數目信息并寫入數據管理模塊，在觸發重調度時會實時寫入一次數據。調度模塊里主要包含實現調度的邏輯操作，通過此模塊編譯出nodePair、executorPair便于計算通信量。executor安排與移除是基本的調度邏輯操作。計算模塊中主要提供配置參數調節的計算以及最佳調度方案的計算。算法生成器在配置調節器給出參數數值之后會運用調度模塊提供的基本操作，進行調度嘗試，最終得到最佳的調度方法，后文會詳細說明計算流程。
[0037]用戶層上，主要是監控API和集群配置文件，配置文件是集群自有配置文件storm.yaml，用戶需要在這里配置使用本方法，而監控API供用戶編程時調用。
[0038]如圖2所示，平臺的主要流程是:檢測當前是否達到觸發計算重調度的時間閾值，如果沒達到則繼續調用Storm源碼中的事物調度否則開計算最佳調度方案，在計算出最佳調度方案會進行觸發調度的原因判斷，如果是由于集群中某些節點過載引起的則直接觸發重調度;如果是因為內部通信量的優化，則還需要進行一次判斷，只有優化效果超過了用戶規定的閾值，才會觸發重調度。進行重調度時，會先釋放所有工作節點上的可用端口，然后會對邏輯executor和物理executor進行匹配并按計算出的最佳分配方案進行物理安排。
[0039]如圖3所示，配置調節流程是:先判斷是否是初次分配，如果是初次分配，則利用初始配置嘗試進行分配，如果不能完成分配，則依據CPU負載將超出的executor數目按比例分配到節點，增大調整這些節點上的最大可運行executor數目。如果不是初次分配，則需要獲取歷史分配方案并嘗試調整運行拓撲的節點個數，嘗試折半減少節點個數成功后，所有的executor數目按CPU負載比例調整這些節點上的可運行最大executor數目。
[0040]如圖4所示，計算最佳調度方案的流程是:先進行配置調節然后再轉入具體分配流程。分配流程開始是獲取內部executor通信列表，此列表的元素是executorPair，此列表由數據層的通信量管理模塊編譯所得，每個executorPair是由兩個有通信的executor組成，并記錄其間通信量，也就是傳遞的tuple個數。循環遍歷此列表，對于每個executorPair做以下處理:executorPair中的兩個executor分別為el、e2，判斷el、e2是否都未被安排，如果都未被安排，則先判斷是否有最近使用節點IastUsedNode，如果沒有最近使用節點IastUsedNode，則尋找能夠承載el和e2負載的最小負載節點IeastLoadedNode分配el、e2，如果不能找到IeastLoadedNode則el、e2分別分配到能夠負載其負載的最小負載節點，分配e2的節點被指定為最近使用節點。如果找到能夠承載el和e2負載的最小負載節點，則el、e2都分配到此節點，并將此節點指定為最近使用節點。如果存在IastUsedNode，則先要檢測IastUsedNode能否同時承載el、e2，如果可以則都分配到IastUsedNode，如果不能則尋找能夠承載el、e2的最小負載節點IeastLoadedNode，如果存在，分配el和e2到此節點，并指定此節點為最近使用節點。如果不存在，則el、e2分開分配到不同節點，優先使用最近使用節點其次是能夠承載其負載的最小負載節點。如果el、e2至少有一個已經被安排，則獲取已經被安排的executor所在的節點列表nodeList，獲取能夠承載el、e2中較大的負載的最小負載節點IeastLoadedNode，判斷IeastLoadedNode和IastUsedNode是否在nodeList中，如果不在，則將其加入nodeList。嘗試將el、e2分配到nodeList中任意一個或兩個節點，計算分配后的內部通信量，遍歷所有的安排方法，尋找最小通信量分配方案，如果出現內部通信量一樣小的情況優先使用包含IastUsedNode的分配方案，記錄最小的內部通信量以及相應的分配方案，最后被分配的最佳安排節點被指定為最近使用節點。如此循環直至內部executor通信列表被完整遍歷，所有executor得到分配。
【主權項】
1.一種具有集群自適應性的storm任務部署與配置平臺，其特征在于:該Storm任務部署與配置平臺架構邏輯上分為資源層、數據層、應用層、用戶層四個層次； 資源層主要包括硬件資源Storm集群以及部署在主控節點上的用以緩存監控數據以及集群資源信息的MySQL數據庫，在storm集群每個工作節點上的監控線程由拓撲任務下發時觸發； 數據層通過JAVA對象從監控線程獲取數據，通過JDBC驅動對數據庫進行讀寫；數據層包括節點管理、通信量管理、數據管理三大模塊;節點管理的主要作用是從數據管理獲取節點數據，進行再封裝，以便計算最佳分配時向應用層提供多種參數情況下獲取最小負載節點的查詢服務;數據管理模塊的作用是讀寫MySQL數據庫的基本數據，作為其他模塊與數據庫交互的中介，提供了對拓撲、負載、通信量、歷史分配、節點信息的讀取和存儲服務;數據管理模塊還為算法生成器提供返回內部executor通信量列表、內部節點通信量列表、過載節點查詢服務;通信量管理為當次調度邏輯計算提供中間數據，此模塊編譯當次調度的內部executor通信量列表和內部節點通信量列表，executor的安排和移除會直接影響此模塊上的中間數據;此模塊還提供包含executor的節點查詢服務以及當前分配的查詢服務；應用層分三個子模塊:感知模塊、調度模塊、計算模塊;感知模塊包括任務監控、進程監控、資源監控是監控API的具體實現;任務監控中的對象會封裝線程ID以及task ID，另外提供tuple發送通知函數和tuple接收記錄函數；用戶在拓撲的spout節點調用tuple發送通知函數，在bolt節點調用tuple接受記錄函數，從而實現線程之間傳遞的tuple個數;進程監控模塊維護一個任務監控的列表，負責匯總線程間通信量并寫入通信量管理和數據管理模塊；具體步驟是:監控線程對b ο 11接收到的t u PI e做簡單的解析，根據t u PI e的發出executor、接收executor以及兩者之間傳遞的tuple個數編譯內部executor通信列表，然后定時寫入緩存數據庫中；資源監控是對集群工作節點的CPU負載資源、可運行線程數目的監控，采用定時上報和行為觸發兩種方式實現監控數據讀寫，資源監控線程每個一段時間收集工作節點上的負載和運行線程數目信息并寫入數據管理模塊，在觸發重調度時會實時寫入一次數據；調度模塊里主要包含實現調度的邏輯操作，通過此模塊編譯出nodePair、executorPair便于計算通信量;executor安排與移除是基本的調度邏輯操作;計算模塊中主要提供配置參數調節的計算以及最佳調度方案的計算;算法生成器在配置調節器給出參數數值之后會運用調度模塊提供的基本操作，進行調度嘗試，最終得到最佳的調度方法； 用戶層上，主要是監控AP I和集群配置文件，配置文件是集群自有配置文件storm.yaml，用戶需要在這里配置使用本方法，而監控API供用戶編程時調用； 該Storm任務部署與配置平臺的工作流程包括三個部分: (1)主要工作流程:檢測當前是否達到觸發計算重調度的時間閾值，如果沒達到則繼續調用Storm源碼中的事物調度否則開計算最佳調度方案，在計算出最佳調度方案會進行觸發調度的原因判斷，如果是由于集群中某些節點過載引起的則直接觸發重調度;如果是因為內部通信量的優化，則還需要進行一次判斷，只有優化效果超過了用戶規定的閾值，才會觸發重調度;進行重調度時，會先釋放所有工作節點上的可用端口，然后會對邏輯executor和物理executor進行匹配并按計算出的最佳分配方案進行物理安排； (2)配置調節流程:先判斷是否是初次分配，如果是初次分配，則利用初始配置嘗試進行分配，如果不能完成分配，則依據CPU負載將超出的executor數目按比例分配到節點，增大調整這些節點上的最大可運行executor數目；如果不是初次分配，則需要獲取歷史分配方案并嘗試調整運行拓撲的節點個數，嘗試折半減少節點個數成功后，所有的executor數目按CPU負載比例調整這些節點上的可運行最大executor數目； (3)計算最佳調度方案的流程:先進行配置調節然后再轉入具體分配流程;分配流程開始是獲取內部executor通信列表，此列表的元素是executorPair，此列表由數據層的通信量管理模塊編譯所得，每個executorPair是由兩個有通信的executor組成，并記錄其間通信量，也就是傳遞的tupIe個數；循環遍歷此列表，對于每個executorPair做以下處理:executorPair中的兩個executor分別為el、e2，判斷el、e2是否都未被安排，如果都未被安排，則先判斷是否有最近使用節點IastUsedNode，如果沒有最近使用節點IastUsedNode，則尋找能夠承載el和e2負載的最小負載節點IeastLoadedNode分配el、e2，如果不能找到IeastLoadedNode則el、e2分別分配到能夠負載其負載的最小負載節點，分配e2的節點被指定為最近使用節點；如果找到能夠承載el和e2負載的最小負載節點，則el、e2都分配到此節點，并將此節點指定為最近使用節點；如果存在IastUsedNode，則先要檢測IastUsedNode能否同時承載e1、e2，如果可以則都分配到IastUsedNode，如果不能則尋找能夠承載el、e2的最小負載節點IeastLoadedNode，如果存在，分配el和e2到此節點，并指定此節點為最近使用節點；如果不存在，則el、e2分開分配到不同節點，優先使用最近使用節點其次是能夠承載其負載的最小負載節點；如果el、e2至少有一個已經被安排，則獲取已經被安排的executor所在的節點列表nodeList，獲取能夠承載el、e2中較大的負載的最小負載節點IeastLoadedNode，判斷IeastLoadedNode和IastUsedNode是否在nodeList中，如果不在，則將其加入nodeList;嘗試將el、e2分配到nodeList中任意一個或兩個節點，計算分配后的內部通信量，遍歷所有的安排方法，尋找最小通信量分配方案，如果出現內部通信量一樣小的情況優先使用包含IastUsedNode的分配方案，記錄最小的內部通信量以及相應的分配方案，最后被分配的最佳安排節點被指定為最近使用節點；如此循環直至內部executor通信列表被完整遍歷，所有executor得到分配。
【文檔編號】G06F17/30GK106021411SQ201610318426
【公開日】2016年10月12日
【申請日】2016年5月13日
【發明人】李克秋, 鄧衍, 齊恒, 李文信
【申請人】大連理工大學