Hadoop 原理學習(8)Yarn 概述及其基本原理

一、Yarn 簡介

Yarn 是 hadoop 集羣的資源管理層。它允許不同的數據處理引擎(如圖形處理、交互式 SQL、流處理、批處理)運行在 hadoop 集羣中並處理 HDFS 中的數據(移動計算而非數據)。除了資源管理外,Yarn 還用於作業調用。

Yarn on hadoop

從資源管理方面看,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(容器):對任務運行環境的一個抽象。

Yarn 組件

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提交任務流程

說明:

  1. 客戶端向 RM 發出請求;
  2. RM 返回一個 ApplicationID 作爲迴應;
  3. 客戶端向 RM 迴應 Application Submission Context(ASC)和 Container Launch Context(CLC)信息。其中 ASC 包括 ApplicationID、user、queue,以及其它一些啓動 AM 相關的信息,CLC 包含了資源請求數(內存與CPU),Job 文件,安全 token,以及其它一些用於在 NM 上啓動 AM的信息;
  4. 當 ResourceManager 接受到 ASC 後,它會調度一個合適的 container 來啓動 AM,這個 container 經常被稱做 container 0。AM 需要請求其它的 container 來運行任務,如果沒有合適的 RM,AM 就不能啓動。當有合適的 container 時,RM 發請求到合適的 NM 上,來啓動 AM。這時候,AM 的 PRC 與監控的 URL 就已經建立了;
  5. 當 AM 啓動起來後,RM 迴應給 AM 集羣的最小與最大資源等信息。這時 AM 必須決定如何使用那麼當前可用的資源。YARN 不像那些請求固定資源的 scheduler,它能夠根據集羣的當前狀態動態調整;
  6. AM 根據從 RM 那裏得知的可使用的資源,它會請求一些一定數目的 container。這個請求可以是非常具體的包括具有多個資源最小值的 Container(例如額外的內存等);
  7. RM 將會根據調度策略,儘可能的滿足 AM 申請的 container;
  8. AM 根據分配的信息,去找NM啓動對應的 container。

運行狀態交互

當一個任務運行時,AM 會向 RM 彙報心跳與進度信息,在這些心跳過程中,AM 可能會去申請或者釋放 Container。當任務完成時,AM 向 RM 發送一條任務結束信息然後退出。AM 與 RM 交互的示例如下圖:

AM與RM交互示例

四、總結

與 HDFS/HBase 一樣,Yarn 也使用了簡潔的 master-salve 架構,這不僅更容易讓人理解它的運行原理,也更方便了運維人員對集羣的管理,彷彿《道德經》中提到的“萬物之始,大道至簡,衍化至繁”一樣。同時,將集羣的資源抽象,這也可作爲將面向對象思想運用的一個經典示例,畢竟,一切皆對象 For Java。

五、參考鏈接

注:此文章主要爲學習的筆記,其中大量的翻譯了參考鏈接中的資料,並有改動,如有需要,請閱讀原文。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章