Hadoop最初的設(shè)計目的是支持大數(shù)據(jù)批處理作業(yè)，如日志挖掘扎阶、Web索引等作業(yè)汹胃，為此，Hadoop僅提供了一個非常簡單的調(diào)度機制：FIFO东臀，即先來先服務(wù)着饥。在該調(diào)度機制下，所有作業(yè)被統(tǒng)一提交到一個隊列中惰赋，Hadoop按照提交順序依次運行這些作業(yè)宰掉。

但隨著Hadoop的普及，單個Hadoop集群的用戶量越來越大，不同用戶提交的應(yīng)用程序往往具有不同的服務(wù)質(zhì)量要求（Quality Of Service, QoS）轨奄，典型的應(yīng)用有以下幾種仇穗。

• 批處理作業(yè)：這種作業(yè)往往耗時較長，對完成時間一般沒有嚴(yán)格要求戚绕，如數(shù)據(jù)挖掘、機器學(xué)習(xí)等方面的應(yīng)用程序枝冀。
• 交互式作業(yè)：這種作業(yè)期望能及時返回結(jié)果舞丛，如SQL查詢（Hive）等。
• 生產(chǎn)性作業(yè)：這種作業(yè)要求有一定量的資源保證果漾，如統(tǒng)計值計算球切。

此外，這些應(yīng)用程序?qū)τ布Y源的需求量也是不同的绒障，如過濾吨凑、統(tǒng)計類作業(yè)一般為CPU密集型作業(yè)，而數(shù)據(jù)挖掘户辱、機器學(xué)習(xí)作業(yè)一般為I/O密集型作業(yè)鸵钝。因此，傳統(tǒng)的FIFO調(diào)度策略不僅不能滿足多樣化需求庐镐，也不能充分利用硬件資源恩商。

為了克服單隊列FIFO調(diào)度器的不足，多種類型的多用戶多隊列調(diào)度器誕生了必逆。這種調(diào)度器允許管理員按照應(yīng)用需求對用戶或者應(yīng)用程序分組怠堪，并為不同的分組分配不同的資源量，同時通過添加各種約束防止單個用戶或者應(yīng)用程序獨占資源名眉，進而能夠滿足各種QoS需求粟矿。當(dāng)前主要有兩種多用戶作業(yè)調(diào)度器的設(shè)計思路：第一種是在一個物理集群上虛擬多個Hadoop集群，這些集群各自擁有全套獨立的Hadoop服務(wù)损拢，比如JobTracker陌粹、TaskTracker等，典型的代表是HOD調(diào)度器福压；另一種是擴展Hadoop調(diào)度器申屹，使之支持多個隊列多用戶，這樣隧膏，不同的隊列擁有不同的資源量哗讥，可以運行不同的應(yīng)用程序，典型的代表是Yahoo胞枕！的Capacity Scheduler和Facebook的Fair Scheduler杆煞。接下來將分別介紹這兩種多用戶作業(yè)調(diào)度器。

HOD

HOD（Hadoop On Demand）調(diào)度器是一個在共享物理集群上管理若干個Hadoop集群的工具。用戶可通過HOD調(diào)度器在一個共享物理集群上快速搭建若干個獨立的虛擬Hadoop集群决乎，以滿足不同的用途队询，比如不同集群運行不同類型的應(yīng)用程序，運行不同的Hadoop版本進行測試等构诚。HOD調(diào)度器可使管理員和用戶輕松地快速搭建和使用Hadoop蚌斩。

HOD調(diào)度器首先使用Torque資源管理器為一個虛擬Hadoop集群分配節(jié)點，然后在分配的節(jié)點上啟動MapReduce和HDFS中的各個守護進程范嘱，并自動為Hadoop守護進程和客戶端生成合適的配置文件（包括mapred-site.xml, core-site.xml和hdfs-site.xml等）送膳。接下來將分別介紹Torque資源管理器和HOD調(diào)度器的基本工作原理。

Torque資源管理器
HOD調(diào)度器的工作過程實現(xiàn)中依賴于一個資源管理器來為它分配丑蛤、回收節(jié)點和管理各節(jié)點上的作業(yè)運行的情況叠聋，如監(jiān)控作業(yè)的運行、維護作業(yè)的運行狀態(tài)等受裹。而HOD只需在資源管理器所分配的節(jié)點上運行Hadoop守護進程和MapReduce作業(yè)即可碌补。當(dāng)前HOD采用的資源管理器是開源的Torque資源管理器。

一個Torque集群由一個頭節(jié)點和若干個計算節(jié)點組成棉饶。頭節(jié)點上運行一個名為pbs_server的守護進程厦章，主要用于管理計算節(jié)點和監(jiān)控各個作業(yè)的運行狀態(tài)。每個計算節(jié)點上運行一個名為pbs_mom的守護進程照藻，用于執(zhí)行主節(jié)點分配的作業(yè)闷袒。此外，用戶可將任何節(jié)點作為客戶端岩梳，用于提交和管理作業(yè)囊骤。

頭節(jié)點內(nèi)部還運行了一個調(diào)度器守護進程。該守護進程會與pbs_server進行通信冀值，以決定對資源使用和作業(yè)分配的本地策略也物。默認(rèn)情況下，調(diào)度守護進程采用了FIFO調(diào)度機制列疗，它將所有作業(yè)存放到一個隊列中滑蚯，并按照到達時間依次對它們進行調(diào)度。需要注意的是抵栈，Torque中的調(diào)度機制是可插拔的告材，Torque還提供許多其他可選的作業(yè)調(diào)度器。

如圖10-1所示古劲，用戶可通過qsub命令向物理集群中提交作業(yè)斥赋，而Torque內(nèi)部執(zhí)行流程如下：

步驟1　當(dāng)pbs_server收到新作業(yè)后，會進一步通知調(diào)度器产艾。
步驟2　調(diào)度器采用一定的策略為該作業(yè)分配節(jié)點疤剑，并將節(jié)點列表與節(jié)點對應(yīng)的作業(yè)執(zhí)行命令返回給pbs_server滑绒。
步驟3　pbs_server將作業(yè)發(fā)送給第一個節(jié)點。
步驟4　第一個節(jié)點啟動作業(yè)隘膘，作業(yè)開始運行（該作業(yè)會通知其他節(jié)點執(zhí)行相應(yīng)命令）疑故。
步驟5　作業(yè)運行完成或者資源申請到期后，Torque會回收資源弯菊。

image.png

HOD作業(yè)調(diào)度

理解了Torque工作原理后纵势，HOD調(diào)度器工作原理便一目了然：首先利用Torque向物理集群申請一個虛擬機群，然后將Hadoop守護進程包裝成一個Torque作業(yè)管钳，并在申請的節(jié)點上啟動钦铁，最后用戶可直接向啟動的Hadoop集群中提交作業(yè)。通過HOD調(diào)度器申請集群和運行作業(yè)的主要流程如下：

步驟1　用戶向HOD調(diào)度器申請一個包含一定數(shù)目節(jié)點的集群蹋嵌，并要求該集群中運行一個Hadoop實例。
步驟2　HOD客戶端利用資源管理器接口qsub提交一個被稱為RingMaster的進程作為Torque作業(yè)葫隙，同時申請一定數(shù)目的節(jié)點栽烂。這個作業(yè)被提交到pbs_server上。
步驟3　在各個計算節(jié)點上恋脚，守護進程pbs_mom接受并處理pbs_server分配的作業(yè)腺办。RingMaster進程在其中一個計算節(jié)點上開始運行。
步驟4　RingMaster通過Torque的另外一個接口pbsdsh在所有分配到的計算節(jié)點上運行第二個HOD組件HodRing糟描，即運行于各個計算節(jié)點上的分布式任務(wù)怀喉。
步驟5　HodRing初始化之后會與RingMaster通信以獲取Hadoop指令，并根據(jù)指令啟動Hadoop服務(wù)進程船响。一旦服務(wù)進程開始啟動躬拢，它們會向RingMaster登記，提供關(guān)于守護進程的信息见间。
步驟6　Hadoop實例啟動之后聊闯，用戶可以向集群中提交MapReduce作業(yè)。
步驟7　如果一段時間內(nèi)Hadoop集群上沒有作業(yè)運行米诉，Torque會回收該虛擬Hadoop集群的資源菱蔬。

管理員將一個物理集群劃分成若干個Hadoop集群后，用戶可將不同類型的應(yīng)用程序提交到不同Hadoop集群上史侣，這樣可避免不同用戶或者不同應(yīng)用程序之間爭奪資源拴泌，從而達到多用戶共享集群的目的。

從集群管理和資源利用率兩方面看惊橱，這種基于完全隔離的集群劃分方法存在諸多問題蚪腐。

• 從集群管理角度看，多個Hadoop集群會給運維人員造成管理上的諸多不便税朴。
• 多個Hadoop集群會導(dǎo)致集群整體利用率低下削茁，這主要是負(fù)載不均衡造成的宙枷，比如某個集群非常忙碌時另外一些集群可能空閑，也就是說茧跋，多個Hadoop集群無法實現(xiàn)資源共享慰丛。

考慮到虛擬集群回收后數(shù)據(jù)可能丟失，用戶通常將虛擬集群中的數(shù)據(jù)寫到外部的HDFS上瘾杭。如圖10-2所示诅病，用戶通常僅在虛擬集群上安裝MapReduce，至于HDFS粥烁，則使用一個外部全局共享的HDFS贤笆。很明顯，這種部署方法會導(dǎo)致喪失部分?jǐn)?shù)據(jù)的本地特性讨阻。為了解決該問題芥永，一種更好的方法是在整個集群中只保留一個Hadoop實例，而通過Hadoop調(diào)度器將整個集群中的資源劃分給若干個隊列钝吮，并讓這些隊列共享所有節(jié)點上的資源埋涧，當(dāng)前Yahoo！的Capacity Scheduler和Facebook的Fair Scheduler正是采用了這個設(shè)計思路奇瘦。

image.png

Hadoop隊列管理機制

在學(xué)習(xí)Capacity Scheduler和Fair Scheduler之前棘催，我們先要了解Hadoop的用戶和作業(yè)管理機制，這是任何Hadoop可插拔調(diào)度器的基礎(chǔ)耳标。

Hadoop以隊列為單位管理作業(yè)醇坝、用戶和資源，整個Hadoop集群被劃分成若干個隊列次坡，每個隊列被分配一定的資源呼猪，且用戶只能向?qū)?yīng)的一個或者幾個隊列中提交作業(yè)。Hadoop隊列管理機制由用戶權(quán)限管理和系統(tǒng)資源管理兩部分組成砸琅，下面依次進行介紹郑叠。

1.用戶權(quán)限管理
Hadoop的用戶管理模塊構(gòu)建在操作系統(tǒng)用戶管理之上，增加了“隊列”這一用戶組織單元明棍，并通過隊列建立了操作系統(tǒng)用戶和用戶組之間的映射關(guān)系乡革。管理員可配置每個隊列對應(yīng)的操作系統(tǒng)用戶和用戶組（需要注意的是，Hadoop允許一個操作系統(tǒng)用戶或者用戶組對應(yīng)一個或者多個隊列）也可以配置每個隊列的管理員摊腋。他可以殺死該隊列中任何作業(yè)沸版，改變?nèi)魏巫鳂I(yè)的優(yōu)先級等。

Hadoop集群中所有隊列需在配置文件mapred-site.xml中設(shè)置兴蒸，這意味著該配置信息不可以動態(tài)加載视粮。

【實例】如果一個集群中有四個隊列，分別是queueA橙凳、queueB蕾殴、queueC和default笑撞，那么可以在mapred-site.xml中配置如下：

＜property＞

＜name＞mapred.queue.names＜/name＞

＜value＞queueA, queueB, queueC, default＜/value＞

＜description＞Hadoop中所有隊列名稱＜/description＞

＜/property＞

＜property＞

＜name＞mapred.acls.enabled＜/name＞

＜value＞true＜/value＞

＜description＞是否啟用權(quán)限管理功能＜/description＞

＜/property＞

隊列權(quán)限相關(guān)的配置選項在配置文件mapred-queue-acls.xml中設(shè)置，這些信息可以動態(tài)加載钓觉。

【實例】如果規(guī)定用戶linux_userA和用戶組linux_groupA可以向隊列queueA中提交作業(yè)茴肥，用戶linux_groupA_admin可以管理（比如殺死任何一個作業(yè)或者改變?nèi)魏巫鳂I(yè)的優(yōu)先級）隊列queueA，那么可以在mapred-queue-acls.xml中配置如下：

＜configuration＞

＜property＞

＜name＞mapred.queue.queueA.acl-submit-job＜/name＞

＜value＞linux_userA linux_groupA＜/value＞

＜/property＞

＜property＞

＜name＞mapred.queue.queueA.acl-administer-jobs＜/name＞

＜value＞linux_groupA_admin＜/value＞

＜/property＞

＜荡灾！--配置其他隊列.--＞

＜/configuration＞

2.系統(tǒng)資源管理
Hadoop資源管理由調(diào)度器完成瓤狐。管理員可在調(diào)度器中設(shè)置各個隊列的資源容量、各個用戶可用資源量等信息批幌，而調(diào)度器則按照相應(yīng)的資源約束對作業(yè)進行調(diào)度础锐。考慮到系統(tǒng)中的隊列信息是在mapred-site.xml中設(shè)置的荧缘，而隊列資源分配信息在各個調(diào)度器的配置文件中設(shè)置皆警，因此，這兩個配置文件中的隊列信息應(yīng)保持一致是十分重要的截粗。如果調(diào)度器中的某個隊列在mapred-site.xml中沒有設(shè)置信姓，則意味著該隊列中的資源無法得到使用。

通常而言桐愉，不同的調(diào)度器對資源管理的方式是不同的财破。接下來將介紹Capacity Scheduler和Fair Scheduler兩個調(diào)度器的工作原理掰派。

Capacity Scheduler實現(xiàn)

Capacity Scheduler是Yahoo从诲！開發(fā)的多用戶調(diào)度器。它以隊列為單位劃分資源靡羡，每個隊列可設(shè)定一定比例的資源最低保證和使用上限系洛，同時，每個用戶也可設(shè)定一定的資源使用上限以防止資源濫用略步，而當(dāng)一個隊列的資源有剩余時描扯，可暫時將剩余資源共享給其他隊列√吮。總之绽诚，Capacity Scheduler主要有以下幾個特點。

• 容量保證：管理員可為每個隊列設(shè)置資源最低保證和資源使用上限杭煎，而所有提交到該隊列的作業(yè)共享這些資源恩够。
• 靈活性：如果一個隊列中的資源有剩余，可以暫時共享給那些需要資源的隊列羡铲，而一旦該隊列有新的作業(yè)提交蜂桶，則其他隊列釋放資源后會歸還給該隊列。相比于HOD調(diào)度器也切，這種資源靈活分配的方式可明顯提高資源利用率扑媚。
• 多重租賃：支持多用戶共享集群和多作業(yè)同時運行腰湾。為防止單個作業(yè)、用戶或者隊列獨占集群中的資源疆股，管理員可為之增加多重約束（比如單個作業(yè)同時運行的任務(wù)數(shù)等）费坊。
• 支持作業(yè)優(yōu)先級：默認(rèn)情況下，在每個隊列中押桃，空閑資源優(yōu)先分配給最早提交的作業(yè)葵萎，但也可讓其支持作業(yè)優(yōu)先級，這樣唱凯，優(yōu)先級高的作業(yè)將優(yōu)先獲取資源（兩個作業(yè)優(yōu)先級相同時羡忘，再按照提交時間優(yōu)先的原則分配資源）。需要注意的是磕昼，當(dāng)前Capacity Scheduler還不支持資源搶占卷雕，也就是說，如果優(yōu)先級高的作業(yè)提交時間晚于優(yōu)先級低的作業(yè)票从，則高優(yōu)先級作業(yè)需等待低優(yōu)先級作業(yè)釋放資源漫雕。

Capacity Scheduler功能介紹

Capacity Scheduler是一個多用戶調(diào)度器。它設(shè)計了多層級別的資源限制條件以更好地讓多用戶共享一個Hadoop集群峰鄙，比如隊列資源限制浸间、用戶資源限制、用戶作業(yè)數(shù)目限制等吟榴。為了能夠更詳盡地了解Capacity Scheduler的功能魁蒜，我們從它的配置文件講起。Capacity Scheduler有自己的配置文件吩翻，即存放在conf目錄下的capacity-scheduler.xml兜看。

在Capacity Scheduler的配置文件中，隊列queueX的參數(shù)Y的配置名稱為mapred.capacity-scheduler.queue.queueX.Y狭瞎，為了簡單起見细移，我們記為Y，則每個隊列可以配置的參數(shù)如下熊锭。

• capacity：隊列的資源容量（百分比）弧轧。當(dāng)系統(tǒng)非常繁忙時，應(yīng)保證每個隊列的容量得到滿足碗殷，而如果每個隊列作業(yè)較少精绎，可將剩余資源共享給其他隊列。注意亿扁，所有隊列的容量之和應(yīng)小于100捺典。
• maximum-capacity：隊列的資源使用上限（百分比）。由于存在資源共享从祝，因此一個隊列使用的資源量可能超過其容量襟己，而最多使用資源量可通過該參數(shù)限制引谜。
• supports-priority：是否支持作業(yè)優(yōu)先級。默認(rèn)情況下擎浴，每個隊列內(nèi)部员咽，提交時間早的作業(yè)優(yōu)先獲得資源，而如果支持優(yōu)先級贮预，則優(yōu)先級高的作業(yè)優(yōu)先獲得資源贝室，如果兩個作業(yè)優(yōu)先級相同，則再進一步考慮提交時間仿吞。
• user-limit-factor：每個用戶最多可使用的資源量（百分比）滑频。比如，假設(shè)該值為30唤冈，則任何時刻峡迷，每個用戶使用的資源量不能超過該隊列容量的30%。
• maximum-initialized-active-tasks：隊列中同時被初始化的任務(wù)數(shù)目上限你虹。通過設(shè)置該參數(shù)可防止因過多的任務(wù)被初始化而占用大量內(nèi)存绘搞。
• maximum-initialized-active-tasks-per-user：每個用戶可同時被初始化的任務(wù)數(shù)目上限。
  一個配置文件實例如下：

＜configuration＞

＜property＞

＜name＞mapred.capacity-scheduler.maximum-system-jobs＜/name＞

＜value＞3000＜/value＞

＜description＞系統(tǒng)中最多可被初始化的作業(yè)數(shù)目＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.maximum-system-jobs＜/name＞

＜value＞3000＜/value＞

＜description＞Hadoop集群中最多同時被初始化的作業(yè)＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.capacity＜/name＞

＜value＞30＜/value＞

＜description＞default隊列的可用資源（百分比）＜/description＞

＜/property＞

＜傅物！--配置myQueue隊列.--＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.maximum-capacity＜/name＞

＜value＞40＜/value＞

＜description＞default隊列的資源使用上限（百分比）＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.supports-priority＜/name＞

＜value＞false＜/value＞

＜description＞是否考慮作業(yè)優(yōu)先級＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.minimum-user-limit-percent＜/name＞

＜value＞100＜/value＞

＜description＞每個用戶最低資源保障（百分比）＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.user-limit-factor＜/name＞

＜value＞1＜/value＞

＜description＞每個用戶最多可使用的資源占隊列總資源的比例＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.maximum-initialized-active-tasks＜/name＞

＜value＞200000＜/value＞

＜description＞default隊列可同時被初始化的任務(wù)數(shù)目＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.maximum-initialized-active-tasks-per-

user＜/name＞

＜value＞100000＜/value＞

＜description＞default隊列中每個用戶可同時被初始化的任務(wù)數(shù)目＜/description＞

＜/property＞

＜property＞

＜name＞mapred.capacity-scheduler.queue.myQueue.init-accept-jobs-factor＜/name＞

＜value＞10＜/value＞

＜description＞default隊列中可同時被初始化的作業(yè)數(shù)目夯辖，即該值與（maximum-system-jobs*

queue-capacity）的乘積＜/description＞

＜/property＞

＜！--配置myQueue隊列.--＞

＜/configuration＞

從上面這些參數(shù)可以看出董饰，Capacity Scheduler將整個系統(tǒng)資源分成若干個隊列蒿褂，且每個隊列有較為嚴(yán)格的資源使用限制，包括每個隊列的資源容量限制尖阔、每個用戶的資源量限制等贮缅。通過這些限制榨咐，Capacity Scheduler將整個Hadoop集群邏輯上劃分成若干個擁有相對獨立資源的子集群介却，而由于這些子集群實際上共用大集群中的資源，因此可以共享資源块茁，相對于HOD而言齿坷，提高了資源利用率且降低了運維成本。

Capacity Scheduler實現(xiàn)

對于Capacity Scheduler而言数焊，JobTracker啟動時永淌，會自動加載調(diào)度器類org.apache.hadoop.mapred.CapacityTaskScheduler（管理員需在參數(shù)mapred.jobtracker.taskScheduler中指定），而CapacityTaskScheduler啟動時會加載自己的配置文件capacity-scheduler.xml佩耳，并向JobTracker注冊監(jiān)聽器以隨時獲取作業(yè)變動信息遂蛀。待調(diào)度器啟動完后，用戶可以提交作業(yè)干厚。如圖10-3所示李滴，一個作業(yè)從提交到開始調(diào)度所經(jīng)歷的步驟大致如下：

image.png

步驟1　用戶通過Shell命令提交作業(yè)后螃宙，JobClient會將作業(yè)提交到JobTracker端。

步驟2　JobTracker通過監(jiān)聽器機制所坯，將新提交的作業(yè)同步給Capacity Scheduler中的監(jiān)聽器JobQueuesManager谆扎；JobQueuesManager收到新作業(yè)后將作業(yè)添加到等待隊列中，由JobInitializationPoller線程按照一定的策略對作業(yè)進行初始化芹助。

步驟3　某一時刻堂湖，一個TaskTracker向JobTracker匯報心跳，且它心跳信息中要求JobTracker為其分配新的任務(wù)状土。

步驟4　JobTracker檢測到TaskTracker可以接收新的任務(wù)后无蜂，調(diào)用CapacityTaskScheduler.assignTasks()函數(shù)為其分配任務(wù)。

步驟5　JobTracker將分配到的新任務(wù)返回給對應(yīng)的TaskTracker蒙谓。

接下來將重點介紹作業(yè)初始化和作業(yè)調(diào)度相關(guān)實現(xiàn)酱讶。

2.作業(yè)初始化
一個作業(yè)經(jīng)初始化后才能夠進一步得到調(diào)度器的調(diào)度而獲取計算資源，因此彼乌，作業(yè)初始化是作業(yè)開始獲取資源的前提泻肯。一個初始化的作業(yè)會占用JobTracker內(nèi)存，因此需防止大量不能立刻得到調(diào)度的作業(yè)被初始化而造成內(nèi)存浪費慰照。Capacity Scheduler通過優(yōu)先初始化那些最可能被調(diào)度器調(diào)度的作業(yè)和限制用戶初始化作業(yè)數(shù)目來限制內(nèi)存使用量灶挟。

由于作業(yè)經(jīng)初始化后才能得到調(diào)度，因此毒租，如果任務(wù)初始化的速度慢于被調(diào)度速度稚铣，則可能會產(chǎn)生空閑資源等待任務(wù)的現(xiàn)象。為了避免該問題墅垮，Capacity Scheduler總會過量初始化一些任務(wù)铲汪，從而讓一部分任務(wù)處于等待資源的狀態(tài)蝠引。

Capacity Scheduler中作業(yè)初始化由線程JobInitializationPoller完成。該線程由若干個（可通過參數(shù)mapred.capacity-scheduler.init-worker-threads指定，默認(rèn)是5）工作線程JobInitializationThread組成创南，每個工作線程負(fù)責(zé)一個或者多個隊列的作業(yè)初始化工作桥胞。作業(yè)初始化流程如下：
步驟1　用戶將作業(yè)提交到JobTracker端后野舶，JobTracker會向所有注冊的監(jiān)聽器廣播該作業(yè)信息槐雾；Capacity Scheduler中的監(jiān)聽器JobQueuesManager收到新作業(yè)添加的信息后，檢查是否能夠滿足以下三個約束若河，如果不滿足能岩，則提示作業(yè)初始化失敗，否則將該作業(yè)添加到對應(yīng)隊列的等待作業(yè)列表中：

• 該作業(yè)的任務(wù)數(shù)目不超過maximum-initialized-active-tasks-per-user萧福。
• 隊列中等待初始化和已經(jīng)初始化的作業(yè)數(shù)目不超過（init-accept-jobs-factor）×（maximum-system-jos）×capacity/100拉鹃。
• 該用戶等待初始化和已經(jīng)初始化的作業(yè)數(shù)目不超過[（maximum-system-jobs）×capacity/100.0×（minimum-user-limit-percent）100.0]×（init-accept-jobs-factor）。

步驟2　在每個隊列中，按照以下策略對未初始化的作業(yè)進行排序：如果支持作業(yè)優(yōu)先級（supports-priority為true）膏燕，則按照FIFO策略（先按照作業(yè)優(yōu)先級排序炭庙，再按照到達時間排序）排序，否則煌寇，按照作業(yè)到達時間排序焕蹄。每個工作線程每隔一段時間（可通過參數(shù)mapred.capacity-scheduler.init-poll-interval設(shè)定，默認(rèn)是3 000毫秒）遍歷其對應(yīng)的作業(yè)隊列阀溶，并選出滿足以下幾個條件的作業(yè)：

• 隊列已初始化作業(yè)數(shù)目（正運行的作業(yè)數(shù)目與已初始化但未運行作業(yè)數(shù)目之和）不超過[（maximum-system-jobs）×capaity/100.0]腻脏。
• 隊列中已初始化任務(wù)數(shù)目不超過maximum-initialized-active-tasks。
• 該用戶已經(jīng)初始化作業(yè)數(shù)目不超過[（maximum-system-jobs）×capacity/100.0×（minimum-user-limit-percent）/100.0]银锻。
• 該用戶已經(jīng)初始化的任務(wù)數(shù)目不超過maximum-initialized-active-tasks-per-user永品。

步驟3　調(diào)用JobTracker.initJob()函數(shù)對篩選出來的作業(yè)進行初始化。

3.任務(wù)調(diào)度
每個TaskTracker周期性向JobTracker發(fā)送心跳匯報任務(wù)進度和資源使用情況击纬，并在出現(xiàn)空閑資源時請求分配新任務(wù)鼎姐。當(dāng)需要為某個TaskTracker分配任務(wù)時，JobTracker會調(diào)用調(diào)度器的assignTasks函數(shù)為其返回一個待運行的任務(wù)列表更振。對于Capacity Scheduler而言炕桨，該assignTasks函數(shù)由類CapacityTaskScheduler實現(xiàn)。其主要工作流程如圖10-4所示肯腕，主要分為三個步驟：

步驟1　更新隊列資源使用量献宫。在選擇任務(wù)之前，需要更新各個隊列的資源使用信息实撒，以便根據(jù)最新的信息進行調(diào)度姊途。更新的信息包括隊列資源容量、資源使用上限知态、正在運行的任務(wù)和已經(jīng)使用的資源量等捷兰。

image.png

步驟2　選擇Map Task。Hadoop調(diào)度器通常采用三級調(diào)度策略负敏，即依次選擇一個隊列贡茅、該隊列中的一個作業(yè)和該作業(yè)中的一個任務(wù)，Capacity Scheduler也是如此原在。下面分別介紹Capacity Scheduler采用的調(diào)度策略友扰。

• 選擇隊列：Capacity Scheduler總是優(yōu)先將資源分配給資源使用率最低的隊列彤叉，即numSlotsOccupied/capacity最小的隊列庶柿，其中numSlotsOccupied表示隊列當(dāng)前已經(jīng)使用的slot數(shù)目，capacity為隊列的資源容量秽浇。

• 選擇作業(yè)：在隊列內(nèi)部浮庐，待調(diào)度作業(yè)排序策略與待初始化作業(yè)排序策略一樣，即如果支持作業(yè)優(yōu)先級（supports-priority為true），則按照優(yōu)先級策略排序审残，否則梭域，按照作業(yè)到達時間排序。當(dāng)選擇任務(wù)時搅轿，調(diào)度器會依次遍歷排好序的作業(yè)病涨，并檢查當(dāng)前TaskTracker剩余資源是否足以運行當(dāng)前作業(yè)的一個任務(wù)（注意，一個任務(wù)可能同時需要多個slot）璧坟，如果滿足既穆，則從該作業(yè)中選擇一個任務(wù)添加到已分配任務(wù)列表中。任務(wù)分配過程如圖10-5所示雀鹃。

  
  
  image.png

image.png

Capacity Scheduler調(diào)度過程用到了以下幾個機制幻工。

機制1：大內(nèi)存任務(wù)調(diào)度。

Capacity Scheduler提供了對大內(nèi)存任務(wù)的調(diào)度機制黎茎。默認(rèn)情況下囊颅，Hadoop假設(shè)所有任務(wù)是同質(zhì)的，任何一個任務(wù)只能使用一個slot傅瞻，考慮到一個slot代表的內(nèi)存是一定的踢代，因此這并沒有考慮那些內(nèi)存密集型的任務(wù)。為解決該問題嗅骄，Capacity Scheduler可根據(jù)任務(wù)的內(nèi)存需求量為其分配一個或者多個slot奸鬓。如果當(dāng)前TaskTracker空閑slot數(shù)目小于作業(yè)的單個任務(wù)的需求量，調(diào)度器會讓TaskTracker為該作業(yè)預(yù)留當(dāng)前空閑的slot掸读，直到累計預(yù)留的slot數(shù)目滿足當(dāng)前作業(yè)的單個任務(wù)需求串远，此時，才會真正地將該任務(wù)分配給TaskTracker執(zhí)行儿惫。

默認(rèn)情況下澡罚，大內(nèi)存任務(wù)調(diào)度機制是關(guān)閉的，只有當(dāng)管理員配置了mapred.cluster.map.memory.mb肾请、mapred.cluster.reduce.memory.mb留搔、mapred.cluster.max.map.memory.mb、mapred.cluster.max.reduce.memory.mb四個參數(shù)后铛铁，才會支持大內(nèi)存任務(wù)調(diào)度隔显，此時，調(diào)度器會按照以下公式計算每個Map Task需要的slot數(shù)（Reduce Task計算方法類似）：
「{mapred.cluster.map.memory.mb}」

機制2：通過任務(wù)延遲調(diào)度以提高數(shù)據(jù)本地性饵逐。

當(dāng)任務(wù)的輸入數(shù)據(jù)與分配到的slot位于同一個節(jié)點或者機架時括眠，稱該任務(wù)具有數(shù)據(jù)本地性。數(shù)據(jù)本地性包含三個級別倍权，分別是node-local（輸入數(shù)據(jù)和空閑slot位于同一個節(jié)點）掷豺、rack-local（輸入數(shù)據(jù)和空閑slot位于同一個機架）和off-switch（輸入數(shù)據(jù)和空閑slot位于不同機架）。由于為空閑slot選擇具有本地性的任務(wù)可避免通過網(wǎng)絡(luò)遠(yuǎn)程讀取數(shù)據(jù)進而提高數(shù)據(jù)讀取效率，所以Hadoop會優(yōu)先選擇node-local的任務(wù)当船，然后是rack-local题画，最后是off-switch。

為了提高任務(wù)的數(shù)據(jù)本地性德频，Capacity Scheduler采用了作業(yè)延遲調(diào)度的策略：當(dāng)選中一個作業(yè)后苍息，如果在該作業(yè)中未找到滿足數(shù)據(jù)本地性的任務(wù)，則調(diào)度器會讓該作業(yè)跳過一定數(shù)目的調(diào)度機會壹置，直到找到一個滿足本地性（node-local或rack-local）的任務(wù)或者達到跳過次數(shù)上限（requiredSlots×localityWaitFactor）档叔，其中，localityWaitFactor可通過參數(shù)mapreduce.job.locality.wait.factor配置蒸绩，默認(rèn)情況下衙四，計算方法如下：
localityWaitFactor=min{jobNodes/clusterNodes，1}

機制3：批量任務(wù)分配患亿。
為了加快任務(wù)分配速度传蹈，Capacity Scheduler支持批量任務(wù)分配，管理員可通過參數(shù)mapred.capacity-scheduler.maximum-tasks-per-heartbeat（默認(rèn)是Short.MAX_VALUE）指定一次性為一個TaskTracker分配的最多任務(wù)數(shù)步藕。需要注意的是惦界，該機制傾向于將任務(wù)分配給優(yōu)先發(fā)送心跳的TaskTracker，也就是說咙冗，當(dāng)系統(tǒng)slot數(shù)目大于任務(wù)需要的數(shù)目時沾歪，會使得任務(wù)集中運行在少數(shù)幾個節(jié)點上，且同一個作業(yè)的任務(wù)也可能會集中分配到幾個節(jié)點上雾消，這不利于負(fù)載均衡灾搏。

步驟3：選擇Reduce Task。

相比于Map Task, Reduce Task選擇機制就簡單多了立润。它僅采用了大內(nèi)存任務(wù)調(diào)度策略狂窑，至于其他策略，如任務(wù)延遲調(diào)度（Reduce Task沒有數(shù)據(jù)本地性）和批量任務(wù)分配等桑腮，不再采用泉哈。調(diào)度器只要找到一個合適的Reduce Task便可以返回。

多層隊列調(diào)度

在Hadoop 1.0中破讨，隊列以平級結(jié)構(gòu)組織在一起丛晦，且每個隊列不能再進一步劃分。但在實際應(yīng)用中提陶，每個隊列可能代表一個部門烫沙，該部門可能又進一步劃分成若干個子部門或者將自己的資源按照應(yīng)用類型劃分到不同隊列中，最終形成一個樹形組織結(jié)構(gòu)搁骑。一個典型的例子如圖10-6所示斧吐。

為了支持這種多層隊列組織方式又固，在Hadoop 2.0中仲器，Capacity Scheduler在現(xiàn)有實現(xiàn)基礎(chǔ)上添加了對多層隊列的支持煤率，主要特性如下：

• 整個組織結(jié)構(gòu)由中間隊列和葉子隊列組成，其中乏冀，中間隊列包含若干子隊列蝶糯，而葉子隊列沒有再分解的隊列。
• 任何隊列可劃分成若干子隊列辆沦，但子隊列容量之和不能超過父隊列總?cè)萘俊?/li>
• 用戶作業(yè)只能將作業(yè)提交到某個葉子隊列中昼捍。
• 當(dāng)某個隊列出現(xiàn)空閑資源時，優(yōu)先共享給同父親的其他子隊列肢扯。以圖10-6為例妒茬，當(dāng)隊列C11中有剩余資源時，首先共享給C12蔚晨，其次是C2乍钻，最后才是A1，A2和B1铭腕。
• 進行任務(wù)調(diào)度時银择，僅考慮葉子隊列，且采用的調(diào)度機制與現(xiàn)有的調(diào)度機制一致累舷。

image.png

Fair Scheduler實現(xiàn)

Fair Scheduler是Facebook開發(fā)的多用戶調(diào)度器浩考。與Capacity Scheduler類似，它以資源池（與隊列一個概念）為單位劃分資源被盈，每個資源池可設(shè)定一定比例的資源最低保證和使用上限析孽，同時，每個用戶也可設(shè)定一定的資源使用上限以防止資源濫用只怎；當(dāng)一個資源池的資源有剩余時绿淋，可暫時將剩余資源共享給其他資源池。當(dāng)然尝盼，F(xiàn)air Scheduler也存在很多與Capacity Scheduler不同之處吞滞，主要體現(xiàn)在以下幾個方面。

• 資源公平共享：在每個資源池中盾沫，F(xiàn)air Scheduler可選擇按照FIFO或者Fair策略為作業(yè)分配資源裁赠，其中Fair策略是一種基于最大最小公平算法實現(xiàn)的資源多路復(fù)用方式，默認(rèn)情況下赴精，每個隊列內(nèi)部采用該方式分配資源佩捞。這意味著，如果一個隊列中有兩個作業(yè)同時運行蕾哟，則每個作業(yè)可得到1/2的資源一忱；如果三個作業(yè)同時運行莲蜘，則每個作業(yè)可得到1/3的資源。

• 支持資源搶占：當(dāng)某個資源池中有剩余資源時帘营，調(diào)度器會將這些資源共享給其他資源池票渠；而當(dāng)該資源池中有新的作業(yè)提交時芬迄，調(diào)度器要為它回收資源问顷。為了盡可能降低不必要的計算浪費，調(diào)度器采用了先等待再強制回收的策略禀梳，即如果等待一段時間后尚有未歸還的資源杜窄，則會進行資源搶占：從那些超額使用資源的隊列中殺死一部分任務(wù)，進而釋放資源算途。

• 負(fù)載均衡：Fair Scheduler提供了一個基于任務(wù)數(shù)目的負(fù)載均衡機制塞耕。該機制盡可能將系統(tǒng)中的任務(wù)均勻分配到各個節(jié)點上。此外嘴瓤，用戶也可以根據(jù)自己的需要設(shè)計負(fù)載均衡機制扫外。

• 任務(wù)延時調(diào)度：Fair Scheduler提供了一種基于延時等待的調(diào)度機制以提高任務(wù)的數(shù)據(jù)本地性。該機制通過暫時減少個別作業(yè)的資源量而提高系統(tǒng)整體吞吐率纱注。

• 降低小作業(yè)調(diào)度延遲：由于采用了最大最小公平算法畏浆，小作業(yè)可以優(yōu)化獲取資源并運行完成。

Fair Scheduler功能介紹

與Capacity Scheduler類似狞贱，F(xiàn)air Scheduler也是一個多用戶調(diào)度器刻获，它同樣添加了多層級別的資源限制條件以更好地讓多用戶共享一個Hadoop集群，比如隊列資源限制瞎嬉、用戶作業(yè)數(shù)目限制等蝎毡。然而，由于Fair Scheduler增加了很多新的特性氧枣，因此它的配置選項更多沐兵。為了能夠更詳盡地了解Fair Scheduler的功能，我們從它的配置文件講起便监。Fair Scheduler的配置選項包括兩部分扎谎，其中一部分在mapred-site.xml中，另外一部分在自己的配置文件中烧董，默認(rèn)情況下為存放在conf目錄下的fair-scheduler.xml毁靶。

1.配置文件mapred-site.xml

啟用Fair Scheduler時，可在配置文件mapred-site.xml中增加以下幾個配置選項（其中逊移，mapred.jobtracker.taskScheduler是必填的预吆，其他自選）。

?mapred. jobtracker.taskScheduler：采用的調(diào)度器所在的類胳泉，即為org.apache.hadoop.mapred.FairScheduler拐叉。

?mapred. fairscheduler.poolnameproperty：資源池命名方式岩遗，包含以下三種命名方式。

〇user.name：默認(rèn)值凤瘦，一個UNIX用戶對應(yīng)一個資源池宿礁。

〇group.name：一個UNIX用戶組對應(yīng)一個資源池。

〇mapred.job.queue.name：一個隊列對應(yīng)一個資源池廷粒。如果設(shè)置為該值窘拯，則與Capacity Scheduler一樣红且。

?mapred. fairscheduler.allocation.file：Fair Scheduler配置文件所在位置坝茎，默認(rèn)是$HADOOP_HOME/conf/fair-scheduler.xml。

?mapred. fairscheduler.preemption：是否支持資源搶占暇番，默認(rèn)為false嗤放。

?mapred. fairscheduler.preemption.only.log：是否只打印資源搶占日志，并不真正進行資源搶占壁酬。打開該選項可用于調(diào)試次酌。

?mapred. fairscheduler.assignmultiple：是否在一次心跳中同時分配Map Task和ReduceTask，默認(rèn)為true舆乔。

?mapred. fairscheduler.assignmultiple.maps：一次心跳最多分配的Map Task數(shù)目岳服，默認(rèn)是-1，表示不限制希俩。

?mapred. fairscheduler.assignmultiple.reduces：一次心跳最多分配的Reduce Task數(shù)目吊宋，默認(rèn)是-1，表示不限制颜武。

?mapred. fairscheduler.sizebasedweight：是否按作業(yè)大小調(diào)整作業(yè)權(quán)重璃搜。將該參數(shù)置為true后，調(diào)度器會根據(jù)作業(yè)長度（任務(wù)數(shù)目）調(diào)整作業(yè)權(quán)重鳞上，以讓長作業(yè)獲取更多資源这吻，默認(rèn)是false。

?mapred. fairscheduler.locality.delay.node：為了等待一個滿足node-local的slot篙议，作業(yè)可最長等待時間唾糯。

?mapred. fairscheduler.locality.delay.rack：為了等待一個滿足rack-local的slot，可最長等待時間鬼贱。

?mapred. fairscheduler.loadmanager：可插拔負(fù)載均衡器移怯。用戶可通過繼承抽象類LoadManager實現(xiàn)一個負(fù)載均衡器，以決定每個TaskTracker上運行的Map Task和Reduce Task數(shù)目吩愧，默認(rèn)實現(xiàn)是CapBasedLoadManager芋酌，它將集群中所有Task按照數(shù)量平均分配到各個TaskTracker上。

?mapred. fairscheduler.taskselector：可插拔任務(wù)選擇器雁佳。用戶可通過繼承TaskSelector抽象類實現(xiàn)一個任務(wù)選擇器脐帝，以決定對于給定一個TaskTracker同云，為其選擇作業(yè)中的哪個任務(wù)。具體實現(xiàn)時可考慮數(shù)據(jù)本地性堵腹，推測執(zhí)行等機制炸站。默認(rèn)實現(xiàn)是DefaultTaskSelector，它使用了JobInProgress中提供的算法疚顷，具體可參考第6章旱易。

?mapred. fairscheduler.weightadjuster：可插拔權(quán)重調(diào)整器。用戶可通過實現(xiàn)WeightAdjuster接口編寫一個權(quán)重調(diào)整器腿堤，以動態(tài)調(diào)整運行作業(yè)的權(quán)重阀坏。

2.配置文件fair-scheduler.xml

fair-scheduler. xml是Fair Scheduler的配置文件，管理員可為每個pool添加一些資源約束以限制資源使用笆檀。對于每個pool忌堂，用戶可配置以下幾個選項。

?minMaps：最少保證的Map slot數(shù)目酗洒，即最小資源量士修。

?maxMaps：最多可以使用的Map slot數(shù)目。

?minReduces：最少保證的Reduce slot數(shù)目樱衷，即最小資源量棋嘲。

?maxReduces：最多可以使用的Reduce slot數(shù)目。

?maxRunningJobs：最多同時運行的作業(yè)數(shù)目矩桂。通過限制該數(shù)目沸移，可防止超量MapTask同時運行時產(chǎn)生的中間輸出結(jié)果撐爆磁盤。

?minSharePreemptionTimeout：最小共享量搶占時間耍鬓。如果一個資源池在該時間內(nèi)使用的資源量一直低于最小資源量阔籽，則開始搶占資源。

?schedulingMode：隊列采用的調(diào)度模式牲蜀，可以是FIFO或者Fair笆制。

管理員也可為單個用戶添加maxRunningJobs屬性限制其最多同時運行的作業(yè)數(shù)目。此外涣达，管理員也可通過以下參數(shù)設(shè)置以上屬性的默認(rèn)值在辆。

?poolMaxJobsDefault：資源池的maxRunningJobs屬性的默認(rèn)值。

?userMaxJobsDefault：用戶的maxRunningJobs屬性的默認(rèn)值度苔。

?defaultMinSharePreemptionTimeout：資源池的minSharePreemptionTimeout屬性的默認(rèn)值匆篓。

?defaultPoolSchedulingMode：資源池的schedulingMode屬性的默認(rèn)值。

?fairSharePreemptionTimeout：公平共享量搶占時間寇窑。如果一個資源池在該時間內(nèi)使用資源量一直低于公平共享量的一半鸦概，則開始搶占資源。

?defaultPoolSchedulingMode：Pool的schedulingMode屬性的默認(rèn)值甩骏。

【實例】假設(shè)要為一個Hadoop集群增加三個資源池poolA窗市、poolB和default先慷，且規(guī)定普通用戶最多可同時運行40個作業(yè)，但用戶userA最多可同時運行400個作業(yè)咨察，那么可在fair-scheduler.xml中進行如下配置：

＜allocations＞

＜pool name="poolA"＞

＜minMaps＞100＜/minMaps＞

＜maxMaps＞150＜/maxMaps＞

＜minReduces＞50＜/minReduces＞

＜maxReduces＞100＜/maxReduces＞

＜maxRunningJobs＞200＜/maxRunningJobs＞

＜minSharePreemptionTimeout＞300＜/minSharePreemptionTimeout＞

＜weight＞1.0＜/weight＞

＜/pool＞

＜pool name="poolB"＞

＜minMaps＞80＜/minMaps＞

＜maxMaps＞80＜/maxMaps＞

＜minReduces＞50＜/minReduces＞

＜maxReduces＞50＜/maxReduces＞

＜maxRunningJobs＞30＜/maxRunningJobs＞

＜minSharePreemptionTimeout＞500＜/minSharePreemptionTimeout＞

＜weight＞1.0＜/weight＞

＜/pool＞

＜pool name="default"＞

＜minMaps＞0＜/minMaps＞

＜maxMaps＞10＜/maxMaps＞

＜minReduces＞0＜/minReduces＞

＜maxReduces＞10＜/maxReduces＞

＜maxRunningJobs＞50＜/maxRunningJobs＞

＜minSharePreemptionTimeout＞500＜/minSharePreemptionTimeout＞

＜weight＞1.0＜/weight＞

＜/pool＞

＜user name="userA"＞

＜maxRunningJobs＞400＜/maxRunningJobs＞

＜/user＞

＜userMaxJobsDefault＞40＜/userMaxJobsDefault＞

＜fairSharePreemptionTimeout＞6000＜/fairSharePreemptionTimeout＞

＜/allocations＞

Fair Scheduler實現(xiàn)

1.Fair Scheduler基本設(shè)計思想

Fair Scheduler核心設(shè)計思想是基于資源池的最小資源量和公平共享量進行任務(wù)調(diào)度论熙。其中，最小資源量是管理員配置的摄狱，而公平共享量是根據(jù)隊列或作業(yè)權(quán)重計算得到的脓诡。資源分配具體過程如下：

步驟1　根據(jù)最小資源量將所有系統(tǒng)中所有slot分配給各個資源池。如果某個資源池實際需要的資源量小于它的最小資源量媒役，則只需將實際資源需求量分配給它即可祝谚。

步驟2　根據(jù)資源池的權(quán)重將剩余的資源分配給各個資源池。

步驟3　在各個資源池中刊愚，按照作業(yè)權(quán)重將資源分配給各個作業(yè)踊跟，最終每個作業(yè)可以分到的資源量即為作業(yè)的公平共享量踩验。其中鸥诽，作業(yè)權(quán)重是由作業(yè)優(yōu)先級轉(zhuǎn)換而來的，它們的映射關(guān)系如表10-1所示箕憾。

image.png

【實例】如圖10-7所示牡借，假設(shè)一個Hadoop集群中共有100有slot（為了簡單，不區(qū)分Map或者Reduce slot）和四個資源池（依次為P1袭异、P2钠龙、P3和P4），它們的最小資源量依次為：25御铃、19碴里、26和28。如圖10-7 a所示上真，在某一時刻咬腋，四個資源池實際需要的資源量（與未運行的任務(wù)數(shù)目相關(guān)）依次為20、26睡互、37和30根竿，則資源分配過程如下：

步驟1　根據(jù)最小資源量將資源分配各個資源池。對于資源池P1而言就珠，由于它實際需要的資源量少于其最小資源量寇壳，因此只需將它實際需要的資源分配給它即可，如圖10-7b和圖10-7c所示妻怎。經(jīng)過這一輪分配壳炎，四個資源池獲得的slot數(shù)目依次為：20、19逼侦、26和28匿辩。

步驟2　經(jīng)過第一輪分配后疏日，尚剩余7個slot，此時需按照權(quán)重將剩余資源分配給尚需資源的資源池P2撒汉，P3和P4沟优。不妨假設(shè)這三個資源池的權(quán)重依次為2.0、3.0和2.0睬辐，則它們額外分得的slot數(shù)目依次為2挠阁、3和2。這樣溯饵，如圖10-7 d所示侵俗，三個資源池最終獲得的資源總量依次為：21、29和30丰刊。

image

這三個值即為對應(yīng)作業(yè)的公平共享量秩仆。

2.Fair Scheduler實現(xiàn)
Fair Scheduler內(nèi)部組織結(jié)構(gòu)如圖10-8所示码泛。涉及的模塊有：配置文件加載模塊、作業(yè)監(jiān)聽模塊澄耍、狀態(tài)更新模塊和調(diào)度模塊噪珊。下面分別介紹這幾個模塊。

• 配置文件加載模塊：由類PoolManager完成齐莲，負(fù)責(zé)將配置文件fair-scheduler.xml中的信息加載到內(nèi)存中痢站。
• 作業(yè)監(jiān)聽模塊：Fair Scheduler啟動時會向JobTracker注冊作業(yè)監(jiān)聽器JobListener，以便能夠隨時獲取作業(yè)變化信息选酗。
• 狀態(tài)更新模塊：由線程UpdateThread完成阵难，該線程每隔mapred.fairscheduler.update.interval（默認(rèn)是500毫秒）時間更新一次隊列和作業(yè)的信息，以便將最新的信息提供給調(diào)度模塊進行任務(wù)調(diào)度星掰。
• 調(diào)度模塊：當(dāng)某個TaskTracker通過心跳請求任務(wù)時多望，該模塊根據(jù)最新的隊列和作業(yè)的信息為該TaskTracker選擇一個或多個任務(wù)。

image.png

前面提到了作業(yè)公平共享量的計算方法氢烘，而調(diào)度器的任務(wù)就是將與公平共享量相等的資源分配給作業(yè)怀偷。在實際的Hadoop集群中，由于資源使用情況是動態(tài)變化的播玖，且任務(wù)運行的時間長短不一椎工，因此時刻保證每個作業(yè)實際分到的資源量與公平共享量一致是不可能的。為此，0.20.X版本采用了基于缺額的調(diào)度策略维蒙。該策略采用了貪心算法以保證盡可能公平地將資源分配給各個作業(yè)掰吕。

缺額（jobDeficit）是作業(yè)的公平共享量與實際分配到的資源量之間的差值。它反映了資源分配過程中產(chǎn)生的“理想與現(xiàn)實的差距”颅痊。調(diào)度器在實際資源分配時殖熟，應(yīng)保證所有作業(yè)的缺額盡可能小。缺額的基本計算公式為：
jobDeficit=jobDeficit+（jobFairShare-runningTasks）×timeDelta

其中斑响，jobFairShare為作業(yè)的公平共享量菱属，runningTasks為作業(yè)正在運行的任務(wù)數(shù)目（對應(yīng)實際分配到的資源量），timeDelta為缺額更新時間間隔舰罚。

從上面公式可以看出纽门，作業(yè)缺額是隨著時間積累的。在進行資源分配時营罢，調(diào)度器總是優(yōu)先將空閑資源分配給當(dāng)前缺額最大的作業(yè)赏陵。如果在一段時間內(nèi)一個作業(yè)一直沒有獲得資源，則它的缺額會越來越大饲漾，最終缺額變得最大蝙搔，從而可以獲得資源。這種基于缺額的調(diào)度機制并不能保證作業(yè)時時刻刻均能獲得與其公平共享量對應(yīng)的資源能颁，但如果所有作業(yè)的運行時間足夠長杂瘸，則該機制能夠保證每個作業(yè)實際平均分配到的資源量逼近它的公平共享量。

選擇隊列
Fair Scheduler選擇隊列時伙菊，在不同的條件下采用不同的策略，具體如下：

• 當(dāng)存在資源使用量小于最小資源量的資源池時敌土，優(yōu)先選擇資源使用率最低的資源池镜硕，即runningTasks/minShare最小的資源池，其中runningTasks是資源池當(dāng)前正在運行的Task數(shù)目（也就是正在使用的slot數(shù)目）返干，minShare為資源池的最小資源量兴枯。
• 否則，選擇任務(wù)權(quán)重比最小的資源池矩欠，其中資源池的任務(wù)權(quán)重比（tasksToWeightRatio）定義如下：
  tasksToWeightRatio=runningTasks/poolWeight
  其中财剖，runningTasks為資源池中正在運行的任務(wù)數(shù)目；poolWeight是管理員配置的資源池權(quán)重癌淮。

選擇作業(yè)
選定一個資源池后躺坟，F(xiàn)air Scheduler總是優(yōu)先將資源分配給資源池中任務(wù)權(quán)重比最小的作業(yè)，其中作業(yè)的任務(wù)權(quán)重比的計算方法與資源池的一致乳蓄，即為該作業(yè)正在運行的任務(wù)數(shù)目與作業(yè)權(quán)重的比值咪橙。但需要注意的是，作業(yè)權(quán)重比是由作業(yè)優(yōu)先級轉(zhuǎn)換而來的。此外美侦，F(xiàn)air Scheduler為管理員提供了另外兩種改變作業(yè)的權(quán)重的方法：

• 將參數(shù)mapred.fairscheduler.sizebasedweight置為true产舞，則計算作業(yè)權(quán)重時會考慮作業(yè)長度，具體計算方法如下：
  jobWeight=jobWeightByPriority×log2（runnableTasks）

其中菠剩，jobWeightByPriority是通過優(yōu)先級轉(zhuǎn)化來的權(quán)重易猫；runnableTasks是作業(yè)正在運行和尚未運行的任務(wù)之和。

• 通過實現(xiàn)WeightAdjuster接口具壮，編寫一個權(quán)重調(diào)整器擦囊，并通過參數(shù)mapred.fairscheduler.weightadjuster使之生效，此時嘴办，作業(yè)權(quán)重即為WeightAdjuster中方法adjustWeight的返回值瞬场。

3.Fair Scheduler優(yōu)化機制

我們知道，提高Map Task的數(shù)據(jù)本地性可提高作業(yè)運行效率涧郊。為了提高數(shù)據(jù)本地性贯被，F(xiàn)air Scheduler采用了延時調(diào)度機制：當(dāng)出現(xiàn)一個空閑slot時，如果選中的作業(yè)沒有node-local或者rack-local的任務(wù)妆艘，則暫時把資源讓給其他作業(yè)彤灶，直到找到一個滿足數(shù)據(jù)本地性的任務(wù)或者達到一個時間閾值，此時不得不為之選擇一個非本地性的任務(wù)批旺。

為了實現(xiàn)延時調(diào)度幌陕，F(xiàn)air Scheduler為每個作業(yè)j維護三個變量：level、wait和skipped汽煮，分別表示最近一次調(diào)度時作業(yè)的本地性級別（0搏熄、1、2分別對應(yīng)node-local暇赤、rack-local和off-switch）心例、已等待時間和是否延時調(diào)度，并依次初始化為：j.level=0鞋囊、j.wait=0和j.skipped=false止后。此外，當(dāng)不存在node-local任務(wù)時溜腐，為了盡可能選擇一個本地性較好的任務(wù)译株，F(xiàn)air Scheduler采用了雙層延遲調(diào)度算法：為了找到一個node-local任務(wù)最長可等待W1或者進一步等待W2找一個rack-local任務(wù)。

機制2：負(fù)載均衡挺益。
Fair Scheduler為用戶提供了一個可擴展的負(fù)載均衡器：CapBasedLoadManager歉糜。它會將系統(tǒng)中所有任務(wù)按照數(shù)量平均分配到各個節(jié)點上。當(dāng)然矩肩，用戶也可通過繼承抽象類LoadManager實現(xiàn)自己的負(fù)載均衡器现恼。

機制3：資源搶占肃续。
當(dāng)一個資源池有剩余資源時，F(xiàn)air Scheduler會將這些資源暫時共享給其他資源池叉袍；而一旦該資源池有新作業(yè)提交始锚，調(diào)度器則為它回收資源。如果在一段時間后該資源池仍得不到本屬于自己的資源喳逛，則調(diào)度器會通過殺死任務(wù)的方式搶占資源瞧捌。Fair Scheduler同時采用了兩種資源搶占方式：最小資源量搶占和公平共享量搶占碱茁。如果一個資源池的最小資源量在一定時間內(nèi)得不到滿足咖城，則會從其他超額使用資源的資源池中搶占資源，這就是最小資源量搶占廉涕；而如果一定時間內(nèi)一個資源池的公平共享量的一半得不到滿足典蝌，則該資源池也會從其他資源池中搶占曙砂，這稱為公平共享量搶占。

進行資源搶占時骏掀，調(diào)度器會選出超額使用資源的資源池鸠澈，并從中找出啟動時間最早的任務(wù)，再將其殺掉截驮，進而釋放資源笑陈。

Fair Scheduler與Capacity Scheduler對比

image.png

小結(jié)

本章介紹了幾種常見的多用戶作業(yè)調(diào)度器。相比于FIFO調(diào)度器葵袭，多用戶調(diào)度器能夠更好地滿足不同應(yīng)用程序的服務(wù)質(zhì)量要求涵妥。

前主要有兩種多用戶作業(yè)調(diào)度器的設(shè)計思路：第一種是在一個物理集群上虛擬多個Hadoop集群，這些集群各自擁有全套獨立的Hadoop服務(wù)坡锡，比如JobTracker蓬网、TaskTracker等，典型的代表是HOD（Hadoop On Demand）調(diào)度器娜氏；另一種是擴展Hadoop調(diào)度器拳缠，使之支持多個隊列多用戶，典型的代表是Yahoo贸弥！的Capacity Scheduler和Facebook的Fair Scheduler。

HOD調(diào)度器是一個在共享物理集群上管理若干個Hadoop集群的工具海渊，它可以幫助用戶在一個共享物理集群上快速搭建若干個獨立的虛擬Hadoop集群绵疲。由于該調(diào)度器會產(chǎn)生多個獨立的小集群，因此會增加集群運維成本和降低資源利用率臣疑。

為了克服HOD的缺點盔憨，Capacity Scheduler和Fair Scheduler出現(xiàn)了。它們通過擴展調(diào)度器功能讯沈，在不拆分集群的前提下郁岩，將集群中的資源和用戶分成若干個隊列，并為每個隊列分配一定量的資源，同時添加各種限制以防止用戶或者隊列獨占資源问慎。由于這種方式能夠保證只有一個Hadoop集群萍摊，因此可大大降低運維成本，同時很容易實現(xiàn)資源共享如叼，進而可明顯提高資源利用率冰木。