本發(fā)明涉及一種基于資源重用的MapReduce短作業(yè)優(yōu)化系統(tǒng)及方法。

背景技術：
互聯(lián)網、金融及媒體等行業(yè)正在面臨著處理大規(guī)模數據集的挑戰(zhàn)，但常規(guī)的數據處理工具和計算模型不能滿足其要求。Google提出的MapReduce模型為其提供了一個有效的解決方案，Hadoop是MapReduce的開源實現。Hadoop將提交的作業(yè)分解為粒度更小的Map任務和Reduce任務，這些任務在集群中的多個節(jié)點上并行運行，因此極大的縮短了作業(yè)的運行時間。Hadoop隱藏了并行計算的細節(jié)——向計算節(jié)點分發(fā)數據，重新運行失敗的任務等，讓用戶能夠專注于具體的業(yè)務邏輯處理。而且，Hadoop提供良好的線性擴展、數據冗余以及計算的高容錯性，這些優(yōu)點使得Hadoop成為運行數據密集型和計算密集型應用的主流計算框架。Hadoop在工業(yè)界的成功促使學術界開始密切關注Hadoop，并對其設計和實現的不足提出改善建議。Hadoop的初始設計目標是在大量計算節(jié)點中并行處理規(guī)模較大的作業(yè)，然而實際生產中，Hadoop卻經常被用來處理規(guī)模較小的短作業(yè)。短作業(yè)是指完成時間小于設定閾值的作業(yè)，閾值一般由用戶自行設置。規(guī)模小的短作業(yè)與規(guī)模大的作業(yè)在多個方面存在差異，比如輸入數據集的大小、作業(yè)分解的任務數、任務需要的資源量、任務的完成時間以及用戶對作業(yè)完成時間的期望等。由于Hadoop并未考慮短作業(yè)的特點，導致短作業(yè)在Hadoop中運行的性能比較低效。影響作業(yè)運行性能因素有多個方面，其中集群節(jié)點的配置、作業(yè)的調度算法和集群的負載是比較關鍵的三個因素。Hadoop在調度任務時假定構成集群的節(jié)點是同構的，即每個節(jié)點的CPU、內存、磁盤等硬件的配置相同。然而，隨著公司業(yè)務的拓展集群的規(guī)模逐漸擴大，新增節(jié)點的配置明顯高于前期節(jié)點的配置。因此，相同的任務在不同節(jié)點上執(zhí)行，任務的完成時間相差較大。在集群高負載的情況下，作業(yè)分解的所有任務不能立即申請到運行任務的資源，部分任務進入等待資源的隊列。獲得資源的任務執(zhí)行完成后釋放占用的資源，Hadoop根據調度算法從等待隊列中選擇合適的任務將可用的資源分配給選擇的任務。因此，若作業(yè)分解的任務比較多，同一個作業(yè)分解的任務可能執(zhí)行運行多輪才能完成。例如在TaoBao的Hadoop集群中，Map任務運行兩輪以上的作業(yè)占30％以上。因此，集群的負載情況對作業(yè)的響應時間和完成時間具有決定性的影響。最近幾年，優(yōu)化MapReduce作業(yè)的執(zhí)行性能逐漸成為研究熱點，大量研究工作從多個方面提升作業(yè)的執(zhí)行效率，比如Hadoop的框架、作業(yè)的調度算法、作業(yè)的運行過程以及硬件加速器等。Piranha基于作業(yè)歷史數據總結出小作業(yè)的特點——任務數少和失敗率低?，F有技術中有基于任務數少的特點優(yōu)化小作業(yè)的執(zhí)行流程，比如Map任務和Reduce任務同時啟動、Map任務的中間結果直接寫到Reduce任務端。由于小作業(yè)的失敗率低于1％，采用了簡易的容錯機制——若作業(yè)運行失敗，Piranha重新執(zhí)行整個作業(yè)而不是失敗的任務?，F有技術中有將批處理作業(yè)分解為大量的微小任務，每個任務只處理8M的數量，任務可以在數秒內完成計算。由于任務輸入的數據量小、運行時間短，任務不存在數據傾斜和落后任務的問題，同時解決了交互式作業(yè)長時間等待資源的不足。Tenzing為減少MapReduce作業(yè)的周轉時間，提供一組作業(yè)進程池。新作業(yè)提交后，Tenzing的調度器從作業(yè)進程池中選擇一個空閑的進程運行提交的作業(yè)。使用進程池降低了啟動新作業(yè)的成本，但Tenzing存在兩個缺點：一個是預留的進程數超過實際需要，浪費了集群的資源；另一個是限制了Tenzing的調度器只能使用某些具體的進程，損害了任務本地計算的特性。現有技術中有分析了Hadoop計算框架運行短作業(yè)存在的不足，提出從Hadoop的框架方面改善短作業(yè)的運行效率。論文從三個方面進行優(yōu)化：1)將setup任務和cleanup任務改為在主節(jié)點運行，避免通過心跳消息改變作業(yè)的狀態(tài)，作業(yè)的完成時間直接縮短了一個心跳周期；2)將任務分配從“拉”模式改為“推”模式，減少任務分配的延遲；3)將主節(jié)點和從節(jié)點之間的控制消息從當前的心跳消息機制中獨立出來，采用即時傳遞機制。Spark也是處理大規(guī)模數據集的計算框架，具有運行DAG圖的引擎。Spark與Hadoop的差異是Spark基于內存計算，spark將作業(yè)的中間結果存儲在內存中而不是本地磁盤或者HDFS中，DAG圖中的后繼作業(yè)直接從內存中讀取輸入數據進行計算。SpongeFiles的目標是緩解數據傾斜的問題，但在減少作業(yè)運行時間方面效果非常顯著?，F有技術中有引入分布式內存，Map任務的輸出結果優(yōu)先寫到分布式內存中，減少數據寫入本地磁盤消耗的時間和shuffle階段讀取Map任務中間結果的時間。該方法對Map任務輸出數據較大的作業(yè)優(yōu)化效果明顯，但對只有Map任務和Map任務輸出數據量小的作業(yè)沒有明顯的效果?，F有技術中都是通過減少磁盤IO來提高作業(yè)的執(zhí)行效率。Sparrow的設計目標是提供低延遲的任務調度。Sparrow在每個節(jié)點中長期運行部分任務進程，由長期運行的任務進程執(zhí)行新任務，降低任務進程頻繁啟動的成本。長期運行的任務進程數由用戶靜態(tài)的設定或是由資源管理器根據集群的負載自動調整。Quincy是任務級別的調度器，與Sparrow類似。Quincy為了計算最優(yōu)的調度順序將調度問題映射為一張圖，調度時綜合考慮數據的位置，公平性和饑餓問題。與Sparrow相比，Quincy計算調度順序時間更長。Hadoop的作業(yè)調度算法對作業(yè)的運行時間有重要的影響。FIFO調度算法根據作業(yè)的提交時間順序調度作業(yè)。由于FIFO沒有考慮作業(yè)之間的差異，導致執(zhí)行小作業(yè)和交互式作業(yè)的性能比較低效。FAIR調度算法保證用戶提交的作業(yè)公平的共享集群資源，確保短作業(yè)在合理的時間內完成，避免作業(yè)出現饑餓問題。但FAIR調度算法沒有考慮集群的異構性和作業(yè)具有時間約束的情況。HFSP在作業(yè)運行時評估作業(yè)的大小，將小作業(yè)設置為高優(yōu)先級的作業(yè)，保證小作業(yè)在最短的時間內完成。作業(yè)的優(yōu)先級隨著時間動態(tài)的調整，防止作業(yè)出現饑餓現象。

技術實現要素：
本發(fā)明的目的就是為了解決上述問題，提供一種基于資源重用的MapReduce短作業(yè)優(yōu)化系統(tǒng)及方法，它從提高資源有效利用方面優(yōu)化短作業(yè)運行性能，減少資源分配和回收的頻率，將資源分配和回收的時間用來運行短作業(yè)，通過減少作業(yè)等待資源時間，提高執(zhí)行短作業(yè)的性能。為了實現上述目的，本發(fā)明采用如下技術方案：一種基于資源重用的MapReduce短作業(yè)優(yōu)化系統(tǒng)，包括：主節(jié)點、一級從節(jié)點和若干個二級從節(jié)點，其中主節(jié)點與一級從節(jié)點連接，一級從節(jié)點與若干個二級從節(jié)點連接；所述主節(jié)點上部署資源管理器和一級任務調度器；所述一級從節(jié)點上部署應用管理器、任務性能評估器和二級任務調度器，其中二級任務調度器與任務性能評估器連接，二級任務調度器還與主節(jié)點連接；每個所述二級從節(jié)點上均部署節(jié)點管理器。所述資源管理器負責全局資源的的分配和監(jiān)控，以及應用管理器的啟動和監(jiān)控。所述一級任務調度器用于按照任務的優(yōu)先級高低、任務所需資源、任務提交時間順序等進行作業(yè)隊列的調度。所述應用管理器把作業(yè)分解為Map任務和Reduce任務，同時還為Map任務和Reduce任務申請資源，與節(jié)點管理器配合運行，還用于對任務進行監(jiān)控。應用管理器是作業(yè)運行的控制單元，每個作業(yè)對應一個應用管理器。所述任務性能評估器，基于任務性能模型預測正在運行的任務和未調度的任務的完成時間。所述二級任務調度器，根據任務性能評估器的預測結果判斷正在執(zhí)行的任務是否屬于短任務以及從未調度的任務隊列中選擇任務。若正在執(zhí)行的任務是短任務，二級任務調度器從未調度的任務隊列中選擇新的短任務，新的短任務重新利用當前正在執(zhí)行的短任務即將釋放的資源；若正在執(zhí)行的任務不是短任務，正在執(zhí)行的任務執(zhí)行完成后直接釋放所占用的資源。二級任務調度器在選擇未調度任務時，需要考慮任務的本地性、任務的運行時間、資源的公平性和集群的異構性。節(jié)點管理器負責監(jiān)控任務使用的資源量，防止任務運行過程中使用的資源量超過任務申請的資源量。一種基于資源重用的MapReduce短作業(yè)優(yōu)化方法，包括如下步驟：步驟(1)：應用管理器通過心跳消息向資源管理器申請資源；步驟(2)：資源管理器將閑置的資源分配給申請資源的應用管理器，應用管理器獲取申請到的資源；步驟(3)：應用管理器把申請到的資源分配給未調度的任務，然后應用管理器通知對應的節(jié)點管理器啟動任務進程；步驟(4)：節(jié)點管理器啟動任務進程運行任務，任務在運行的過程中每間隔設定的心跳周期向所屬的應用管理器發(fā)送心跳消息，所述心跳消息包括任務的進度、任務統(tǒng)計數據和任務健康狀態(tài)；任務統(tǒng)計數據是指已處理的數據量、已輸出的數量、已消耗的時間、溢寫IO速率；任務健康狀態(tài)是指執(zhí)行任務的進程是否異常；步驟(5)：應用管理器收到心跳消息，基于任務性能評估器中的任務完成時間預測模型來預測任務的運行時間，若任務的運行時間小于等于用戶設定的任務完成時間，則當前任務是短任務；否則當前任務是長任務；若當前任務是短任務，二級任務調度器從未調度的任務隊列中選擇新任務；若當前任務是長任務，就忽略心跳消息；步驟(6)：應用管理器將選擇的新任務通知任務進程，任務進程執(zhí)行完正在運行的任務后繼續(xù)運行新任務；步驟(7)：若任務進程執(zhí)行完正在運行的任務后未接收到新任務，任務進程退出并釋放占用的資源，節(jié)點管理器通過心跳消息將釋放的資源通知資源管理器。所述步驟(4)的任務在運行的過程中每間隔設定的心跳周期向所屬的應用管理器發(fā)送心跳消息的步驟為：步驟(401)：判斷任務進度是否超過設定閾值，若任務進度超過設定閾值，計算當前任務的統(tǒng)計數據，發(fā)送統(tǒng)計心跳消息，轉步驟(403)；否則轉步驟(402)；所述當前任務的統(tǒng)計數據包括任務已處理的數量、已運行時間和輸出數據量；步驟(402)：任務的進度未超過設定閾值，發(fā)送任務健康心跳消息；進入步驟(404)；步驟(403)：任務收到應用管理器的心跳消息；進入步驟(404)；步驟(404)：判斷任務進程進行是否收到新任務，若任務進程收到新任務，轉步驟(405)；否則轉(406)；步驟(405)：將新任務的輸入數據讀取到當前節(jié)點；在當前任務執(zhí)行完成后，運行新接收到的任務；步驟(406)：若任務進程沒有收到新任務，當前任務執(zhí)行完成后，任務進程釋放任務占用的資源。所述步驟(5)的基于任務性能評估器中的任務完成時間預測模型來預測任務的運行時間：假如任務的運行過程可劃分為多個子階段，任務的完成時間與任務在子階段消耗的時間密切相關，因此根據任務在子階段消耗的時間建立任務完成時間預測模型；任務的運行過程劃分為多個子階段，若子階段之間不存在重疊，任務的完成時間為各個子階段的時間之和；若子階段之間存在重疊，要去除重疊的部分；假如任務i的運行過程分解為n個子階段，每個子階段處理的數據量用向量s表示，s＝[s1，s1，…，sn]，每個子階段處理數據的速率用向量r表示，r＝[r1，r1，…，rn]。任務i的完成時間Ti為：其中，α為啟動任務的時間，在固定的范圍內變化，是一個常量。Map任務的運行過程分解為四個子階段，分別為讀取輸入數據階段，運行map操作階段，輸出數據溢寫階段，中間結果文件合并階段，各階段分別用read，map，spill，combine表示。根據公式(1)計算Map任務i的完成時間Ti：對于短任務而言，中間結果文件合并階段運行時間非常小，看做常量。讀取輸入數據階段和map操作階段處理的數量相同，為任務的輸入數據量stask。由于map操作階段與輸出數據溢寫階段存在部分重疊，溢寫階段的數據量取map操作之后輸出的數量，即最后一次溢寫的數量。設已處理的輸入數據量，為已輸出的數據量，sbuffer配置項設定的緩存大小，為最后一次溢寫的數據量，公式(2)演變?yōu)椋?![CDATA[Ti=stask(1rread+1rmap)+sspilllastrspill+β---(3)]]>其中，stask為任務的輸入數據量大小，β為常量，rread，rmap，rspill從任務端發(fā)送的統(tǒng)計心跳消息中獲取。為i階段已處理的數據量，為在i階段已消耗的時間。當應用管理器收到任務端發(fā)送的統(tǒng)計心跳消息時，根據公式(3)計算當前任務的完成時間。假如任務k在節(jié)點w上運行，預測未調度的任務m在節(jié)點w運行的完成時間時，任務m各個子階段的處理速率為所述步驟(5)的二級任務調度器從未調度的任務隊列中選擇新任務的步驟包括：步驟(51)：按任務的本地性將未調度的任務分為節(jié)點本地任務，機架本地任務，其他機架任務；如果任務的輸入數據在處理任務的節(jié)點上，稱該任務為節(jié)點本地任務；如果任務的輸入數據與處理任務的節(jié)點在同一個機架內，稱為該任務為機架本地任務；如果任務的輸入數據與處理任務的節(jié)點不在同一個機架內，稱為該任務為其他機架任務；再按照節(jié)點本地任務、機架本地任務、其他機架任務的順序選擇任務，優(yōu)先選擇每個優(yōu)先級中運行時間最小的任務；步驟(52)：根據異構性原則選擇最優(yōu)任務。所述步驟(51)的步驟為：步驟(511)：應用管理器收到任務進程發(fā)送的統(tǒng)計心跳消息，轉步驟(512)；步驟(512)：任務性能評估器預測發(fā)送心跳任務的完成時間，轉步驟(513)；步驟(513)：若發(fā)送心跳任務的完成時間小于設定的時間，則計算未調度任務在運行當前作業(yè)的全部節(jié)點上運行時間，轉步驟(514)；步驟(514)：將未調度任務按照本地性分別加入到節(jié)點本地任務隊列、機架本地任務隊列和其他機架任務隊列，轉步驟(515)；本地性是指任務的輸入數據與處理節(jié)點是否相同，是否在一個機架內；步驟(515)：按照任務的運行時間對節(jié)點本地任務隊列、機架本地任務隊列和其他機架任務隊列排序；轉步驟(516)；步驟(516)：根據任務的本地性優(yōu)先級，判斷未調度任務是否屬于最優(yōu)任務，若是最優(yōu)任務則將當前選擇的未調度任務從未調度列表中刪除，返回該任務；否則判斷下一個未調度的任務，直到檢查完全部未調度任務。所述步驟(52)的步驟為：步驟(521)：計算輸入任務在運行當前作業(yè)的全節(jié)點上的運行時間，轉步驟(522)；步驟(522)：獲取計算輸入任務運行時間最短的節(jié)點，轉步驟(523)；步驟(523)：判斷獲取的節(jié)點與輸入的節(jié)點是否相同，如果相同，返回任務是最優(yōu)任務；否則轉步驟(524)；步驟(524)：計算任務從輸入節(jié)點轉移到運行任務時間最短的節(jié)點上運行的收益，若收益超過設定的閾值，返回輸入任務是最優(yōu)任務；否則返回輸入任務不是最優(yōu)任務。所述任務的本地性是指：任務的輸入數據與處理節(jié)點在同一個節(jié)點稱為本地任務；若在同一個機架稱為機架本地任務；不在一個機架內稱為其他機架任務。就是任務的輸入數據與處理節(jié)點是何種關系。所述任務轉移運行收益是指：是指若任務在其他節(jié)點運行，運行時間比在原節(jié)點運行時間更短。縮短的這部分時間稱為收益。所述最優(yōu)任務是指：是這在當前節(jié)點運行時間最短的任務。本發(fā)明的有益效果：對Hadoop進行優(yōu)化，提高短作業(yè)的運行效率。首先，本發(fā)明通過分析Hadoop中作業(yè)的執(zhí)行過程，對短作業(yè)處理過程中存在的問題進行描述。然后，根據高負載情況下任務運行多輪的特點，提出一種基于資源重用的短作業(yè)優(yōu)化機制——通過對已執(zhí)行任務所釋放資源的重用，減少資源在分配和回收過程中的浪費。在集群高負載的情況下，運行多輪的任務中Map任務占的比例遠高于Reduce任務，因此本發(fā)明只優(yōu)化Map任務。實驗結果表明，本發(fā)明提出的基于資源重用的短作業(yè)優(yōu)化方法能夠有效的減少短作業(yè)的運行時間，并顯著提高了集群資源的利用率。附圖說明圖1為長任務運行時序圖；圖2為短作業(yè)計算框架；圖3為短任務執(zhí)行流程時序圖；圖4(a)為任務的進程取不同的值時，任務性能模型預測正在運行的任務的誤差變化情況；圖4(b)為任務運行時間與誤差之間的關系；圖5(a)為詞頻統(tǒng)計作業(yè)運行時間；圖5(b)為HiveSQL轉化的作業(yè)運行時間；圖5(c)為短作業(yè)優(yōu)化的作業(yè)運行時間；圖6為計算節(jié)點CPU利用率；圖7為計算節(jié)點內存利用率。具體實施方式下面結合附圖與實施例對本發(fā)明作進一步說明。Hadoop是一種用于處理大規(guī)模數據集的并行計算平臺，具備良好的擴展性、高容錯性、易編程等優(yōu)點。雖然其初始設計目標是在大量計算節(jié)點中并行處理規(guī)模較大的作業(yè)，然而在實際生產中，Hadoop卻經常被用來處理規(guī)模較小的短作業(yè)。由于Hadoop并未考慮短作業(yè)的特點，導致短作業(yè)在Hadoop中執(zhí)行比較低效。針對上述挑戰(zhàn)，本發(fā)明首先通過分析Hadoop中作業(yè)的執(zhí)行過程，對短作業(yè)處理過程中存在的問題進行描述。然后，根據高負載情況下任務運行多輪的特點，提出一種基于資源重用的短作業(yè)優(yōu)化機制——通過對已執(zhí)行任務所釋放資源的重用，減少資源在分配和回收過程中的浪費。實驗結果表明，本發(fā)明提出的基于資源重用的短作業(yè)優(yōu)化方法能夠有效的減少短作業(yè)的運行時間，并顯著提高了集群資源的利用率。本發(fā)明基于Hadoop2.x版本對短作業(yè)進行優(yōu)化。本節(jié)首先分析Hadoop的計算框架和任務執(zhí)行的過程，然后描述Hadoop執(zhí)行短作業(yè)存在的問題。Hadoop采用主從結構，由一個主節(jié)點和多個從節(jié)點組成，參考圖2。資源管理器(ResourceManager)運行在主節(jié)點上，負責全局資源的分配和監(jiān)控，以及應用管理器的啟動和監(jiān)控。應用管理器(ApplicationMaster)運行在從節(jié)點上，其職責是把作業(yè)分解為Map任務和Reduce任務、為Map任務和Reduce任務申請資源、與節(jié)點管理器配合運行和監(jiān)控任務。應用管理器是作業(yè)運行的控制單元，每個作業(yè)對應一個應用管理器。節(jié)點管理器(NodeManager)也運行在從節(jié)點上，負責監(jiān)控任務使用的資源量(如內存，CPU等)，防止任務運行過程中使用的資源量超過任務申請的資源量。圖1描述了應用管理器為任務申請資源和任務運行過程。①應用管理器將作業(yè)劃分為Map任務和Reduce任務，通過心跳消息向資源管理器申請資源。②資源管理器按照某種調度算法從申請資源的任務隊列中選擇合適的任務，并將閑置的資源分配給選擇的任務，應用管理器在下一次心跳消息時獲取申請到的資源。③應用管理器把申請的資源分配給適合的任務，然后通知資源所在節(jié)點的節(jié)點管理器啟動任務。④節(jié)點管理器啟動任務進程運行任務，任務在運行的過程中間隔心跳周期向所屬的應用管理器匯報任務的進度和健康狀態(tài)。⑤任務完成后釋放任務占用的資源，由節(jié)點管理器通過心跳消息將釋放的資源歸還給資源管理器。從上述任務的執(zhí)行過程得知，運行時間短的任務和運行時間長的任務都遵從上述過程，但運行時間短的任務按照上述過程執(zhí)行存在如下問題：1)任務啟動成本高。應用管理器為任務申請資源至少需要一個心跳周期(默認為3秒)，從應用管理器通知節(jié)點管理器運行任務到任務初始化完成需要1～2秒。在Taobao的集群中運行時間低于10秒的Map任務占50％以上，在Yahoo！的即席查詢和數據分析集群中大量Map任務的平均完成時間是20左右秒，因此任務的啟動時間占總時間的20％(5/25)以上。在任務申請資源時，若資源管理器沒有可以用的資源，任務需要排隊等待可用資源，這將導致任務啟動成本進一步增加。而任務排隊等待可用資源的現象在集群中經常發(fā)生。2)資源浪費嚴重。已執(zhí)行完的任務釋放所占用的資源，由節(jié)點管理器間隔一個心跳周期將釋放的資源歸還給資源管理器。資源管理器把閑置的資源分配給等待資源的任務，任務所屬的應用管理器間隔一個心跳周期才能獲得申請的資源。從啟動任務進程到任務初始化完成需要1～2秒，所以釋放的資源再次被重新利用需要7～8秒，其中心跳周期為3秒。因此，集群頻繁的執(zhí)行運行時間短的任務，將導致集群資源的嚴重浪費。根據上述分析，當前Hadoop執(zhí)行任務的流程不適合執(zhí)行運行時間短的任務。為了方便描述問題，我們?yōu)檫\行時間短的任務引入一個新概念——短任務。定義1.設任務i的完成時間為Ti，用戶設定任務完成時間為TshortTask，若任務的完成時間滿足Ti≤TshortTesk，稱任務i為短任務。短作業(yè)是由大量的短任務構成，運行大量的短任務降低了短作業(yè)的執(zhí)行性能。根據高負載情況下任務運行多輪的特點，本發(fā)明提出一種基于資源重用的短作業(yè)優(yōu)化機制——通過對已執(zhí)行任務所釋放資源的重用，減少資源在分配和回收過程中的浪費。重用資源的任務得到提前運行，從而減少了作業(yè)的運行時間。1資源重用的短作業(yè)計算框架本節(jié)描述資源重用的短作業(yè)計算框架和短作業(yè)的任務執(zhí)行過程。任務運行需要一定數量的資源，包括內存、CPU、網絡、磁盤存儲空間、任務進程等，這些資源都可以被未調度的任務使用。由于不同作業(yè)的任務需要的資源數量有差別，本發(fā)明只考慮同一個作業(yè)的Map任務之間進行資源重用。1.1短作業(yè)計算框架在Hadoop的框架中，應用管理器是一個作業(yè)的控制中心，負責為任務申請資源、與節(jié)點管理器配合執(zhí)行和監(jiān)控任務。本發(fā)明在應用管理器中增加兩個組件——任務性能評估器(TaskPerformanceEstimator)和二級任務調度器(Sub-scheduler)，框架如圖2所示。任務性能評估器基于任務性能模型預測兩類任務的完成時間——正在運行的任務和未調度的任務。因為資源重用的機制只適用于短任務，根據短任務的定義需要任務的運行時間，而該時間在任務完成之前是未知的。未調度的任務在設定節(jié)點的運行時間是二級任務調度器選擇任務的關鍵依據，其計算結果直接影響任務的調度順序。由于任務可劃分為多個子階段，任務性能模型是基于任務子階段消耗的時間建立的。任務執(zhí)行的過程中，不間斷的收集統(tǒng)計數據，計算任務在各個子階段消耗的時間。二級任務調度器的職責是根據任務性能評估器的預測結果判斷正在執(zhí)行的任務是否屬于短任務，以及從未調度的任務隊列中選擇任務。若正在執(zhí)行的任務是短任務，二級任務調度器從未調度的任務隊列中選擇合適的任務重用短任務即將釋放的資源。二級任務調度器在選擇未調度任務時，綜合考慮任務的本地性、任務的運行時間、資源的公平性和集群的異構性問題。1.2短作業(yè)的任務執(zhí)行過程圖3描述了短作業(yè)的任務執(zhí)行流程。①應用管理器通過心跳消息向資源管理器申請資源。②資源管理器將閑置的資源分配給申請資源的任務，應用管理器在下一次心跳消息時獲取申請到的資源。③應用管理器把申請的資源分配給適合的任務，然后通知對應的節(jié)點管理器啟動任務。④節(jié)點管理器啟動任務進程運行任務，任務在運行的過程中間隔心跳周期向所屬的應用管理器匯報任務的進度、任務統(tǒng)計數據和健康狀態(tài)。⑤應用管理器收到心跳消息，若當前任務是短任務，二級任務調度器從未調度的任務隊列中選擇合適的任務。⑥應用管理器將選擇的任務通知任務進程，任務進程執(zhí)行完正在運行的任務后繼續(xù)運行新接收到的任務。⑦任務進程執(zhí)行完正在運行的任務后未接收到新任務，任務進程退出并釋放占用的資源，節(jié)點管理器通過心跳消息將釋放的資源通知資源管理器。短作業(yè)計算框架不影響長任務的執(zhí)行，但長任務仍然遵循圖1描述的過程執(zhí)行，圖3描述的過程只適用于短任務。2資源重用的短作業(yè)優(yōu)化實現根據短作業(yè)計算框架的設計，要在應用管理器端和任務進程分別實現。應用管理器端的實現基于任務進程收集的統(tǒng)計數據，本節(jié)首先介紹任務進程心跳消息的實現，然后介紹應用管理器端任務性能模型和二級任務調度器的實現。2.1任務進程心跳消息任務與應用管理器基于心跳消息通信，心跳消息的內容包括任務的進度、任務的健康狀況等信息。任務性能模型預測任務的完成時間基于任務運行過程中的統(tǒng)計數據——已處理的輸入數量、已輸出的數據量、任務輸出率、讀取輸入數據的速率、map操作的速率和溢寫輸出數據的速率等信息。因為正常的心跳消息發(fā)送頻率比較高，為了緩解應用管理器的壓力，本發(fā)明在任務與應用管理器之間增加一種統(tǒng)計心跳消息，負責將統(tǒng)計數據發(fā)送給應用管理器。統(tǒng)計心跳消息只有任務的進度超過設定的閾值時才發(fā)送。算法1.sendHeartbeat算法.輸入：發(fā)送統(tǒng)計心跳消息的最小任務進度，由用戶設定；當前任務的進度；輸出：心跳消息步驟101：若任務進度超過設定的閾值，計算當前任務的統(tǒng)計數據(任務已處理的數量、已運行時間、輸出數據量等)，發(fā)送統(tǒng)計心跳消息，轉步驟103；否則轉步驟102；步驟102：任務的進度未超過設定閾值，發(fā)送任務健康心跳消息；步驟103：任務收到應用管理器的心跳消息；步驟104：若任務進程收到新任務，轉步驟105；否則轉106；步驟105：將新任務的輸入數據讀取到當前節(jié)點。在當前任務執(zhí)行完成后，運行新接收到的任務；步驟106：若任務進程沒有收到新任務，當前任務執(zhí)行完成后任務進程釋放任務占用的資源。算法1描述了任務進程發(fā)送心跳消息的過程，curTask為當前正在運行的任務，newTask為新接收的任務。在任務的進度超過設定的閾值時，計算任務已處理的數量、輸出的數據量、讀寫速率等統(tǒng)計數據，然后向應用管理器發(fā)送統(tǒng)計心跳消息。任務進程在收到應用管理器反饋的心跳消息時，檢查是否收到新任務。若任務進程收到新任務，將新任務的輸入數據提前讀取到當前節(jié)點。讀取新任務輸入數據的操作與正在運行任務并行執(zhí)行，避免執(zhí)行新任務時再讀取數據。正在運行的任務完成后，繼續(xù)執(zhí)行新接收到的任務。若任務進程未接收到新任務，正在運行的任務運行完成后釋放占用的資源。2.2任務完成時間預測模型假如任務的運行過程可劃分為多個子階段，任務的完成時間與任務在子階段消耗的時間密切相關，因此本發(fā)明根據任務在子階段消耗的時間建立任務性能模型。任務的運行過程可以劃分為多個子階段，若子階段之間不存在重疊，任務的完成時間為各個子階段的時間之和；若子階段之間存在重疊，要去除重疊的部分。假如任務i的運行過程分解為n個子階段，每個子階段處理的數據量用向量s表示，s＝[s1，s1，…，sn]，每個子階段處理數據的速率用向量r表示，r＝[r1，r1，…，rn]。任務i的完成時間Ti為：其中，α為啟動任務的時間，該值在固定的范圍內變化，可以看做一個常量。Map任務的運行過程分解為四個子階段，分別為讀取輸入數據階段，運行map操作階段，輸出數據溢寫階段，中間結果文件合并階段，各階段分別用read，map，spill，combine表示。根據公式(1)計算Map任務i的完成時間Ti：對于短任務而言，中間結果文件合并階段運行時間非常小，可以看做常量。讀取輸入數據階段和map操作階段處理的數量相同，為任務的輸入數據量stask。由于map操作階段與輸出數據溢寫階段存在部分重疊，溢寫階段的數據量取map操作之后輸出的數量，即最后一次溢寫的數量。設已處理的輸入數據量，為已輸出的數據量，sbuffer配置項設定的緩存大小，為最后一次溢寫的數據量，公式(2)演變?yōu)椋?![CDATA[Ti=stask(1rread+1rmap)+sspilllastrspill+β---(3)]]>其中，stask為任務的輸入數據量大小，β為常量，rread，rmap，rspill從任務端發(fā)送的統(tǒng)計心跳消息中獲取。為i階段已處理的數據量，為在i階段已消耗的時間。當應用管理器收到任務端發(fā)送的統(tǒng)計心跳消息時，根據公式(3)可以計算當前任務的完成時間。假如任務k在節(jié)點w上運行，預測未調度的任務m在節(jié)點w運行的完成時間時，任務m各個子階段的處理速率為2.3二級任務調度器應用管理器收到任務發(fā)送的統(tǒng)計心跳消息后，基于任務性能模型預測任務的運行時間。若發(fā)送統(tǒng)計心跳消息的任務是短任務，從未調度的任務隊列中選擇合適的任務。本節(jié)描述選擇未調度任務的過程，在選擇任務時綜合考慮任務本地性、集群的異構性和資源的公平性三個方面的問題。問題1.任務的本地性。任務的運行時間是讀取輸入數據的時間和計算輸入數據的時間之和，因此減少讀取輸入數據的時間能夠縮短任務的運行時間。在集群中，本地磁盤的IO速率比網絡的傳輸速率高，同一個機架內的網絡帶寬比機架之間的網絡帶寬大，所以在分配任務時要盡量將任務分配給靠近輸入數據的節(jié)點。該策略不但能夠減少數據拷貝的時間，而且也能緩解網絡的負載。因此，二級任務調度器按照節(jié)點本地任務、機架本地任務、其他機架任務的順序選擇任務。定義2.任務轉移運行收益。設任務i在節(jié)點a的運行時間為在節(jié)點b的運行時間為任務i由在節(jié)點a運行轉移到在節(jié)點b運行的收益為若為正值，說明任務i由節(jié)點a運行轉移到節(jié)點b運行時間縮短；為任務轉移運行的收益程度，值越大收益越高。若為負值，說明任務運行時間延長。定義3.在某個節(jié)點運行的最優(yōu)任務。在節(jié)點a運行的任務i滿足(6)或(7)，則稱任務i為在節(jié)點a運行的最優(yōu)任務。其中，X為運行當前作業(yè)的節(jié)點集合，m為運行任務i時間最短的節(jié)點。(6)說明任務在a節(jié)點的運行時間最小，(7)說明任務i在運行時間最短的節(jié)點運行的收益小于設定的收益閾值。算法2.assignTask算法輸入:未分配的任務集合；輸出:將要調度的任務；步驟201：應用管理器收到任務進程發(fā)送的統(tǒng)計心跳消息，轉步驟202；步驟202：任務性能評估器預測發(fā)送心跳任務的完成時間，轉步驟203；步驟203：若發(fā)送心跳任務的完成時間小于設定的時間，則計算未調度任務在運行當前作業(yè)的全部節(jié)點上運行時間，轉步驟204；步驟204：將未調度任務按照本地性分別加入到節(jié)點本地任務隊列、機架任務隊列和其他任務隊列，轉步驟205；步驟205：按照任務的運行時間對節(jié)點本地任務隊列、機架任務隊列和其他任務隊列排序；轉步驟206步驟206：根據任務本地性優(yōu)先級，判斷未調度任務是否屬于最優(yōu)任務，若是最優(yōu)任務則從未調度列表中刪除，返回該任務；否則判斷下一個未調度的任務，直到檢查完全部未調度任務。問題2.集群的異構性。集群的異構性是指集群節(jié)點的硬件配置不一致，硬件主要指CPU，內存，磁盤三項。集群的異構性對任務的執(zhí)行效率有重要的影響。同一個任務在性能高的節(jié)點執(zhí)行與在性能低的節(jié)點執(zhí)行相比，前者的運行時間與后者的運行時間差異巨大。二級任務調度器在選擇未調度任務時，檢查選擇的任務對于某個節(jié)點是否為最優(yōu)任務。若選擇的任務為最優(yōu)任務就執(zhí)行該任務；否則跳過該任務，重新選擇要執(zhí)行的任務。問題3.資源的公平性。資源的公平性是指各個作業(yè)公平的共享集群資源。由于集群是異構的，各節(jié)點的計算能力差異較大，要避免某個作業(yè)長時間占用性能高或性能低的節(jié)點資源。為了公平共享資源，由用戶設定資源的最大的重用時間，資源的重用時間是相同的。為資源的最大的重用時間，為任務在節(jié)點x上的平均運行時間，資源的重用次數為任務在各個節(jié)點的平均運行時間不同，所以各節(jié)點中資源的重用次數不同，在性能高的節(jié)點中的資源重用次數多。二級任務調度器分兩步選擇未調度的任務。第一步是按任務的本地性將未調度的任務分為節(jié)點本地任務，機架本地任務，其他機架任務。再按照本地性優(yōu)先級順序選擇任務，優(yōu)先選擇每個優(yōu)先級中運行時間最小的任務，見算法2。第二步是根據異構性原則選擇最優(yōu)任務，見算法3。算法2中，k為運行任務i的節(jié)點，為任務i使用資源的重用次數，dasknode為節(jié)點本地任務集合，Taskrack為機架本地任務集合，TaskoffRack為其他機架任務集合，為資源的最大重用時間，由用戶設定。算法2描述了應用管理器收到心跳消息選擇未調度任務的過程。首先判斷發(fā)送心跳消息的任務是否為短任務，以及資源的重用次數是否超過最大值。然后將未調度的任務分為節(jié)點本地任務，機架本地任務，其他機架任務三組，最后按照本地性的優(yōu)先級選擇任務。算法3：selectOptimalTask算法.輸入：運行當前作業(yè)的節(jié)點集合；用戶設定的最小收益；選擇的任務；運行當前任務的節(jié)點；輸出:選擇的任務是否為最優(yōu)任務.步驟301：計算輸入任務在運行當前作業(yè)的全節(jié)點上的運行時間，轉步驟302；步驟302：獲取計算輸入任務運行時間最短的節(jié)點，轉步驟303；步驟303：判斷獲取的節(jié)點與輸入的節(jié)點是否相同，如果相同，返回任務是最優(yōu)任務；否則轉步驟304；步驟304：計算任務從輸入節(jié)點轉移到運行任務時間最短的節(jié)點上運行的收益，若收益超過設定的閾值，返回輸入任務是最優(yōu)任務；否則返回輸入任務不是最優(yōu)任務。算法3描述了選擇的任務對當前節(jié)點而言是否為最優(yōu)任務。首先，計算選擇的任務在運行當前作業(yè)的其他節(jié)點上的運行時間，判斷選擇的任務在當前節(jié)點上的運行時間是否為最小。若選擇的任務在節(jié)點m上的運行時間最小，計算任務在節(jié)點m上執(zhí)行的收益。若任務的收益超過設定的閾值，則跳過選擇的任務；否則在當前節(jié)點執(zhí)行選擇的任務。3實驗與分析本發(fā)明基于Hadoop2.2.0實現短作業(yè)的優(yōu)化，優(yōu)化前的版本(ApacheHadoop)稱為AH，優(yōu)化后的版本稱為SJH。我們用SJH與AH對比的方式評估短作業(yè)的優(yōu)化效果。實驗集群由1個主節(jié)點和8個計算節(jié)點組成，節(jié)點的主要配置如表1所示。主節(jié)點和四個計算節(jié)點的使用配置一，其余四個計算節(jié)點使用配置二。節(jié)點分布在兩個機架中，節(jié)點之間使用千兆網連接。HDFS的數據塊大小為64M，數據塊的副本數設置為3。集群使用Hadoop提供的FAIR調度器，運行Map任務需要1G內存和1個CPU的資源，Reduce任務和應用管理器分別需要1.5G內存和1個CPU的資源。表1集群節(jié)點配置信息實驗使用兩個測試數據集，數據集一由Hadoop提供的randomtextwriter生成，數據集二為某省電力終端采集系統(tǒng)采集的用戶用電數據。randomtextwriter用來生成設定數據量的數據集，數據集的內容由隨機的單詞組成。實驗使用詞頻統(tǒng)計(wordcount)，Hive的單表條件查詢和Terasort作為基準測試程序。Hive是構建在HDFS之上的數據倉庫，Hive提供的類SQL被轉換為Hadoop作業(yè)。Hive的單表條件查詢語句轉換為Hadoop作業(yè)后，只有Map任務。詞頻統(tǒng)計用于統(tǒng)計每個單詞在輸入數據集中出現的頻率，Terasort對輸入數據集按字典順序排序。3.1任務性能模型的準確性本發(fā)明首先測試任務性能模型預測正在運行的任務和未運行任務的準確性。使用詞頻統(tǒng)計程序作為基準測試程序，采用數據集一，數據量大小為2.5G，集群使用40個Map任務處理數據集。實驗使用相對誤差描述準確性，e為誤差大小，為任務的預測完成時間，Ti為任務實際的完成時間。在任務的進度pmin分別為40％，60％，70％，80％時，預測正在運行任務完成時間的誤差。圖4(a)描述了任務的進程取不同的值時，任務性能模型預測正在運行的任務的誤差變化情況。由圖4(a)看見，誤差隨著進度的增加而減小，而且誤差趨于穩(wěn)定。任務的進度超過60％，誤差在20％以內；任務的進度超過70％時，誤差在10％左右。圖4(b)描述任務運行時間與誤差之間的關系。誤差隨著任務運行時間的增加而增加，在任務的完成時間達到80秒時，誤差超過20％。而且預測未運行任務的誤差要高于預測正在運行任務的誤差。任務性能模型使用短時間內的讀速率、map操作處理速率和溢寫速率計算任務的完成時間，而未考慮速率隨時間的變化情況。因此，任務性能模型的預測誤差會隨著任務時間的增加而增大。從圖4(b)中得知，任務完成時間低于30秒時預測誤差小于15％，而短任務的平均完成時間為20秒，因此該預測模型滿足實際需要。3.2作業(yè)完成時間我們在短作業(yè)和長作業(yè)混合運行的情況下測試短作業(yè)優(yōu)化效果，測試數據如表2所示。實驗使用shell腳本輪詢提交基準測試程序，每秒提交1個作業(yè)，所有作業(yè)在30秒內提交完成。集群提供的總容器數量為96個，因此每個作業(yè)的Map任務需要多輪才能調度完成。圖5(a)和圖5(b)顯示了短作業(yè)優(yōu)化對作業(yè)完成時間的影響。詞頻統(tǒng)計作業(yè)運行時間縮短了6％-22％，HiveSQL轉化的作業(yè)運行時間縮短了6％-27％。這個兩種作業(yè)是短作業(yè)，Hive單表條件查詢只有Map任務，其優(yōu)化效果比詞頻統(tǒng)計作業(yè)更好。從圖5(c)中可以看出，短作業(yè)優(yōu)化對長作業(yè)沒有顯著的影響，作業(yè)最大的延長時間為5％。短任務優(yōu)化操作使得短作業(yè)的任務搶占了資源，導致長作業(yè)完成時間有部分延長。表2作業(yè)測試數據3.3資源的利用率本節(jié)關注計算節(jié)點的CPU和內存的利用率，基準測試程序和數據集如表2所示。資源的利用率使用Ganglia收集，最終的結果取在計算過程中各個資源的平均值。圖6為計算節(jié)點的CPU利用情況，優(yōu)化后的CPU利用率平均提高了4％-13％?；鶞蕼y試程序中，詞頻統(tǒng)計和HiveSQL轉換的作業(yè)屬于計算密集型作業(yè)。N1、N2、N6和N7節(jié)點的CPU利用率提高的幅度大于N3、N4、N5和N8提高的幅度，因為前者是性能高的節(jié)點，后者是性能低的節(jié)點。圖7描述了計算節(jié)點內存的變化，優(yōu)化后內存的利用率提高了2.6％-6.18％。內存利用率提高的幅度不大，因為基準測試程序中只有terasort的輸出數據比較大。實驗測試結果表明，本發(fā)明提出的優(yōu)化短作業(yè)方法在改善集群資源有效利用方面效果明顯。4總結由于Hadoop并未考慮短作業(yè)的特點，導致短作業(yè)在Hadoop中執(zhí)行比較低效。針對上述挑戰(zhàn)，本發(fā)明首先通過分析Hadoop中作業(yè)的執(zhí)行過程，對短作業(yè)處理過程中存在的問題進行描述。然后，根據高負載情況下任務運行多輪的特點，提出一種基于資源重用的短作業(yè)優(yōu)化機制——通過對已執(zhí)行任務所釋放資源的重用，減少資源在分配和回收過程中的浪費。本發(fā)明通過優(yōu)化Map任務執(zhí)行過程，減少短作業(yè)的運行時間。未來的工作將從Reduce任務的執(zhí)行過程和任務調度方面來提高短作業(yè)的執(zhí)行效率。上述雖然結合附圖對本發(fā)明的具體實施方式進行了描述，但并非對本發(fā)明保護范圍的限制，所屬領域技術人員應該明白，在本發(fā)明的技術方案的基礎上，本領域技術人員不需要付出創(chuàng)造性勞動即可做出的各種修改或變形仍在本發(fā)明的保護范圍以內。