- YARN的簡介
- 什么是YARN
- MRv1的架構和缺陷
- 經典MapReduce的局限性
- 解決可伸縮性問題
- YARN的架構
- 一個可運行任何分布式應用程序的集群
- YARN中的應用程序提交
- YARN的其他特性
- 總結
YARN的簡介
什么是YARN
Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層應用提供統一的資源管理和調度。它將資源管理和處理組件分開，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。
MRv1的架構和缺陷
Apache Hadoop 是一個開源軟件框架，可安裝在一個商用機器集群中，使機器可彼此通信並協同工作，以高度分布式的方式共同存儲和處理大量數據。
經典 MapReduce的局限性
經典MapReduce最嚴重的限制：可伸縮性、資源利用、對不同工作負載的支持
在 MapReduce 框架中，作業執行受兩種類型的進程控制：
- 一個稱為 JobTracker 的主要進程，它協調在集群上運行的所有作業，分配要在 TaskTracker 上運行的 map 和 reduce 任務。
- 許多稱為 TaskTracker 的下級進程，它們運行分配的任務並定期向 JobTracker 報告進度。
Apache Hadoop 的經典版本 (MRv1)
大型的 Hadoop 集群顯現出了由單個 JobTracker 導致的可伸縮性瓶頸。依據 Yahoo!，在集群中有 5,000 個節點和 40,000 個任務同時運行時，這樣一種設計實際上就會受到限制。由於此限制，必須創建和維護更小的、功能更差的集群。
此外，較小和較大的 Hadoop 集群都從未最高效地使用他們的計算資源。在 Hadoop MapReduce 中，每個從屬節點上的計算資源由集群管理員分解為固定數量的 map 和 reduce slot，這些 slot 不可替代。設定 map slot 和 reduce slot 的數量后，節點在任何時刻都不能運行比 map slot 更多的 map 任務，即使沒有 reduce 任務在運行。這影響了集群的利用率，因為在所有 map slot 都被使用（而且我們還需要更多）時，我們無法使用任何 reduce slot，即使它們可用，反之亦然。
解決可伸縮性問題
在Hadoop MapReduce中，JobTracker具有兩種不同的職責：
- 管理集群中的計算資源，這涉及到維護活動節點列表、可用和占用的 map 和 reduce slots 列表，以及依據所選的調度策略將可用 slots 分配給合適的作業和任務
- 協調在集群上運行的所有任務，這涉及到指導 TaskTracker 啟動 map 和 reduce 任務，監視任務的執行，重新啟動失敗的任務，推測性地運行緩慢的任務，計算作業計數器值的總和，等等
為單個進程安排大量職責會導致重大的可伸縮性問題，尤其是在較大的集群上，JobTracker 必須不斷跟蹤數千個 TaskTracker、數百個作業，以及數萬個 map 和 reduce 任務。下圖演示了這一問題。相反，TaskTracker 通常僅運行十來個任務，這些任務由勤勉的 JobTracker 分配給它們。
大型 Apache Hadoop 集群 (MRv1) 上繁忙的 JobTracker
為了解決可伸縮性問題，一個簡單而又絕妙的想法應運而生：我們減少了單個 JobTracker 的職責，將部分職責委派給 TaskTracker，因為集群中有許多 TaskTracker。在新設計中，這個概念通過將 JobTracker 的雙重職責（集群資源管理和任務協調）分開為兩種不同類型的進程來反映。
不再擁有單個 JobTracker，一種新方法引入了一個集群管理器，它惟一的職責就是跟蹤集群中的活動節點和可用資源，並將它們分配給任務。對於提交給集群的每個作業，會啟動一個專用的、短暫的 JobTracker 來控制該作業中的任務的執行。有趣的是，短暫的 JobTracker 由在從屬節點上運行的 TaskTracker 啟動。因此，作業的生命周期的協調工作分散在集群中所有可用的機器上。得益於這種行為，更多工作可並行運行，可伸縮性得到了顯著提高。
YARN的架構
- ResourceManager 代替集群管理器
- ApplicationMaster 代替一個專用且短暫的 JobTracker
- NodeManager 代替 TaskTracker
- 一個分布式應用程序代替一個 MapReduce 作業
YARN的架構
在 YARN 架構中，一個全局 ResourceManager 以主要后台進程的形式運行，它通常在專用機器上運行，在各種競爭的應用程序之間仲裁可用的集群資源。ResourceManager 會追蹤集群中有多少可用的活動節點和資源，協調用戶提交的哪些應用程序應該在何時獲取這些資源。ResourceManager 是惟一擁有此信息的進程，所以它可通過某種共享的、安全的、多租戶的方式制定分配（或者調度）決策（例如，依據應用程序優先級、隊列容量、ACLs、數據位置等）。
在用戶提交一個應用程序時，一個稱為 ApplicationMaster 的輕量型進程實例會啟動來協調應用程序內的所有任務的執行。這包括監視任務，重新啟動失敗的任務，推測性地運行緩慢的任務，以及計算應用程序計數器值的總和。這些職責以前分配給所有作業的單個 JobTracker。ApplicationMaster 和屬於它的應用程序的任務，在受 NodeManager 控制的資源容器中運行。
NodeManager 是 TaskTracker 的一種更加普通和高效的版本。沒有固定數量的 map 和 reduce slots，NodeManager 擁有許多動態創建的資源容器。容器的大小取決於它所包含的資源量，比如內存、CPU、磁盤和網絡 IO。目前，僅支持內存和 CPU (YARN-3)。未來可使用 cgroups 來控制磁盤和網絡 IO。一個節點上的容器數量，由配置參數與專用於從屬后台進程和操作系統的資源以外的節點資源總量（比如總 CPU 數和總內存）共同決定。
有趣的是，ApplicationMaster 可在容器內運行任何類型的任務。例如，MapReduce ApplicationMaster 請求一個容器來啟動 map 或 reduce 任務，而 Giraph ApplicationMaster 請求一個容器來運行 Giraph 任務。您還可以實現一個自定義的 ApplicationMaster 來運行特定的任務，進而發明出一種全新的分布式應用程序框架，改變大數據世界的格局。您可以查閱 Apache Twill，它旨在簡化 YARN 之上的分布式應用程序的編寫。
在 YARN 中，MapReduce 降級為一個分布式應用程序的一個角色（但仍是一個非常流行且有用的角色），現在稱為 MRv2。MRv2 是經典 MapReduce 引擎（現在稱為 MRv1）的重現，運行在 YARN 之上。
一個可運行任何分布式應用程序的集群
ResourceManager、NodeManager 和容器都不關心應用程序或任務的類型。所有特定於應用程序框架的代碼都轉移到它的 ApplicationMaster，以便任何分布式框架都可以受 YARN 支持 — 只要有人為它實現了相應的 ApplicationMaster。
得益於這個一般性的方法，Hadoop YARN 集群運行許多不同工作負載的夢想才得以實現。想像一下：您數據中心中的一個 Hadoop 集群可運行 MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI 等。
單一集群方法明顯提供了大量優勢，其中包括：
- 更高的集群利用率，一個框架未使用的資源可由另一個框架使用
- 更低的操作成本，因為只有一個 “包辦一切的” 集群需要管理和調節
- 更少的數據移動，無需在 Hadoop YARN 與在不同機器集群上運行的系統之間移動數據
管理單個集群還會得到一個更環保的數據處理解決方案。使用的數據中心空間更少，浪費的硅片更少，使用的電源更少，排放的碳更少，這只是因為我們在更小但更高效的 Hadoop 集群上運行同樣的計算。
YARN 中的應用程序提交
YARN 中的應用程序提交
假設用戶采用與 MRv1 中相同的方式鍵入 hadoop jar 命令，將應用程序提交到 ResourceManager。ResourceManager 維護在集群上運行的應用程序列表，以及每個活動的 NodeManager 上的可用資源列表。ResourceManager 需要確定哪個應用程序接下來應該獲得一部分集群資源。該決策受到許多限制，比如隊列容量、ACL 和公平性。ResourceManager 使用一個可插拔的 Scheduler。Scheduler 僅執行調度；它管理誰在何時獲取集群資源（以容器的形式），但不會對應用程序內的任務執行任何監視，所以它不會嘗試重新啟動失敗的任務。
在 ResourceManager 接受一個新應用程序提交時，Scheduler 制定的第一個決策是選擇將用來運行 ApplicationMaster 的容器。在 ApplicationMaster 啟動后，它將負責此應用程序的整個生命周期 首先也是最重要的是，它將資源請求發送到 ResourceManager，請求運行應用程序的任務所需的容器。資源請求是對一些容器的請求，用以滿足一些資源需求，比如：
- 一定量的資源，目前使用 MB 內存和 CPU 份額來表示
- 一個首選的位置，由主機名、機架名稱指定，或者使用 * 來表示沒有偏好
- 此應用程序中的一個優先級，而不是跨多個應用程序
如果可能的話，ResourceManager 會分配一個滿足 ApplicationMaster 在資源請求中所請求的需求的容器（表達為容器 ID 和主機名）。該容器允許應用程序使用特定主機上給定的資源量。分配一個容器后，ApplicationMaster 會要求 NodeManager（管理分配容器的主機）使用這些資源來啟動一個特定於應用程序的任務。此任務可以是在任何框架中編寫的任何進程（比如一個 MapReduce 任務或一個 Giraph 任務）。NodeManager 不會監視任務；它僅監視容器中的資源使用情況，舉例而言，如果一個容器消耗的內存比最初分配的更多，它會結束該容器。
ApplicationMaster 會竭盡全力協調容器，啟動所有需要的任務來完成它的應用程序。它還監視應用程序及其任務的進度，在新請求的容器中重新啟動失敗的任務，以及向提交應用程序的客戶端報告進度。****應用程序完成后，ApplicationMaster 會關閉自己並釋放自己的容器。
盡管 ResourceManager 不會對應用程序內的任務執行任何監視，但它會檢查 ApplicationMaster 的健康狀況。如果 ApplicationMaster 失敗，ResourceManager 可在一個新容器中重新啟動它。您可以認為 ResourceManager 負責管理 ApplicationMaster，而 ApplicationMasters 負責管理任務。
YARN的其他特性
- 如果作業足夠小，Uberization 支持在 ApplicationMaster 的 JVM 中運行一個 MapReduce 作業的所有任務。這樣，您就可避免從 ResourceManager 請求容器以及要求 NodeManagers 啟動（可能很小的）任務的開銷。
- 與為 MRv1 編寫的 MapReduce 作業的二進制或源代碼兼容性 (MAPREDUCE-5108)。
- 針對 ResourceManager 的高可用性 (YARN-149)。此工作正在進行中，已由一些供應商完成。
- 重新啟動 ResourceManager 后的應用程序恢復 (YARN-128)。ResourceManager 將正在運行的應用程序和已完成的任務的信息存儲在 HDFS 中。如果 ResourceManager 重新啟動，它會重新創建應用程序的狀態，僅重新運行不完整的任務。此工作已接近完成，社區正在積極測試。它已由一些供應商完成。
- 簡化的用戶日志管理和訪問。應用程序生成的日志不會留在各個從屬節點上（像 MRv1 一樣），而轉移到一個中央存儲區，比如 HDFS。在以后，它們可用於調試用途，或者用於歷史分析來發現性能問題。
- Web 界面的新外觀。
總結
YARN(Yet Another Resource Negotiator)，也稱Hadoop2.0，是新一代的通用資源管理系統。它在Hadoop 1.0(MRv1)的基礎上，提供了更強大的可伸縮性和靈活性。對原有的架構進行了去中心化的處理，將資源管理和任務協調分為兩個不同的進程來處理。此外，它特定的ApplicationMaster支持在容器（cpu、內存、磁盤和網絡IO等資源）內運行任何類型的任務，給創造新的分布式應用程序框架提供了條件，從而除了MapReduce之外，它還可以運行Giraph、Storm、Spark、Tez/Impala、MPI 等，只需要使用特定的ApplicationMaster即可。