【深入淺出 Yarn 架構與實現】5-1 Yarn 資源調度器基本框架

資源調度器是 YARN 中最核心的組件之一，它是 ResourceManager 中的一個插拔式服務組件，負責整個集群資源的管理和分配。 Yarn 預設提供了三種可用資源調度器，分別是FIFO (First In First Out )、 Yahoo! 的 Capacity Scheduler 和 ... ...

資源調度器是 YARN 中最核心的組件之一，它是 ResourceManager 中的一個插拔式服務組件，負責整個集群資源的管理和分配。
Yarn 預設提供了三種可用資源調度器，分別是FIFO (First In First Out )、 Yahoo! 的 Capacity Scheduler 和 Facebook 的 Fair Scheduler。
本節會重點介紹資源調度器的基本框架，在之後文章中詳細介紹 Capacity Scheduler 和 Fair Scheduler。

一、基本架構

資源調度器是最核心的組件之一，並且在 Yarn 中是可插拔的，Yarn 中定義了一套介面規範，以方便用戶實現自己的調度器，同時 Yarn 中自帶了FIFO，CapacitySheduler， FairScheduler三種常用資源調度器。

一）資源調度模型

Yarn 採用了雙層資源調度模型。

第一層中，RM 中的資源調度器將資源分配給各個 AM（Scheduler 處理的部分）
第二層中，AM 再進一步將資源分配給它的內部任務（不是本節關註的內容）

Yarn 的資源分配過程是非同步的，資源調度器將資源分配給一個應用程式後，它不會立刻 push 給對應的 AM，而是暫時放到一個緩衝區中，等待 AM 通過周期性的心跳主動來取（pull-based通信模型）

NM 通過周期心跳彙報節點信息
RM 為 NM 返回一個心跳應答，包括需要釋放的 container 列表等信息
RM 收到的 NM 信息觸發一個NODE_UPDATED事件，之後會按照一定策略將該節點上的資源分配到各個應用，並將分配結果放到一個記憶體數據結構中
AM 向 RM 發送心跳，獲得最新分配的 container 資源
AM 將收到的新 container 分配給內部任務

二）資源表示模型

NM 啟動時會向 RM 註冊，註冊信息中包含該節點可分配的 CPU 和記憶體總量，這兩個值均可通過配置選項設置，具體如下：

yarn.nodemanager.resource.memory-mb：可分配的物理記憶體總量，預設是8G
yarn.nodemanager.vmem-pmem-ratio：任務使用單位物理記憶體量對應最多可使用的虛擬記憶體，預設值是2.1，表示使用1M的物理記憶體，最多可以使用2.1MB的虛擬記憶體總量
yarn.nodemanager.resource.cpu-vcores：可分配的虛擬CPU個數，預設是8。為了更細粒度地劃分CPU資源和考慮到CPU性能差異，YARN允許管理員根據實際需要和CPU性能將每個物理CPU劃分成若幹個虛擬CPU，而管理員可為每個節點單獨配置可用的虛擬CPU個數，且用戶提交應用程式時，也可指定每個任務需要的虛擬CPU數

Yarn 支持的調度語義：

請求某個節點上的特定資源量
請求某個特定機架上的特定資源量
將某些節點加入（或移除）黑名單，不再為自己分配這些節點上的資源
請求歸還某些資源

Yarn 不支持的調度語義（隨著 Yarn 的不斷迭代，可能會在未來實現）：

請求任意節點上的特定資源量
請求任意機架上的特定資源量
請求一組或幾組符合某種特質的資源
超細粒度資源。比如CPU性能要求、綁定CPU等
動態調整Container資源，允許根據需要動態調整Container資源量

三）資源保證機制

當單個節點的閑置資源無法滿足應用的一個 container 時，有兩種策略：

放棄當前節點等待下一個節點；
在當前節點上預留一個 container 申請，等到節點有資源時優先滿足預留。

YARN 採用了第二種增量資源分配機制（當應用程式申請的資源暫時無法保證時，為應用程式預留一個節點上的資源直到累計釋放的空閑資源滿足應用程式需求），這種機制會造成浪費，但不會出現餓死現象

四）層級隊列管理

Yarn 的隊列是層級關係，每個隊列可以包含子隊列，用戶只能將任務提交到葉子隊列。管理員可以配置每個葉子隊列對應的操作系統用戶和用戶組，也可以配置每個隊列的管理員。管理員可以殺死隊列中的任何應用程式，改變任何應用的優先順序等。
隊列的命名用 . 來連接，比如 root.A1、root.A1.B1。

二、三種調度器

Yarn 的資源調度器是可以配置的，預設實現有三種 FIFO、CapacityScheduler、FairScheduler。

一）FIFO

FIFO 是 Hadoop設計之初提供的一個最簡單的調度機制：先來先服務。
所有任務被統一提交到一個隊里中，Hadoop按照提交順序依次運行這些作業。只有等先來的應用程式資源滿足後，再開始為下一個應用程式進行調度運行和分配資源。
優點：

原理是和實現簡單。也不需要任何單獨的配置

缺點：

無法提供 QoS，只能對所有的任務按照同一優先順序處理。
無法適應多租戶資源管理。先來的大應用程式把集群資源占滿，導致其他用戶的程式無法得到及時執行。
應用程式併發運行程度低。

二）Capacity Scheduler

Capacity Scheduler 容量調度是 Yahoo! 開發的多用戶調度器，以隊列為單位劃分資源。
每個隊列可設定一定比例的資源最低保證和使用上限。每個用戶也可設置一定的資源使用上限，以防資源濫用。並支持資源共用，將隊列剩餘資源共用給其他隊列使用。配置文件名稱為 capacity-scheduler.xml。
主要特點：

容量保證：可為每個隊列設置資源最低保證（capacity）和資源使用上限（maximum-capacity，預設100%），而所有提交到該隊列的應用程式可以共用這個隊列中的資源。
彈性調度：如果隊列中的資源有剩餘或者空閑，可以暫時共用給那些需要資源的隊列，一旦該隊列有新的應用程式需要資源運行，則其他隊列釋放的資源會歸還給該隊列，從而實現彈性靈活分配調度資源，提高系統資源利用率。
多租戶管理：支持多用戶共用集群資源和多應用程式同時運行。且可對每個用戶可使用資源量（user-limit-factor）設置上限。
安全隔離：每個隊列設置嚴格的ACL列表（acl_submit_applications），用以限制可以用戶或者用戶組可以在該隊列提交應用程式。

三）Fair Scheduler

Fair Scheduler 是 Facebook 開發的多用戶調度器。設計目標是為所有的應用分配「公平」的資源（對公平的定義可以通過參數來設置）。公平不僅可以在隊列中的應用體現，也可以在多個隊列之間工作。
在 Fair 調度器中，我們不需要預先占用一定的系統資源，Fair 調度器會為所有運行的 job 動態的調整系統資源。如下圖所示，當第一個大 job 提交時，只有這一個 job 在運行，此時它獲得了所有集群資源；當第二個小任務提交後，Fair 調度器會分配一半資源給這個小任務，讓這兩個任務公平的共用集群資源。
與Capacity Scheduler不同之處：

四）源碼繼承關係

看下麵三個圖中調度器的繼承關係。這三個 Scheduler 都繼承自 AbstractYarnScheduler。這個抽象類又 extends AbstractService implements ResourceScheduler。繼承 AbstractService 說明是一個服務，實現 ResourceScheduler 是 scheduler 的主要功能。

三者還有一些區別，FairScheduler 沒實現 Configurable 介面，少了 setConf() 方法；FifoScheduler 不支持資源搶占，FairScheduler 支持資源搶占卻沒實現 PreemptableResourceScheduler 介面。

在 YarnScheduler 中，定義了一個資源調度器應該實現的方法。在 AbstractYarnScheduler 中實現了大部分方法，若自己實現調度器可繼承該類，將發開重點放在資源分配實現上。

public interface YarnScheduler extends EventHandler<SchedulerEvent> {
  // 獲得一個隊列的基本信息
  public QueueInfo getQueueInfo(String queueName, boolean includeChildQueues,
      boolean recursive) throws IOException;

  // 獲取集群資源
  public Resource getClusterResource();

  /**
   * AM 和資源調度器之間最主要的一個方法
   * AM 通過該方法更新資源請求、待釋放資源列表、黑名單列表增減
   */
  @Public
  @Stable
  Allocation allocate(ApplicationAttemptId appAttemptId,
      List<ResourceRequest> ask, List<ContainerId> release,
      List<String> blacklistAdditions, List<String> blacklistRemovals,
      List<UpdateContainerRequest> increaseRequests,
      List<UpdateContainerRequest> decreaseRequests);

  // 獲取節點資源使用情況報告
  public SchedulerNodeReport getNodeReport(NodeId nodeId);

ResourceScheduler 本質是個事件處理器，主要處理10種事件（CapacityScheduler 還會多處理幾種搶占相關的事件），可以到對應 Scheduler 的 handle() 方法中查看這些事件處理邏輯：

NODE_ADDED: 集群中增加一個節點
NODE_REMOVED: 集群中移除一個節點
NODE_RESOURCE_UPDATE: 集群中有一個節點的資源增加了
NODE_LABELS_UPDATE: 更新node labels
NODE_UPDATE: 該事件是 NM 通過心跳和 RM 通信時發送的，會彙報該 node 的資源使用情況，同時觸發一次分配操作。
APP_ADDED: 增加一個Application
APP_REMOVED: 移除一個application
APP_ATTEMPT_ADDED: 增加一個application Attempt
APP_ATTEMPT_REMOVED: 移除一個application attempt
CONTAINER_EXPIRED: 回收一個超時的container

三、資源調度維度

目前有兩種：DefaultResourceCalculator 和 DominantResourceCalculator。

DefaultResourceCalculator: 僅考慮記憶體資源
DominantResourceCalculator: 同時考慮記憶體和 CPU 資源（後續更新中支持更多類型資源，FPGA、GPU 等）。該演算法擴展了最大最小公平演算法（max-min fairness）。
- 在 DRF 演算法中，將所需份額（資源比例）最大的資源稱為主資源，而 DRF 的基本設計思想則是將最大最小公平演算法應用於主資源上，進而將多維資源調度問題轉化為單資源調度問題，即 DRF 總是最大化所有主資源中最小的
- 感興趣的話，可到源碼中 DominantResourceCalculator#compare 探究實現邏輯
- 對應的論文《Dominant Resource Fairness: Fair Allocation of Multiple Resource Types》

（這裡註意！很多文章和書中寫的是「YARN 資源調度器預設採用了 DominantResourceCalculator」，實際並不是這樣的！）

FifoScheduler 預設使用 DefaultResourceCalculator 且不可更改。
CapacityScheduler 是在 capacity-scheduler.xml 中配置 yarn.scheduler.capacity.resource-calculator 參數決定的。
FairScheduler 才預設使用 DominantResourceCalculator。

四、資源搶占模型

這裡僅簡要介紹資源搶占模型，在後面的文章中會深入源碼分析搶占的流程。

在資源調度器中，每個隊列可設置一個最小資源量和最大資源量，其中，最小資源量是資源緊缺情況下每個隊列需保證的資源量，而最大資源量則是極端情況下隊列也不能超過的資源使用量
為了提高資源利用率，資源調度器（包括Capacity Scheduler和Fair Scheduler）會將負載較輕的隊列的資源暫時分配給負載重的隊列，僅當負載較輕隊列突然收到新提交的應用程式時，調度器才進一步將本屬於該隊列的資源分配給它。

五、總結

本文介紹了 Yarn 資源調度器的基本框架，包括基本架構，以及簡要介紹三種 YARN 實現的調度器，並對資源調度維度，資源搶占模型等進行了介紹。
後續文章中將會圍繞三種 YARN 調度器，深入源碼進行探究。看其在源碼中是如何一步步實現對應功能的。

參考文章：
《Hadoop 技術內幕：深入解析 YARN 架構設計與實現原理》第六章
深入解析yarn架構設計與技術實現-資源調度器
 Yarn源碼分析5-資源調度