大數據之 Yarn 技術原理

Yarn 的基本介紹

Yarn 基本定義：

Apache Hadoop YARN（Yet Another Resource Negotiator, 另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可爲上層應用提供統一的資源管理和調度，它的引入爲集羣在利用率、資源統一管理和數據共享等方面帶來的巨大的好處。

YARN 在產品中的位置：

yarn 位置

圖：Yarn 在 FusionInsight 產品中的位置

YARN 是 Hadoop2.0 中的資源管理系統，它是一個通用的資源管理模塊，可爲各類應用程序提供資源管理和調度功能。

Yarn 是輕量級彈性計算平臺，除了 MapReduce 框架，還可以支持其他框架，如 Spark、Storm 等。

多種框架統一管理，共享集羣資源的優點：

資源利用率高
運維成本低
數據共享方便

YARN 的設計思路：

YARN 的設計是爲了解決 MapReduce1.0 中的一些缺陷。

存在單點故障。
JobTracker“大包大攬” 導致任務過重（任務多時內存開銷大，上限 4000 節點）。
容易出現內存溢出（分配資源只考慮 MapReduce 任務數，不考慮 CPU、內存）。
資源劃分不合理（強制劃分爲 slot ，包括 Map slot 和 Reduce slot）。

Yarn 架構思路：

設計

圖：Yarn 的架構思路：將原 Job Tacker 三大功能拆分

Yarn 的組件架構

Yarn 的組件架構：

Yarn 組件架構

圖：YARN 的組件架構圖

三大組件的主要功能介紹：

（1）ResourceManager：

處理客戶端請求
啓動 / 監控 ApplicationMaster
監控 NodeManager
資源分配與調度

（2）ApplicationMaster：

爲應用程序申請資源，並分配給內部任務
任務調度、監控與容錯

（3）NodeManager：

單個節點上的資源管理
處理來自 ResourceManger 的命令
處理來自 ApplicationMaster 的命令

ResourceManager：

ResourceManager（RM）是一個全局的資源管理器，負責整個系統的資源管理和分配，主要包括兩個組件，即調度器（Scheduler）和應用程序管理器（Applications Manager）。

調度器接收來自 ApplicationMaster 的應用程序資源請求，把集羣中的資源以 “容器” 的形式分配給提出申請的應用程序，容器的選擇通常會考慮應用程序所要處理的數據的位置，進行就近選擇，從而實現 “計算向數據靠攏”。

容器（Container）作爲動態資源分配單位，每個容器中都封裝了一定數量的 CPU、內存、磁盤等資源，從而限定每個應用程序可以使用的資源量。

調度器被設計成是一個可插拔的組件，YARN 不僅自身提供了許多種直接可用的調度器，也允許用戶根據自己的需求重新設計調度器。

應用程序管理器（Applications Manager）負責系統中所有應用程序的管理工作，主要包括應用程序提交、與調度器協商資源以啓動 ApplicationMaster、監控 ApplicationMaster 運行狀態並在失敗時重新啓動等。

ApplicationMaster：

ResourceManager 接收用戶提交的作業，按照作業的上下文信息以及從 NodeManager 收集來的容器狀態信息，啓動調度過程，爲用戶作業啓動一個 ApplicationMaster。

ApplicationMaster 的主要功能是：

（1）當用戶作業提交時，ApplicationMaster 與 ResourceManager 協商獲取資源，ResourceManager 會以容器的形式爲 ApplicationMaster 分配資源；

（2）把獲得的資源進一步分配給內部的各個任務（Map 任務或 Reduce 任務），實現資源的 “二次分配”；

（3）與 NodeManager 保持交互通信進行應用程序的啓動、運行、監控和停止，監控申請到的資源的使用情況，對所有任務的執行進度和狀態進行監控，並在任務發生失敗時執行失敗恢復（即重新申請資源重啓任務）；

（4）定時向 ResourceManager 發送 “心跳” 消息，報告資源的使用情況和應用的進度信息；

（5）當作業完成時，ApplicationMaster 向 ResourceManager 註銷容器，執行週期完成。

NodeManager：

NodeManager 是駐留在一個 YARN 集羣中的每個節點上的代理，主要負責：

容器生命週期管理。
監控每個容器的資源（CPU、內存等）使用情況。
跟蹤節點健康狀況。
以 “心跳” 的方式與 ResourceManager 保持通信。
向 ResourceManager 彙報作業的資源使用情況和每個容器的運行狀態。
接收來自 ApplicationMaster 的啓動 / 停止容器的各種請求。

需要說明的是，NodeManager 主要負責管理抽象的容器，只處理與容器相關的事情，而不具體負責每個任務（Map 任務或 Reduce 任務）自身狀態的管理，因爲這些管理工作是由 ApplicationMaster 完成的，ApplicationMaster 會通過不斷與 NodeManager 通信來掌握各個任務的執行狀態。

YARN 的部署：

Yarn 的部署

圖：Yarn 和 Hadoop 平臺其他組件的統一部署

在集羣部署方面，YARN 的各個組件是和 Hadoop 集羣中的其他組件進行統一部署的.

Yarn 的工作流程：

工作流程

圖：YARN 的工作流程圖

Yarn 的工作流程如下：

用戶編寫客戶端應用程序，向 YARN 提交應用程序，提交的內容包括 ApplicationMaster 程序，啓動 ApplicationMaster 的命令、用戶程序等。
YARN 中的 ResourceManager 負責接收和處理來自客戶端的請求，爲應用程序分配一個容器，在該容器中啓動一個 ApplicationMaster。
ApplicationMaster 被創建後會首先向 ResourceManager 註冊。
ApplicationMaster 採用輪詢的方式向 ResourceManager 申請資源。
ResourceManager 以 “容器” 的形式向提出申請的 ApplicationMaster 分配資源。
在容器中啓動任務（運行環境、腳本）。
各個任務向 ApplicationMaster 彙報自己的狀態和進度。
應用程序運行完成後，ApplicationMaster 向 ResourceManager 的應用程序管理器註銷並關閉自己。

Yarn 框架與 MapReduce1.0 框架的對比分析

從 MapReduce1.0 框架發展到 YARN 框架，客戶端並沒有發生變化，其大部分調用 API 及接口都保持兼容，因此，原來針對 Hadoop1.0 開發的代碼不用做大的改動，就可以直接放到 Hadoop2.0 平臺上運行。

總體而言，YARN 相對於 MapReduce1.0 來說具有以下優勢：

大大減少了承擔中心服務功能的 ResourceManager 的資源消耗。

ApplicationMaster 來完成需要大量資源消耗的任務調度和監控。

多個作業對應多個 ApplicationMaster，實現了監控分佈化。
MapReduce1.0 既是一個計算框架，又是一個資源管理調度框架，但是，只能支持 MapReduce 編程模型。而 YARN 則是一個純粹的資源調度管理框架，在它上面可以運行包括 MapReduce 在內的不同類型的計算框架，只要編程實現相應的 ApplicationMaster。
YARN 中的資源管理比 MapReduce1.0 更加高效。

以容器爲單位，而不是以 slot 爲單位。

Yarn 的發展目標：

YARN 的目標就是實現 “一個集羣多個框架”。

一個企業當中同時存在各種不同的業務應用場景，需要採用不同的計算框架。

MapReduce 實現離線批處理
使用 Impala 實現實時交互式查詢分析
使用 Storm 實現流式數據實時分析
使用 Spark 實現迭代計算

這些產品通常來自不同的開發團隊，具有各自的資源調度管理機制。

爲了避免不同類型應用之間互相干擾，企業就需要把內部的服務器拆分成多個集羣，分別安裝運行不同的計算框架，即 “一個框架一個集羣”。

導致問題

集羣資源利用率低
數據無法共享
維護代價高

發展

圖：在 Yarn 上部署各種計算框架

YARN 的目標就是實現 “一個集羣多個框架”，即在一個集羣上部署一個統一的資源。調度管理框架 YARN，在 YARN 之上可以部署其他各種計算框架
由 YARN 爲這些計算框架提供統一的資源調度管理服務，並且能夠根據各種計算框架的負載需求，調整各自佔用的資源，實現集羣資源共享和資源彈性收縮。
可以實現一個集羣上的不同應用負載混搭，有效提高了集羣的利用率。
不同計算框架可以共享底層存儲，避免了數據集跨集羣移動。

Yarn HA：

Yarn HA

圖：YARN HA 方案

Yarn 中的 ResourceManager 負責整個集羣的資源管理和任務調度，Yarn 高可用性方案通過引入冗餘的 ResourceManager 節點的方式，解決了 ResourceManager 單點故障問題。

Yarn APPMaster 容錯機制：

APP 容錯

圖：Yarn APPMaster 容錯機制

Yarn 的資源管理和任務調度

資源管理：

當前 Yarn 支持內存和 CPU 兩種資源類型的管理和分配。

每個 NodeManager 可分配的內存和 CPU 的數量可以通過配置選項設置（可在 Yarn 服務配置頁面配置）。

yarn.nodemanager.resource.memory-mb
yarn.nodemanager.vmem-pmem-ratio
yarn.nodemanager.resource.cpu-vcore

資源分配模型：

資源分配模型

圖：資源分配模型

調度器維護一羣隊列的信息、用戶可以向一個或多個隊列提交應用。
每次 NM 心跳的時候，調度器根據一定的規則選擇一個隊列，再在隊列上選擇一個應用，嘗試在這個應用上分配資源。
調度器會優先匹配本地資源的申請請求，其次是同機架的，最後是任意機器的。

容量調度器：

容量調度器的介紹：

容量調度器使得 Hadoop 應用能夠共享的、多用戶的、操作簡便的運行在集羣上，同時最大化集羣的吞吐量和利用率。

容量調度器以隊列爲單位劃分資源，每個隊列都有資源使用的下限和上限。每個用戶可以設定資源使用上限。管理員可以約束單個隊列、用戶或者作業的資源使用、支持作業優先級，但不支持搶佔。

容量調度器的特點：

容量保證：管理員可爲每個隊列設置資源最低保證和資源使用上限，所有提交到該隊列的應用程序共享這些資源。
靈活性：如果一個隊列中的資源有剩餘，可以暫時共享給那些需要資源的隊列，當該隊列有新的應用程序提交，則其他隊列釋放的資源會歸還給該隊列。
支持優先級：隊列支持任務優先級調度（默認是 FIFO）。
多重租賃：支持多用戶共享集羣和多應用程序同時運行。爲防止單個應用程序、用戶或者隊列獨佔集羣資源，管理員可以爲之增加多重約束。
動態更新配置參數：管理員可以根據需要動態修改配置參數，以實現在線集羣管理。

容量調度器的任務選擇：

調度時，首先按照以下策略選擇一個合適隊列：

資源利用最低的隊列優先，比如同級的兩個隊列 Q1 和 Q2，它們的容量均爲 30，而 Q1 已經使用 10，Q2 已使用 12，則會優先將資源分配給 Q1.
最小隊列層級優先。例如：QueueA 與 QueueB.childQueueB，則 QueueA 優先。
資源回收請求隊列優先。

然後按以下策略選擇該任務中一個任務：

按照任務優先級和提交時間順序選擇，同時考慮用戶資源量限制和內存限制。

隊列資源限制：

隊列的創建是在多租戶頁面，當創建一個租戶關聯 Yarn 服務時，會創建同名的隊列。比如先創建 QueueA，QueueB 兩個租戶即對應 Yarn 兩個隊列。

隊列的資源容量（百分比）：

例如，有 default，QueueA，QueueB 三個隊列，每個隊列都有一個 [隊列名].capacity 配置。

Default 隊列容量爲整個集羣資源的 20%。
QueueA 隊列容量爲整個集羣資源的 10%。
QueueB 隊列容量爲整個集羣資源的 10%，後臺有個影子隊列 root-default 使隊列之和達到 100%。

共享空閒資源：

由於存在資源共享，因此一個隊列使用的資源可能超過其容量，而最多使用資源量可通過該參數限制。
如果某個隊列任務較少，可將剩餘資源共享給其他隊列。例如 QueueA 的 maximum-capacity 配置爲 100，假設當前只有 QueueA 在運行任務，理論上 QueueA 可以佔用整個集羣 100% 的資源。

用戶限制：

每個用戶最低資源保障（百分比）

任何時刻，一個隊列中每個用戶可使用的資源量均由一定的限制，當一個隊列中同時運行多個用戶的任務時，每個用戶的可使用資源量在一個最小值與最大值之間浮動，其中，最大值取決於正在運行的任務數據，而最小值則由 minimum-user-limit-percent 決定。

例如：設置隊列 A 的這個值爲 25，即 yarn.scheduler.capacity.root.AueueA.minimum-user-limit-percent=25，那麼隨着任務的用戶增加，隊列資源的調整如下：

用戶

每個用戶最多可使用的資源量（所在隊列容量的倍數）

queue 容量的倍數，用來設置一個 user 可以獲取更多的資源。yarn.scheduler.capacity.root.QueueD.user-limit-factor=1. 默認值爲 1，表示一個 user 獲取的資源容量不能超過 queue 配置的 capacity，無論集羣有多少空閒字眼，最多不超過 maximum-capacity。

任務限制：

最大活躍任務數：整個集羣中允許的最大活躍任務數，包括運行或掛起狀態的所有任務，當提交的任務申請數據達到限制以後，新提交的任務將會被拒絕。默認 10000。yarn.scheduler.capacity.maximum-applications=10000.
每個隊列最大任務數：對於每個隊列，可以提交的最大任務數，以 QueueA 爲例，可以在隊列配置頁面配置，默認是 1000，即此隊列允許最多 1000 個活躍任務。
每個用戶可以提交的最大任務數：這個數值依賴每個隊列最大任務數。假設根據上面的結果，QueueA 最多可以提交 1000 個任務，那麼對於每個用戶而言，可以向 QueueA 提交的最大任務數爲：1000 yarn.scheduler.capacity.root.QueueA.minimum-user-limit-percent yarn.scheduler.capacity.root.QueueA.user-limit-factor.

Yarn 的增強特性

Yarn 動態內存管理：

動態內存管理

圖：Yarn 動態內存管理

Yarn 基於標籤調度：

標籤調度

圖：Yarn 基於標籤調度

常用維護命令

命令

常用性能調優參數：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sW2TwJKMnVX4DzhTFHPt6Q