一、Yarn 簡介
Yarn 是 hadoop 集羣的資源管理層。它允許不同的數據處理引擎（如圖形處理、交互式 SQL、流處理、批處理）運行在 hadoop 集羣中並處理 HDFS 中的數據（移動計算而非數據）。除了資源管理外，Yarn 還用於作業調用。
從資源管理方面看，Yarn 管理着由各個 NodeManager 節點的 vcore（CPU內核）和 RAM（運行時內存）共同組成的一組資源，比如我們的一個集羣由35個 NodeManager 節點共560 vcores 和 3.4TiB的內存組成，那麼 Yarn 管理的資源大小便是560 vcores + 3.4TiB RAM。當我們提交一個應用程序到 hadoop 集羣時，Yarn 便會爲這個應用程序分配一個資源池，這個資源池包含一定數量的 containers，每個 container 又包含一定數量的 vcores 和內存供應用程序運行。
二、Yarn 組件
Yarn 採用傳統的 master-slave 架構模式，其主要由 4 種組件組成，它們的主要功能如下：
- ResourceManager（RM）：全局資源管理器，負責整個系統的資源管理和分配；
- ApplicationMaster（AM）：負責應用程序（Application）的管理；
- NodeManager（NM）：負責 slave 節點的資源管理和使用；
- Container（容器）：對任務運行環境的一個抽象。
ResourceManager (RM)
ResourceManager 是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件組成：
- Scheduler：資源調度器，主要功能和特點如下：
- 負責將資源分配給各種正在運行的應用程序，這些應用程序受到容量、隊列等限制；
- Scheduler 是純調度程序，不會監視或跟蹤應用程序的狀態；
- 由於應用程序故障或硬件故障，它不提供有關重新啓動失敗任務的保證；
- Scheduler 根據應用程序的資源需求來執行其調度功能，它是基於資源容器的抽象概念來實現的，容器（Container）內包含內存、CPU、磁盤、網絡等因素；
- Scheduler 是一個可插拔的插件（即可配置），負責在各種隊列、應用程序等之間對集羣資源進行區分。當前支持的Scheduler類包括：FairScheduler、FifoScheduler、CapacityScheduler；
- Applocation Manager：負責接受 job 提交請求，爲應用程序分配第一個 Container 以運行 ApplicationMaster，並提供失敗時重新啓動運行着 ApplicationMaster 的 Container 的服務。
ApplicationMaster（AM）
當用戶提交一個應用程序時，將啓動一個被稱爲 ApplcationMaster 的輕量級進程的實例，用以協調應用程序內所有任務的執行。它的主要工作包括：
- 向 ResourceManager 申請並以容器（Container）的形式提供計算資源；
- 管理在容器內運行的任務：
- 跟蹤任務的狀態並監視它們的執行；
- 遇到失敗時，重新啓動失敗的任務；
- 推測性的運行緩慢的任務以及計算應用計數器的總值。 -
NodeManager（NM）
NodeManager 進程運行在集羣中的節點上，是每個節點上的資源和任務管理器。它的主要功能包括：
- 接收 ResourceManager 的資源分配請求，併爲應用程序分配具體的 Container；
- 定時地向 ResourceManager 彙報本節點上的資源使用情況和各個 Container 的運行狀態，以確保整個集羣平穩運行；
- 管理每個 Container 的生命週期；
- 管理每個節點上的日誌；
- 接收並處理來自 ApplicationMaster 的 Container 啓動/停止等請求。
Container（容器）
Container 是 Yarn 中的資源抽象，是執行具體應用的基本單位，它包含了某個 NodeManager 節點上的多維度資源，如內存、CPU、磁盤和網絡 IO，當然目前僅支持內存和 CPU。
任何一個 Job 或應用程序必須運行在一個或多個 Container 中，在 Yarn 中，ResourceManager 只負責告訴 ApplicationMaster 哪些 Containers 可以用，ApplicationMaster 需要自己去找 NodeManager 請求分配具體的 Container。
Container 和集羣節點的關係是：一個節點會運行多個 Container，但一個 Container 不會跨節點。
三、提交任務流程
客戶端向RM提交任務流程
說明：
- 客戶端向 RM 發出請求；
- RM 返回一個 ApplicationID 作爲迴應；
- 客戶端向 RM 迴應 Application Submission Context（ASC）和 Container Launch Context（CLC）信息。其中 ASC 包括 ApplicationID、user、queue，以及其它一些啓動 AM 相關的信息，CLC 包含了資源請求數（內存與CPU），Job 文件，安全 token，以及其它一些用於在 NM 上啓動 AM的信息；
- 當 ResourceManager 接受到 ASC 後，它會調度一個合適的 container 來啓動 AM，這個 container 經常被稱做 container 0。AM 需要請求其它的 container 來運行任務，如果沒有合適的 RM，AM 就不能啓動。當有合適的 container 時，RM 發請求到合適的 NM 上，來啓動 AM。這時候，AM 的 PRC 與監控的 URL 就已經建立了；
- 當 AM 啓動起來後，RM 迴應給 AM 集羣的最小與最大資源等信息。這時 AM 必須決定如何使用那麼當前可用的資源。YARN 不像那些請求固定資源的 scheduler，它能夠根據集羣的當前狀態動態調整；
- AM 根據從 RM 那裏得知的可使用的資源，它會請求一些一定數目的 container。這個請求可以是非常具體的包括具有多個資源最小值的 Container（例如額外的內存等）；
- RM 將會根據調度策略，儘可能的滿足 AM 申請的 container；
- AM 根據分配的信息，去找NM啓動對應的 container。
運行狀態交互
當一個任務運行時，AM 會向 RM 彙報心跳與進度信息，在這些心跳過程中，AM 可能會去申請或者釋放 Container。當任務完成時，AM 向 RM 發送一條任務結束信息然後退出。AM 與 RM 交互的示例如下圖：
四、總結
與 HDFS/HBase 一樣，Yarn 也使用了簡潔的 master-salve 架構，這不僅更容易讓人理解它的運行原理，也更方便了運維人員對集羣的管理，彷彿《道德經》中提到的“萬物之始，大道至簡，衍化至繁”一樣。同時，將集羣的資源抽象，這也可作爲將面向對象思想運用的一個經典示例，畢竟，一切皆對象 For Java。
五、參考鏈接
注：此文章主要爲學習的筆記，其中大量的翻譯了參考鏈接中的資料，並有改動，如有需要，請閱讀原文。