Hadoop中Yarn架構是什么樣的

這篇文章主要介紹Hadoop中Yarn架構是什么樣的，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

先來看看Yarn平臺的基本架構：

    在Yarn的結構中，把原來JobTracker管的事兒(資源管理、任務調度)拆開了，資源調度讓ResourceManager干，任務調度讓ApplicationMaster管，這樣的好處就是能夠讓各個模塊各司其職，專一干一件事，就好比一個大領導每天如果不專心管理管隊，老跑去敲代碼，最后這個團隊必然存在問題。言歸正傳，既然要了解Yarn的架構，在這里有必要先解釋一下用戶提交一個任務都走了哪些流程：

    NodeManager啟動的時候，會向ResourceManager注冊自己的內存、CPU使用率等資源信息，供NodeManager調度。

    2. ApplicationMaster

    ApplicationMaster 負責管理應用程序的整個生命周期，每個應用程序都對應一個AM，主要功能有：

    (1) 與RM的調度器通訊，協商管理資源分配。

    (2) 與NM合作，在合適的容器中運行對應的task，并監控這些task執行。

    (3) 如果container出現故障，AM會重新向調度器申請資源。

    (4) 計算應用程序所需的資源量，并轉化成調度器可識別的協議。

    (5) AM出現故障后，ASM會重啟它，而由AM自己從之前保存的應用程序執行狀態中恢復應用程序。 

    3. NodeManager

    NodeManager替代了Hadoop v1版本中的TaskTracker，每個節點都會有一個NM，主要功能有：

    (1) 為應用程序啟動容器，同時確保申請的容器使用的資源不會超過節點上的總資源。

    (2) 為task構建容器環境，包括二進制可執行文件，jars等。

    (3) 為所在的節點提供了一個管理本地存儲資源的簡單服務，應用程序可以繼續使用本地存儲資源即使他沒有從RM那申請。比如：MapReduce可以使用該服務程序存儲map task的中間輸出結果。

    一個NodeManager上面可以運行多個Container，Container之間的資源互相隔離，類似于虛擬機的多個系統一樣，各自使用自己分配的資源。NodeManager會啟動一個監控進行用來對運行在它上面的Container進行監控，當某個Container占用的資源超過約定的閾值后，NodeManager就會將其殺死。

    4. Container

    Container可以說是一個對Application使用資源描述的集合(或容器)，可以看做一個可序列化的java對象，封裝了一些描述信息，例如：

    message ContainerProto {

    optional ContainerIdProto id = 1; //container id

    optional NodeIdProto nodeId = 2; //container（資源）所在節點

    optional string node_http_address = 3;

    optional ResourceProto resource = 4; //container資源量

    optional PriorityProto priority = 5; //container優先級

    optional hadoop.common.TokenProto container_token = 6; //container token，用于安全認證

    }

    Container的一些基本概念和工作流程如下：

    (1) Container是YARN中資源的抽象，它封裝了某個節點上一定量的資源（CPU和內存兩類資源）。它跟Linux Container沒有任何關系，僅僅是YARN提出的一個概念（從實現上看，可看做一個可序列化/反序列化的Java類）。

    (2) Container由ApplicationMaster向ResourceManager申請的，由ResouceManager中的資源調度器異步分配給ApplicationMaster；
    (3) Container的運行是由ApplicationMaster向資源所在的NodeManager發起的，Container運行時需提供內部執行的任務命令（可以使任何命令，比如java、Python、C++進程啟動命令均可）以及該命令執行所需的環境變量和外部資源（比如詞典文件、可執行文件、jar包等）。

    另外，一個應用程序所需的Container分為兩大類，如下：

    (1) 運行ApplicationMaster的Container：這是由ResourceManager（向內部的資源調度器）申請和啟動的，用戶提交應用程序時，可指定唯一的ApplicationMaster所需的資源；
    (2) 運行各類任務的Container：這是由ApplicationMaster向ResourceManager申請的，并由ApplicationMaster與NodeManager通信以啟動之。

以上兩類Container可能在任意節點上，它們的位置通常而言是隨機的，即ApplicationMaster可能與它管理的任務運行在一個節點上。

    5. YARN平臺的資源管理方案

    在YARN中，用戶以隊列的形式組織，每個用戶可屬于一個或多個隊列，且只能向這些隊列中提交application。每個隊列被劃分了一定比例的資源。
    YARN的資源分配過程是異步的，也就是說，資源調度器將資源分配給一個application后，不會立刻push給對應的ApplicaitonMaster，而是暫時放到一個緩沖區中，等待ApplicationMaster通過周期性的RPC函數主動來取，也就是說，采用了pull-based模型，而不是push-based模型，這個與MRv1是一致的。

    相比于MRv1中的資源調度器，盡管YANR的調度器也是插拔式的，但由于YARN采用了事件驅動的模型，因此編寫起來更加復雜，難度也遠遠大于MRv1。
    同MRv1一樣，YARN也自帶了三種常用的調度器，分別是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一個是默認的調度器，它屬于批處理調度器，而后兩個屬于多租戶調度器，它采用樹形多隊列的形式組織資源，更適合公司應用場景。需要注意的是，這三種調度器采用的算法與MRv1中的完全一致，只不過是根據YARN中資源調度器的對外接口重新實現了一遍，在此不再贅述。 

以上是“Hadoop中Yarn架構是什么樣的”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！