1. Yarn 產生背景

1.1 MRv1 的局限性

擴展性差：在MRV1中，jobtracker同時兼備了資源管理和作業控制兩個功能，這成為系統的一個最大瓶頸，嚴重制約了hadoop集群擴展性。

資源利用率低：MRV1采用了基于槽位的資源分配模型，槽位是一種粗粒度的資源劃分單位，通常一個任務不會用完槽位對應的資源，且其他任務也無法使用這些空閑資源

無法支持多種計算框架：隨著互聯網高速發展，mapreduce這種基于磁盤的離線計算框架已經不能滿足應用要求，從而出現了一些新的計算框架，包括內存計算框架、流式計算框架和迭代式計算框架等，而MRV1不能支持多種計算框架并存。

2. Yarn基本設計思想

2.1 基本框架對比

在Hadoop1.0中，JobTracker由資源管理器（由TaskScheduler模塊實現）和作業控制（由JobTracker中多個模塊共同實現而成）兩部分組成。

• Hadoop MapReduce存在的問題：MRV1之所以存在可擴展性、資源利用率和多框架等支持方面不足的問題，正是由于Hadoop中JobTracker中賦予的功能過多導致負載過重。

JobTracker的兩個主要功能，即資源管理和作業控制（包括作業監控和容錯），分拆成兩個獨立的進程。

• 資源管理進程與具體應用程序無關，它負責整個集群的資源管理（內存、CPU、磁盤等）管理
• 作業控制進程則是直接與應用程序相關的模塊，且每個作業控制進程只負責管理一個作業。

2.2 編程模型對比

MRv1主要由編程模型、數據處理引擎和運行環境三部分組成

為了保證編程模型的兼容性，MRv2重用了其編程模型和數據處理引擎，但運行環境被完成重寫

• 編程模型與數據處理引擎：MRv2重用了MRv1的編程模型和數據處理引擎。為了能夠讓用戶應用程序平滑遷移到Hadoop2.0中，MRv2應盡可能保證編程接口的向后兼容性。
• 運行時環境：MRv1的運行時候環境主要有兩類組成。分別是JobTracker和TaskTracker。其中，JobTracker復制資源管理和任務的管理和調度。TaskTracker負責每個節點的資源管理和任務執行。而MRv2則通過將資源管理和應用程序管理分離開來，分別由Yarn和ApplicationMaster負責，其中，Yarn負責資源管理和調度，而ApplicationMaster負責與具體應用程序相關的任務切分、調度和容錯。

3 Yarn基本架構

Yarn 的基本思想：將MRv1中的JobTracker拆分成兩個獨立的服務：一個全局的資源管理器ResourceManager和每個應用程序獨有的ApplicationMaster。其中ResourceMangager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。

3.1 Yarn基本組成結構

YARN總體上仍然是Master/Slave結構，在整個資源管理框架中，ResourceManager為Master，NodeManager為Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。

ResourceManager（RM）

ResourceManager 是一個全局的資源管理器，負責整個集群的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Master，ASM）。

• 調度器：該調度器是一個 “純調度器”，不再參與任何與具體應用程序邏輯相關的工作，而僅根據各個應用程序的資源需求進行分配，資源分配的單位用一個資源抽象概念 “Container” 來表示。Container 封裝了內存和 CPU。此外，調度器是一個可插拔的組件，用戶可根據自己的需求設計新的調度器，YARN 自身提供了 Fair Scheduler 和 Capacity Scheduler。
• 應用程序管理器：應用程序管理器負責管理整個系統中所有應用程序，包括應用程序的提交、與調度器協商資源以啟動 ApplicationMaster、監控 ApplicationMaster 運行狀態并在失敗時重新啟動它等。

ApplicationMaster

用戶提交的每個 Application 都要包含一個 ApplicatioNMaster，主要功能包括：

• 向 RM 調度器申請資源（用 Container 表示）
• 將從 RM 分配的資源分配給 Applcation 內部的任務
• 與 NM 通信請求 啟動/停止 任務
• 監控所有任務的運行狀態，并在失敗時重新為任務申請資源以重啟任務

NodeManager

NM 是每個節點上的資源和任務管理器，一方面，它會定時地向 RM 匯報本節點上的資源使用情況和各個 Container 的運行狀態；另一方面，它接收并處理來自 AM 的 Container 啟動/停止 等各種命令。

Container

Container 是 YARN 中資源抽象，它封裝了某個節點上的內存和 CPU、磁盤、網絡等，當 AM 向 RM 申請資源時，RM 為 AM 返回的資源便是用 Container 表示的。YARN 是使用輕量級資源隔離機制 Cgroups 進行資源隔離的。

3.2 YARN 通信協議

在 YARN 中，任何兩個需要相互通信的組件之間僅有一個 RPC 協議，而對于任何一個 RPC 協議，通信雙方有一端是 Client，另一端是 Server，且 Client 總是主動連接 Server。YARN 中有以下幾個主要的 RPC 協議：

• JobClient 與 RM 之間的協議：ApplicationClientProtocol，JobClient 通過該 RPC 協議提交應用程序、查詢應用程序狀態等
• Admin（管理員）與 RM 之間的協議：ResourceManagerAdministrationProtocol，Admin 通過該 RPC 協議更新系統配置文件，比如節點黑白名單、用戶隊列權限等
• AM 與 RM 之間的協議：ApplicationMasterProtocol，AM 通過該 RPC 協議向 RM 注冊并撤銷自己，并為各個人物申請資源
• NM 與 RM 之間的協議：ResourceTracker，NM 通過該協議向 RM 注冊，并定時發送心跳信息匯報當前節點的資源使用情況和 Container 運行情況，并接收來自 AM 的命令
• AM 與 NM 之間的協議：ContainerManagermentProtocol，AM 通過該 RPC 協議要求 NM 啟動或者停止 Container

3.3 YARN 工作流程

YARN 的工作流程如上所示：

Client 向 YARN 提交應用程序，其中包括 ApplicationMaster 程序及啟動 ApplicationMaster 的命令

ResourceManager 為該 ApplicationMaster 分配第一個 Container，并與對應的 NodeManager 通信，要求它在這個 Container 中啟動應用程序的 ApplicationMaster

ApplicationMaster 首先向 ResourceManager 注冊, 這樣用戶可以直接通過ResourceManager查看應用程序的運行狀態，然后它將為各個任務申請資源，并監控它們的運行狀態，直到運行結束，即重復4~7

ApplicationMaster 為 Application 的任務申請并領取資源

領取到資源后，要求對應的 NodeManager 在 Container 中啟動任務

NodeManager 收到 ApplicationMaster 的請求后，為任務設置好運行環境（包括環境變量、JAR 包、二進制程序等），將任務啟動腳本寫到一個腳本中，并通過運行該腳本啟動任務

各個任務通過 RPC 協議向 ApplicationMaster 匯報自己的狀態和進度，以讓 ApplicationMaster 隨時掌握各個任務的運行狀態，從而可以在失敗時重啟任務

應用程序完成后，ApplicationMaster 向 ResourceManager 注銷并關閉自己
。

4. 理解YARN

4.1 并行編程

將YARN看做是一個云操作系統，它負責應用程序啟動ApplicationMaster（相當于主進程），然后由ApplicationMaster進行數據切分、任務分配、啟動和監控等工作，而由ApplicationMaster啟動的各個Task(相當于子線程)僅僅負責自己的計算任務。

4.2 資源管理系統

資源管理系統地主要功能是對集群中各類資源進行抽象，并根據各種應用程序或者服務的要求，按照一定的調度策略，將資源分配給它們使用，同時采用一定的資源隔離機制防止應用程序或者服務之間因資源搶奪而相互干擾。

總結

以上是生活随笔為你收集整理的Hadoop详解（十一）：Yarn设计理念与基本架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。