本發(fā)明屬于計算機軟件領域，涉及一種基于hadoop平臺下動態(tài)標簽匹配dlms調度方法的設計與實現(xiàn)。

背景技術：

早期hadoop版本由于將資源調度管理和mapreduce框架整合在一個模塊中，導致代碼的解耦性較差，不能很好的進行擴展，不支持多種框架。hadoop開源社區(qū)設計實現(xiàn)了一種全新架構的新一代hadoop系統(tǒng)，該系統(tǒng)為hadoop2.0版本，將資源調度抽取出來構建了一個新的資源調度框架，即新一代的hadoop系統(tǒng)yarn。眾所周知在某一確定的環(huán)境下合適的調度算法能夠在滿足用戶作業(yè)請求的同時，有效的提升hadoop作業(yè)平臺的整體性能和系統(tǒng)的資源利用率。在yarn中默認自帶三種調度器：先入先出(fifo)、公平調度器(fairscheduler)和計算能力調度器(capacityscheduler)。hadoop默認采用的是fifo調度器，該算法采用先進先出的調度策略，簡單易實現(xiàn)，但是不利于短作業(yè)的執(zhí)行，不支持共享集群和多用戶管理；由facebook提出的公平調度算法考慮不同用戶與作業(yè)資源配置需求的差異，支持用戶公平共享集群的資源，但是作業(yè)資源的配置策略不夠靈活，容易造成資源的浪費，并且不支持作業(yè)搶占；雅虎提出的計算能力調度算法支持多用戶共享多隊列，計算能力靈活，但是不支持作業(yè)搶占易陷入局部最優(yōu)。

然而在實際的企業(yè)生產中，隨著企業(yè)的數(shù)據(jù)量加大，每年集群都會加入一些新節(jié)點，但是集群節(jié)點的性能差異是顯著的，這種異構集群在企業(yè)生產環(huán)境中很普遍。設想如果將一個計算量很大的機器學習的任務分配在cpu計算能力很差的機器節(jié)點上，顯然會影響作業(yè)的整體執(zhí)行時間。hadoop自帶的三種資源調度器并沒有很好地解決這個問題，本發(fā)明提出了一種節(jié)點性能和作業(yè)類別標簽動態(tài)匹配的資源調度方法(dlms)，將cpu性能比較好的機器貼上cpu標簽，在磁盤io性能比較好的機器上面貼上io標簽或者是兩者都一般的普通標簽，作業(yè)根據(jù)分類可以貼上cpu標簽、io標簽任務或者普通標簽，然后進入不同的標簽隊列，調度器盡可能將相應的標簽節(jié)點的資源分配給相應的標簽作業(yè)，從而可以減少作業(yè)的運行時間，提高系統(tǒng)資源利用率，提高系統(tǒng)整體效率。

技術實現(xiàn)要素：

本發(fā)明提出的調度方法將集群節(jié)點進行初始分類并賦予相應的標簽。nodemanager發(fā)送心跳前進行自我檢測并對原始標簽進行動態(tài)調整，并使用機器學習分類算法對作業(yè)進行分類賦予相應的標簽，并根據(jù)用戶設定的作業(yè)優(yōu)先級，作業(yè)等待時間等屬性動態(tài)實現(xiàn)作業(yè)的排序，并將相應標簽的資源分配給相應的標簽隊列中的作業(yè)。

本發(fā)明所提出的調度方法主要包括以下模塊：

(1)集群節(jié)點原始分類及其動態(tài)分類標簽

集群節(jié)點首先需要進行初始分類，根據(jù)節(jié)點的cpu和磁盤io性能進行分類。集群中每個節(jié)點都需要單獨運行一個指定類型的任務并記錄下該節(jié)點運行該類作業(yè)的時間，根據(jù)節(jié)點運行單個任務的時間與集群中所有節(jié)點運行時間平均值的大小關系將節(jié)點分成cpu型節(jié)點，磁盤io型節(jié)點，普通型節(jié)點。

在集群節(jié)點運行的過程中，如果一個節(jié)點運行部分作業(yè)導致負載過大，會對這個節(jié)點的標簽進行降級處理，直接降級為普通節(jié)點。一個節(jié)點初始標簽是cpu型標簽，節(jié)點中運行cpu型任務，雖然此節(jié)點還有部分資源未使用，但是此時環(huán)境中節(jié)點cpu性能優(yōu)勢已經失去，為避免這種情況出現(xiàn)，采取動態(tài)標簽方法，在nodemanager向resourcemanager發(fā)送心跳的時候動態(tài)檢測該節(jié)點機器的cpu和io使用率，如果超過閾值，就將此節(jié)點標簽貼上普通標簽，每次發(fā)送心跳時都需要進行檢測一次，由此實現(xiàn)節(jié)點動態(tài)標簽。此閾值可以在配置文件中自行配置，如果用戶未配置會參照系統(tǒng)默認值。

(2)map執(zhí)行信息的獲取與回傳

hadoop作業(yè)通常分成map階段和reduce階段，通常大作業(yè)map數(shù)量在上百個甚至更多，一個作業(yè)主要時間是花費在map階段的計算上，但是每個map又是完全相同的執(zhí)行邏輯，所以會收集作業(yè)運行的第一個map進程的運行信息，這些信息在nodemanager向resourcemanager發(fā)送心跳時傳遞到調度器中，調度器根據(jù)傳回的信息進行作業(yè)的分類。

企業(yè)生產環(huán)境中，每天都會運行一些相同內容邏輯的作業(yè)，即用戶已知作業(yè)應所屬的標簽，在命令行或者代碼中為作業(yè)設置作業(yè)類型標簽，在調度的時候調度器會進行檢查，如果用戶已經對作業(yè)貼上標簽，就省去作業(yè)分類的環(huán)節(jié)，直接進行調度。

(3)多優(yōu)先級隊列

為滿足不同用戶的需求，防止小作業(yè)出現(xiàn)“饑餓”現(xiàn)象，采用作業(yè)優(yōu)先級方案。在調度器中新建5個隊列即：原始隊列、等待優(yōu)先級隊列、cpu優(yōu)先級隊列、io優(yōu)先級隊列和普通優(yōu)先級隊列。用戶提交作業(yè)首先是進入原始隊列中，先運行作業(yè)部分map并收集這部分map運行信息，然后作業(yè)進入等待優(yōu)先級隊列中等待map的運行信息回傳并進行分類，最后根據(jù)作業(yè)的分類類別標簽進入到對應標簽的隊列中。

(3)作業(yè)分類

在分類之前需要對數(shù)據(jù)進行預處理，數(shù)據(jù)預處理是指在前期對數(shù)據(jù)進行一些處理。為提高數(shù)據(jù)挖掘的質量產生了數(shù)據(jù)預處理技術。數(shù)據(jù)預處理技術有多種方法：數(shù)據(jù)清理、數(shù)據(jù)集成、數(shù)據(jù)變換和數(shù)據(jù)規(guī)約。這些數(shù)據(jù)處理技術在數(shù)據(jù)挖掘之前使用，大大提高數(shù)據(jù)挖掘模式的質量，降低實際挖掘所需時間。本文數(shù)據(jù)預處理主要是在數(shù)據(jù)歸一化方面。數(shù)據(jù)歸一化就是把各個變量數(shù)據(jù)都線性地變換到一個新標尺上，變換后變量最小值為0，最大值為1，這樣就保證所有的變量數(shù)據(jù)都小于等于1。

在作業(yè)分類方面選擇了簡單、使用比較普遍而且分類效果較好的樸素貝葉斯分類器進行分類。如果用戶在命令行和任務代碼中已經添加作業(yè)的類型的話，這個步驟會省掉，直接進入相應的隊列中等待分配資源。

(4)數(shù)據(jù)本地性

hadoop中遵循一個原則是“移動計算比移動數(shù)據(jù)更好”，移動到放置數(shù)據(jù)的計算節(jié)點要比把數(shù)據(jù)移動到一個計算節(jié)點更加節(jié)省成本，性能更好。關于數(shù)據(jù)本地性本發(fā)明采取了延時降級調度策略。

有益效果如下：

1.本發(fā)明針對異構集群環(huán)境提出一種動態(tài)標簽匹配的調度方法，通過對節(jié)點和作業(yè)進行分類，結合作業(yè)本身特性以及提交用戶的屬性共同組計算作業(yè)優(yōu)先級，在分配資源時將相同類型資源和節(jié)點進行匹配，考慮到節(jié)點的性能跟現(xiàn)階段運行的任務量的關系，采用自檢測方法動態(tài)調整節(jié)點標簽。最后通過實驗來對算法性能進行對比分析。

2.本發(fā)明針對數(shù)據(jù)本地性問題，提出了延時降級的算法，降級分為當前本節(jié)點、本機架節(jié)點和隨機節(jié)點三種，通過在一定的延時時間降低本地性等級來提高數(shù)據(jù)本地性。

3.本發(fā)明采用動態(tài)標簽的方法，首先預先運行不同類型作業(yè)，根據(jù)單節(jié)點運行的時間和集群所有節(jié)點的平均時間對比對節(jié)點進行分類，然后根據(jù)集群節(jié)點運行任務的負載情況對節(jié)點性能進行自檢測并生成相應的新標簽。

4.本發(fā)明提出對作業(yè)進行分類，由于mapreduce作業(yè)map部分都是相同的處理邏輯，所以可以根據(jù)作業(yè)預先執(zhí)行的部分信息對作業(yè)進行分類。

附圖說明

圖1作業(yè)調度整體框架流程圖；

圖2調度算法流程圖；

圖3不同調度算法下三種作業(yè)總運行時間對比圖；

圖4dlms下500m數(shù)據(jù)量下container分布數(shù)量圖；

圖5dlms下1g數(shù)據(jù)量下container分布數(shù)量圖；

圖6dlms下1.5g數(shù)據(jù)量下container分布數(shù)量圖；

圖7作業(yè)組在不同調度算法下運行時間對比圖；

具體實施方式

為使本發(fā)明的目的、技術方案和特點更加清楚明白，以下結合具體實施例子，并參照附圖，對本發(fā)明進行進一步的細化說明。yarn調度框架如圖1所示。

各個步驟解釋如下：

(1)用戶向yarn提交應用程序，其中包括用戶程序、啟動applicationmaster命令。

(2)resourcemanager為該應用程序分配第一個container，并與對應的nodemanager通信，要求它啟動應用程序的applicationmaster。

(3)applicationmaster向resourcemanager注冊后，為各個任務申請資源，并監(jiān)控它們的運行狀態(tài)，直到運行結束

(4)nodemanager發(fā)送心跳前進行自我檢測生成動態(tài)的節(jié)點標簽，并向resourcemanager匯報資源。

(5)任務分類進入不同的標簽隊列中，進行優(yōu)先級排序等待分配資源。

(6)applicationmaster通過rpc協(xié)議向resourcemanager申請和領取資源。

(7)根據(jù)nodemanager匯報的節(jié)點標簽和資源，調度器將此節(jié)點的資源分配給對應標簽隊列的作業(yè)。

(8)applicationmaster申請到資源后，便與對應的nodemanager通信，要求它啟動任務。

(9)nodemanager為任務設置好運行環(huán)境(環(huán)境變量、jar包、二進制程序等)后，將任務啟動命令寫到腳本中，并通過運行該腳本啟動任務。

(10)各個任務通過某個rpc協(xié)議向applicationmaster匯報自己的狀態(tài)和進度，可以在任務失敗時重新啟動任務。

(11)應用程序運行完成后，applicationmaster向resourcemanager注銷并關閉自己。

首先對集群物理節(jié)點進行初始分類，分類的方法過程如下：

(1)設集群機器節(jié)點集為n＝{ni|i∈[1,n]}n為節(jié)點總數(shù)量，i為從1開始n的正整數(shù)，ni表示集群中第i個物理機器。

(2)在每臺節(jié)點上都執(zhí)行一個相同的任務量的cpu、io和普通型作業(yè)并記錄作業(yè)執(zhí)行時間；tcpu(i)表示在第ni個節(jié)點上執(zhí)行cpu作業(yè)的花費時間；tio(i)表示在第ni個節(jié)點上執(zhí)行io作業(yè)的花費時間,tcom(i)表示在第ni個節(jié)點上執(zhí)行普通作業(yè)的花費時間。

(3)計算每種作業(yè)的集群平均時間，集群平均時間的計算公式如下：j表示作業(yè)的類型，算出每個節(jié)點在此種作業(yè)下與平均時間的時間差，如果tcpu(i)<avgcpu，為這個節(jié)點貼上cpu型節(jié)點的原始標簽，如果tcpu(i)>avgcpu，為這個節(jié)點貼上普通型原始標簽，通過比較后很可能每臺節(jié)點上的標簽會有多個，選擇節(jié)省時間最多的標簽為此節(jié)點的最后標簽。

設map的運行信息為m，它包括以下需要收集的信息m＝{min,mout,rate,acpu,mcpu,zcpu,mrate}min表示map輸入數(shù)據(jù)量，mout表示map輸出數(shù)據(jù)量，rate表示輸入數(shù)據(jù)量/輸出數(shù)據(jù)量，acpu表示cpu平均使用率，mcpu表示cpu中位數(shù)，zcpu表示cpu使用率超過90％的平均數(shù)，mrate表示內存使用量，這些數(shù)據(jù)將成為以后這個作業(yè)分類的特征屬性。在實驗的過程中發(fā)現(xiàn)單純的計算cpu的平均時間不能很好反應作業(yè)的特征，通過實驗發(fā)現(xiàn)cpu型作業(yè)的cpu使用率大于90％的次數(shù)比較多，其他類型的作業(yè)cpu使用率大于90％的次數(shù)相對較少，所以把這個信息也加入到map回傳的信息中。

在隊列優(yōu)先級方面采取用戶自定義雙層權重的設計方法，設作業(yè)的大小屬性所占的權重為worthnum，該屬性分成三個等級num∈{long,mid,short}，作業(yè)的擁有者屬性所占權重為worthuser，該屬性分成兩個等級user∈{root,others}，作業(yè)的緊急程度所占權重為worthemogence，該屬性可分成三個等級prority∈{highprority,midprority,lowprority},作業(yè)的等待時間所占的權重為worthwait，等待的計算公式為waittime＝nowtime-submittime,賦予相應的權重，最后計算出每個任務的優(yōu)先級數(shù)，然后在相應的隊列中進行排序。上述五種任務屬性權重相加和為100％，具體公式如下。

worthnum+worthuser+worthemogence+worthwtait＝100％；

最后權重計算公式：

finalwort＝worthnum*num+worthuser*user+worthemogence*prority+worthwait*waittime

在作業(yè)分類方面，采用樸素貝葉斯分類器，具體分類步驟如下：

(1)分別計算一個作業(yè)在某些條件下是cpu、io還是普通型作業(yè)下的條件概率：

p(job＝labcpu|v1,v2,…,vn)

p(job＝labio|v1,v2,…,vn)

p(job＝labcom|v1,v2,…,vn)

其中job∈{cpu,io,com}表示作業(yè)類別標簽；vi為作業(yè)的屬性特征。

(2)根據(jù)貝葉斯公式p(b|a)＝p(ab)/p(a)得:

假設vi之間相對獨立，根據(jù)獨立假設其中

(3)實際計算中p(v1,v2,…,vn)與作業(yè)無關可忽略不計，因此最終可得

同理有

作業(yè)是cpu型作業(yè)、io型作業(yè)還是普通型作業(yè)取決于哪個概率值更大。

本地性本文采取了延時降級調度策略。該策略具體思想如下：

為每個作業(yè)增加一個延時時間屬性，設ti為第i個作業(yè)當前的延時時間，i∈[1,n],n為集群的節(jié)點數(shù)目，tlocal表示本地節(jié)點延時時間閾值，track表示機架節(jié)點延時時間閾值。當調度器分配資源給作業(yè)時，如果作業(yè)的執(zhí)行節(jié)點和數(shù)據(jù)輸入節(jié)點不在一個節(jié)點上，此時ti自增1，表示該作業(yè)有一次延時調度，此時將此資源分配給其它合適的作業(yè)，直到當ti>tlocal時，作業(yè)的本地性就會降低為機架本地性，此時只要是本機架內的節(jié)點都可以將資源分配給該作業(yè)；當ti>track時，作業(yè)的本地性降低為隨機節(jié)點。其中的tlocal和track都采用配置文件的方式由用戶根據(jù)集群情況自行配置。采用延時的調度策略可以保證在一定的延時時間內獲得較好的本地性。

dlms調度方法的基本思想是預先分配部分作業(yè)執(zhí)行，根據(jù)作業(yè)回傳的信息對作業(yè)進行分類，然后將節(jié)點標簽的資源分配給相應的隊列中的任務，基本流程：

步驟1當節(jié)點通過心跳向資源管理匯報資源的時候，如果原始隊列不為空，則遍歷原始隊列中作業(yè)，將已經在命令行或者程序中指定了作業(yè)類型標簽的作業(yè)分配到相應的標簽優(yōu)先級隊列中，原始隊列移除此作業(yè)。

步驟2如果原始隊列不為空，則將此節(jié)點上的資源分配給原始隊列，作業(yè)進入等待隊列中等待下次分配資源，原始隊列移除此作業(yè)，此輪分配結束。

步驟3如果等待優(yōu)先級隊列不為空，則對等待優(yōu)先級隊列中的作業(yè)進行分類進入相應的標簽優(yōu)先級隊列。

步驟4如果如節(jié)點性能標簽相應的作業(yè)類別隊列不為空，則將此節(jié)點的資源分配給此隊列，此輪分配結束。

步驟5設置查看資源訪問次數(shù)變量，如果超過集群的數(shù)量，則將節(jié)點的資源按cpu、io、普通、等待優(yōu)先級順序將資源分配給相應的隊列，此輪調度結束。本步驟可以防止出現(xiàn)類似以下情況，cpu隊列作業(yè)過多，導致cpu型節(jié)點資源已經耗盡，其他標簽的節(jié)點還有資源，但是作業(yè)無法分配資源的情況。

算法的流程圖如圖2所示。

實驗環(huán)境

本節(jié)將通過實驗來驗證本文提出的dlms調度器的實際效果。實驗環(huán)境為5臺pc機搭建而成的hadoop完全分布式集群，集群的節(jié)點機器配置統(tǒng)一為操作系統(tǒng)ubuntu-12.04.1,jdk1.6，hadoop2.5.1，內存2g，硬盤50g。其中namenode的cpu的核數(shù)為2，datanode1的cpu核數(shù)為2，datanode2的cpu核數(shù)為4，datanode3的cpu核數(shù)為2，datanode4的cpu核數(shù)為4.

實驗結果與說明

首先準備數(shù)據(jù)量為128m的wordcount(io型)，kmeans(cpu型)作業(yè)各一個，分別在4臺節(jié)點上面運行6次，記錄下作業(yè)運行的時間。表1中s表示時間單位秒，avg表示該節(jié)點運行相應標簽任務的平均時間，allavg表示所有節(jié)點運行相應標簽任務的總平均時間，rate的計算公式如下：

負號表示平均時間相對于總平均時間的減少，正號表示平均時間相對于總平均時間的增加。

由表1可以看出datanode1在運行兩個任務的時間都是節(jié)省時間的，我們采取節(jié)省最多的cpu作業(yè)作為機器的原始標簽，datanode2為io標簽，datanode3、datanode4為普通機器。

表1原始分類實驗表

實驗結果及其分析

使用可以明顯區(qū)分作業(yè)類型的幾種作業(yè)，wordcount在map階段需要大量的讀取數(shù)據(jù)和寫入中間數(shù)據(jù)，map階段和reduce階段基本上沒有算數(shù)計算，所以將此種作業(yè)定性為io型作業(yè)，kmeans在map階段和reduce階段都需要大量的計算點和點之間的距離，并沒有太多的中間數(shù)據(jù)的寫入，所以將此種作業(yè)定性為cpu型作業(yè)，topk在reduce階段沒有大量的數(shù)據(jù)寫入磁盤，也沒有大量的計算，只涉及到簡單的比較，所以人為的認為這個是普通型的任務。

通過兩組實驗來進行驗證，第一組實驗設置調度器為fifo，在500m、1g和1.5g的數(shù)據(jù)量下分別運行wordcount，kmeans，topk作業(yè)各3次，記錄每個作業(yè)3次的平均時間作為最終時間，切換調度器為capacity和dlms調度器做同樣的實驗操作，實驗中記錄下dlms調度器下每種作業(yè)的container在集群的分布，container是表示集群資源的劃分單位，記錄了作業(yè)分片在集群中運行的分布情況，yarn中每個map和reduce進程都是以一個container來進行表示的。container在集群中每個節(jié)點分布比例表明節(jié)點執(zhí)行作業(yè)任務量的比例。圖2的橫坐標是作業(yè)的數(shù)據(jù)量，縱坐標是wordcount，kmeans，topk這3種作業(yè)共同運行的總時間。在數(shù)據(jù)量增大的情況下，dlms調度器相比于其他的調度器節(jié)省大約10％-20％的時間。

因為dlms會將相應節(jié)點標簽的資源分配給相應標簽的作業(yè)。作業(yè)的map和reduce是以一個container的形式在節(jié)點上運行的，圖3至圖5是在dmls調度器下不同數(shù)據(jù)量作業(yè)的container數(shù)量。根據(jù)上節(jié)的原始分類node1是cpu型的標簽節(jié)點，node2和node3是普通標簽節(jié)點，node4是io標簽節(jié)點。wordcount是io型作業(yè)，topk是普通型作業(yè)，kmeans是cpu型作業(yè)。從圖中可以看出container的分布規(guī)律為wordcount作業(yè)在node4上分配的container比較多，tokp在普通節(jié)點node2和node3上面分布的比較多，kmeans作業(yè)在node1節(jié)點上面分布的比較多。以上不同作業(yè)的container在集群節(jié)點上的分布表明dlms調度器提高了相應節(jié)點標簽的資源分配給對應標簽作業(yè)的概率。

第二組實驗，準備了5個作業(yè)，分別是128m和500m數(shù)據(jù)量的wordcount作業(yè)，128m和500m數(shù)據(jù)量的kmeans作業(yè)，500m的topk作業(yè)組成一個作業(yè)組。5個作業(yè)同時提交運行。在不同調度器的集群中模擬連續(xù)作業(yè)執(zhí)行情況，記錄作業(yè)組執(zhí)行完的總時間。作業(yè)組在不同的調度器下運行3次，記錄下作業(yè)組運行完的總時間。具體結果見圖6，從圖6中可以看出本文提出的dlms調度器相比于hadoop自帶調度器執(zhí)行相同作業(yè)組節(jié)省的時間是顯而易見的，本文提出的dmls調度器相比hadoop自帶的fifo調度器節(jié)省了大約20％的時間，比capacity調度器節(jié)省了大約10％的運行時間。