YARN

YARN

Apache YARN(Yet Another Resource Negotiator) 是Hadoop集羣的資源管理系統。YARN爲應用使用提供請求集羣資源的API，對使用者而言，這些分佈式計算框架的細節被YARN的資源管理所隱藏。下圖展示的是分佈式計算框架（MapReduce，spark等）運行在集羣計算層（YARN）和集羣存儲層（HDFS，HBase）上。

其中pig，hive等是調用MapReduce的運行。

YARN的架構

YARN的體系架構見圖：

YARN總體上是Master/Slave結構，主要由ResourceManager、NodeManager、 ApplicationMaster和Container等幾個組件構成。

ResourceManager(RM) ：負責對各NM上的資源進行統一管理和調度。將AM分配空閒的Container運行並監控其運行狀態。對AM申請的資源請求分配相應的空閒Container。主要由兩個組件構成：調度器和應用程序管理器

1、調度器(Scheduler)：調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位是Container，從而限定每個任務使用的資源量。Shceduler不負責監控或者跟蹤應用程序的狀態，也不負責任務因爲各種原因而需要的重啓（由ApplicationMaster負責）。總之，調度器根據應用程序的資源要求，以及集羣機器的資源情況，爲應用程序分配封裝在Container中的資源。 調度器是可插拔的，例如CapacityScheduler、FairScheduler。具體看下文的調度算法。

2、應用程序管理器(Applications Manager)：應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啓動AM、監控AM運行狀態並在失敗時重新啓動等，跟蹤分給的Container的進度、狀態也是其職責。

NodeManager (NM) ：NM是每個節點上的資源和任務管理器。它會定時地向RM彙報本節點上的資源使用情況和各個Container的運行狀態；同時會接收並處理來自AM的Container 啓動/停止等請求。

ApplicationMaster (AM)： 用戶提交的應用程序均包含一個AM，負責應用的監控，跟蹤應用執行狀態，重啓失敗任務等。ApplicationMaster是應用框架，它負責向ResourceManager協調資源，並且與NodeManager協同工作完成Task的執行和監控。MapReduce就是原生支持的一種框架，可以在YARN上運行Mapreduce作業。有很多分佈式應用都開發了對應的應用程序框架，用於在YARN上運行任務，例如Spark，Storm等。如果需要，我們也可以自己寫一個符合規範的YARN application。

Container： Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM爲AM返回的資源便是用Container 表示的。 YARN會爲每個任務分配一個Container且該任務只能使用該Container中描述的資源。

解剖YARN的運行

YARN通過2個常駐後臺程序提供它的核心服務：

1、ResourceManager（RM）：對集羣中資源的使用進行管理；

2、NodeManager（NM）：運行在集羣的所有節點從而去發起並監視containers。

container是在有限的資源下執行一個特別的應用進程。下圖是YARN運行應用的流程圖。

a、用戶向YARN中提交應用程序，其中包括AM程序、啓動AM的命令、命令參數、用戶程序等；事實上，需要準確描述運行ApplicationMaster的unix進程的所有信息。提交工作通常由YarnClient來完成。

b、RM爲該應用程序分配第一個Container，並與對應的NM通信，要求它在這個Container中啓動AM；

c、AM首先向RM註冊，這樣用戶可以直接通過RM査看應用程序的運行狀態，運行狀態通過 AMRMClientAsync.CallbackHandler的getProgress() 方法來傳遞給RM。 然後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟d〜g；

d、AM採用輪詢的方式通過RPC協議向RM申請和領取資源；資源的協調通過 AMRMClientAsync異步完成,相應的處理方法封裝在AMRMClientAsync.CallbackHandler中。

e、—旦AM申請到資源後，便與對應的NM通信，要求它啓動任務；通常需要指定一個ContainerLaunchContext，提供Container啓動時需要的信息。

f、NM爲任務設置好運行環境(包括環境變量、JAR包、二進制程序等)後，將任務啓動命令寫到一個腳本中，並通過運行該腳本啓動任務；

g、各個任務通過某個RPC協議向AM彙報自己的狀態和進度，以讓AM隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啓動任務；ApplicationMaster與NM的通信通過NMClientAsync object來完成，容器的所有事件通過NMClientAsync.CallbackHandler來處理。例如啓動、狀態更新、停止等。

h、應用程序運行完成後，AM向RM註銷並關閉自己。

YARN資源調度器

ResourceManager分配集羣資源的時候，以抽象的Container形式分配給各應用程序，至於應用程序的子任務如何使用這些資源，由應用程序自行決定。主要有2種調度器：FIFO Scheduler 、Capacity Scheduler和Fair Scheduler。

Capacity Scheduler

適合於多用戶共享集羣的環境的調度器。在多用戶的情況下，達到最大化集羣的吞吐和利用率的目的。Capacity 調度器允許多個組織共享整個集羣，每個組織可以獲得集羣的一部分計算能力。通過爲每個組織分配專門的隊列，然後再爲每個隊列分配一定的集羣資源，這樣整個集羣就可以通過設置多個隊列的方式給多個組織提供服務了。除此之外，隊列內部又可以垂直劃分，這樣一個組織內部的多個成員就可以共享這個隊列資源了，在一個隊列內部，資源的調度是採用的是先進先出(FIFO)策略。下圖爲FIFO Scheduler

一個job可能使用不了整個隊列的資源。然而如果這個隊列中運行多個job，如果這個隊列的資源夠用，那麼就分配給這些job，如果這個隊列的資源不夠用了呢？其實Capacity調度器仍可能分配額外的資源給這個隊列，這就是彈性隊列(queue elasticity)的概念。

一般情況下，Capacity調度器不會強制釋放Container，當一個隊列資源不夠用時，這個隊列只能獲得其它隊列釋放後的Container資源。當然，我們可以爲隊列設置一個最大資源使用量，以免這個隊列過多的佔用空閒資源，導致其它隊列無法使用這些空閒資源，這就是彈性隊列需要權衡的地方。

Capacity Scheduler特點

• 容量保證：每個隊列都分配了一部分容量，他們可以支配着部分資源。提交到特定隊列的應用程序，可以使用該隊列的資源。管理員可以配置每個隊列容量的最低保證和資源使用上限。

• 安全性：每個隊列都有嚴格的ACL（控制訪問列表），它可以控制用戶提交應用程序到特定隊列上。同時保證用戶不能查看或修改其它用戶提交的應用程序，並且隊列管理員和集羣系統管理員可以對其進行維護。

• 靈活性：隊列的空閒資源可以分配各其它隊列使用。如果某隊列的資源分配未達到隊列資源使用上限，在其需要更多資源時，將分配其它隊列的空閒資源給該繁忙隊列。

• 多用戶性：支持多用戶共享集羣，一些列的綜合設置可以防止單個應用程序、用戶或隊列獨佔隊裏或集羣的全部資源。

• 可操作性：支持運行時配置和隊列停止。隊列的屬性（例如：資源容量分配、ACL等）可以在運行時由管理員以一種安全的方式更改，從而減少了對用戶的影響。同時提供給管理員和用戶一個界面，用於查看當前隊列資源的使用情況。管理員可以在集羣運行時添加新隊列，可以在停止運行的隊列的同時保證隊列上的任務運行完成，而新的任務不能提交到該隊列上。注意現在不支持在運行時刪除隊列，如果需要刪除隊列，需要重啓集羣。

• 層級隊列：層級隊列可確保資源在該組織的子隊列之間被共享，從而提供更多的可控制性和預測性。

• 基於資源的調度：支持資源密集型的應用程序，允許應用程序使用的資源量高於默認值，從而該調度器可以支持不同資源需求的應用程序。目前只支持內存資源的配置，通過配置可支持CPU資源。

Fair Scheduler

Fair Scheduler是由Facebook貢獻的，是Hadoop上一個可插拔式的調度器，允許YARN應用程序在一個大的集羣上公平地共享資源。公平調度是一種爲應用程序分配資源的方法，多用戶的情況下，強調用戶公平地使用資源。默認情況下Fair Scheduler根據內存資源對應用程序進行公平調度，通過配置可以修改爲根據內存和CPU兩種資源進行調度。當集羣中只有一個應用程序運行時，那麼此應用程序佔用這個集羣資源。當其他的應用程序提交後，那些釋放的資源將會被分配給新的應用程序，所以每個應用程序最終都能獲取幾乎一樣多的資源。

在Fair Scheduler中，不需要預先佔用一定的系統資源，Fair Scheduler會動態調整應用程序的資源分配。例如，當第一個大job提交時，只有這一個job在運行，此時它獲得了所有集羣資源；當第二個小任務提交後，Fair調度器會分配一半資源給這個小任務，讓這兩個任務公平的共享集羣資源。需要注意的是，在下圖Fair Scheduler中，從第二個任務提交到獲得資源會有一定的延遲，因爲它需要等待第一個任務釋放佔用的Container。小任務執行完成之後也會釋放自己佔用的資源，大任務又獲得了全部的系統資源。

Fair Scheduler允許爲隊列分配擔最小的共享資源量，這樣可以保證某些用戶、groups或者應用程序總能獲取充足的資源。當一個隊列中有正在運行的應用程序時，它至少能夠獲取設置的最小資源，當隊列中無任務時，它的資源將會被拆分給其他運行中的任務。

Fair Scheudler在默認情況下允許所有的任務運行，但是這也可以通過配置文件來限制每個用戶下和每個隊列下運行的任務個數。處於限制時，新提交的任務不會提交失敗，而是在Scheduler queue中等待，直到先前的任務結束，再執行。

Fair Scheduler vs Capacity Scheduler

相同點

• 都支持多用戶多隊列，即：適用於多用戶共享集羣的應用環境

• 都支持層級隊列

• 支持配置動態修改，更好的保證了集羣的穩定運行。

• 均支持資源共享，即某個隊列中的資源有剩餘時，可共享給其他缺資源的隊列

• 單個隊列均支持優先級和FIFO調度方式

不同點

• Capacity Scheduler與Fair Scheduler最大的區別爲調度策略的不同

• Capacity Scheduler的調度策略是，可以先選擇資源利用率低的隊列，然後在隊列中通過FIFO或DRF進行調度。

• Fair Scheduler的調度策略是，可以使用公平排序算法選擇隊列，然後再隊列中通過Fair（默認）、FIFO或DRF的方式進行調度。