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

資源排程器是 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-資源排程