在YARN中，資源排程器（ResourceScheduler）是一個非常核心的部件，它負責将各個節點上的資源封裝成container，并按照一定的限制條件（按隊列配置設定，每個隊列有一定的資源配置設定上限等）配置設定給各個application。
（注意：本文分析基于hadoop-2.0.3-alpha）
YARN的資料總管實際上是一個事件處理器，它需要處理來自外部的6種SchedulerEvent類型的事件，并根據事件的具體含義進行相應的處理。這6種事件含義如下：
（1） NODE_REMOVED
事件NODE_REMOVED表示叢集中被移除一個計算節點（可能是節點故障或者管理者主動移除），資源排程器收到該事件時需要從可配置設定資源總量中移除相應的資源量。
（2） NODE_ADDED
事件NODE_ADDED表示叢集中增加了一個計算節點，資源排程器收到該事件時需要将新增的資源量添加到可配置設定資源總量中。
（3）APPLICATION_ADDED
事件APPLICATION_ADDED 表示ResourceManager收到一個新的Application。通常而言，資料總管需要為每個application維護一個獨立的資料結構，以便于統一管理和資源配置設定。資料總管需将該Application添加到相應的資料結構中。
（4）APPLICATION_REMOVED
事件APPLICATION_REMOVED表示一個Application運作結束（可能成功或者失敗），資料總管需将該Application從相應的資料結構中清除。
（5） CONTAINER_EXPIRED
當資源排程器将一個container配置設定給某個ApplicationMaster後，如果該ApplicationMaster在一定時間間隔内沒有使用該container，則資源排程器會對該container進行再配置設定。
（6）NODE_UPDATE
NodeManager通過心跳機制向ResourceManager彙報各個container運作情況，會觸發一個NODE_UDDATE事件，由于此時可能有新的container得到釋放，是以該事件會觸發資源配置設定，也就是說，該事件是6個事件中最重要的事件，它會觸發資源排程器最核心的資源配置設定機制。
資源表示模型
目前YARN支援記憶體和CPU兩種資源類型的管理和配置設定。當NodeManager啟動時，會向ResourceManager注冊，而注冊資訊中會包含該節點可配置設定的CPU和記憶體總量，這兩個值均可通過配置選項設定，具體如下：
（1）yarn.nodemanager.resource.memory-mb
可配置設定的實體記憶體總量，預設是8*1024MB。
（2）yarn.nodemanager.vmem-pmem-ratio
每機關的實體記憶體總量對應的虛拟記憶體量，預設是2.1，表示每使用1MB的實體記憶體，最多可以使用2.1MB的虛拟記憶體總量。
（3）yarn.nodemanager.resource.cpu-core（預設是8）
可配置設定的CPU總個數，預設是8
（4）yarn.nodemanager.vcores-pcores-ratio
為了更細粒度的劃分CPU資源，YARN将每個實體CPU劃分成若幹個虛拟CPU，預設值為2。使用者送出應用程式時，可以指定每個任務需要的虛拟CPU個數。在MRAppMaster中，每個Map Task和Reduce Task預設情況下需要的虛拟CPU個數為1，使用者可分别通過mapreduce.map.cpu.vcores和mapreduce.reduce.cpu.vcores進行修改（對于記憶體資源，Map Task和Reduce Task預設情況下需要1024MB，使用者可分别通過mapreduce.map.memory.mb和mapreduce.reduce.memory.mb修改）。
（在最新版本2.1.0-beta中，yarn.nodemanager.resource.cpu-core和yarn.nodemanager.vcores-pcores-ratio兩個參數被遺棄，引入一個新參數yarn.nodemanager.resource.cpu-vcore，表示虛拟CPU個數，具體請閱讀YARN-782）
YARN對記憶體資源和CPU資源采用了不同的資源隔離方案。對于記憶體資源，為了能夠更靈活的控制記憶體使用量，YARN采用了程序監控的方案控制記憶體使用，即每個NodeManager會啟動一個額外監控線程監控每個container記憶體資源使用量，一旦發現它超過約定的資源量，則會将其殺死。采用這種機制的另一個原因是Java中建立子程序采用了fork()+exec()的方案，子程序啟動瞬間，它使用的記憶體量與父程序一緻，從外面看來，一個程序使用記憶體量可能瞬間翻倍，然後又降下來，采用線程監控的方法可防止這種情況下導緻swap操作。對于CPU資源，則采用了Cgroups進行資源隔離。具體可參考YARN-3。
資源配置設定模型
在YARN中，使用者以隊列的形式組織，每個使用者可屬于一個或多個隊列，且隻能向這些隊列中送出application。每個隊列被劃分了一定比例的資源。
YARN的資源配置設定過程是異步的，也就是說，資源排程器将資源配置設定給一個application後，不會立刻push給對應的ApplicaitonMaster，而是暫時放到一個緩沖區中，等待ApplicationMaster通過周期性的RPC函數主動來取，也就是說，采用了pull-based模型，而不是push-based模型，這個與MRv1是一緻的。
總結
相比于MRv1中的資源排程器，盡管YANR的排程器也是插拔式的，但由于YARN采用了事件驅動的模型，是以編寫起來更加複雜，難度也遠遠大于MRv1。
同MRv1一樣，YARN也自帶了三種常用的排程器，分别是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一個是預設的排程器，它屬于批處理排程器，而後兩個屬于多租戶排程器，它采用樹形多隊列的形式組織資源，更适合公司應用場景。需要注意的是，這三種排程器采用的算法與MRv1中的完全一緻，隻不過是根據YARN中資源排程器的對外接口重新實作了一遍，在此不再贅述。
轉自：http://dongxicheng.org/mapreduce-nextgen/yarnmrv2-resource-manager-resource-manager/