YARN并不是下一代MapReduce（MRv2）
下一代MapReduce與第一代MapReduce（MRv1）在編程接口、數(shù)據(jù)處理引擎（MapTask和ReduceTask）是完全一樣的， 可認為MRv2重用了MRv1的這些模塊，不同的是資源管理和作業(yè)管理系統(tǒng)，MRv1中資源管理和作業(yè)管理均是由JobTracker實現(xiàn)的，集兩個功能于一身，而在MRv2中，將這兩部分分開了， 其中，作業(yè)管理由ApplicationMaster實現(xiàn)，而資源管理由新增系統(tǒng)YARN完成，由于YARN具有通用性，因此YARN也可以作為其他計算框架的資源管理系統(tǒng)，不僅限于MapReduce，也是其他計算框架，比如Spark等， 通常而言，我們一般將運行在YARN上的計算框架稱為“X on YARN”，比如“MapReduce On YARN”, "Spark On YARN"，“Storm On YARN”等

總結：
mapreduce v1 與 v2 都是hadoop的計算框架
而yarn 是 分離開來的資源管理框架

下面可以看到 v2 與 YARN的關系：

圖片 6.png

原 Hadoop MapReduce 框架的問題

原來的 map-reduce V1 架構是簡單明了的，在最初推出的幾年，也得到了眾多的成功案例，獲得業(yè)界廣泛的支持和肯定，但隨著分布式系統(tǒng)集群的規(guī)模和其工作負荷的增長，原框架的問題逐漸浮出水面，主要的問題集中如下：

• JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
• JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的內(nèi)存開銷，潛在來說，也增加了 JobTracker fail 的風險，這也是業(yè)界普遍總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點主機的上限。
• 在 TaskTracker 端，以 map/reduce task 的數(shù)目作為資源的表示過于簡單，沒有考慮到 cpu/ 內(nèi)存的占用情況，如果兩個大內(nèi)存消耗的 task 被調(diào)度到了一塊，很容易出現(xiàn) 問題。

新 Hadoop Yarn 框架原理及運作機制

從業(yè)界使用分布式系統(tǒng)的變化趨勢和 hadoop 框架的長遠發(fā)展來看，MapReduce 的 JobTracker/TaskTracker 機制需要大規(guī)模的調(diào)整來修復它在可擴展性，內(nèi)存消耗，線程模型，可靠性和性能上的缺陷。在過去的幾年中，hadoop 開發(fā)團隊做了一些 bug 的修復，但是最近這些修復的成本越來越高，這表明對原框架做出改變的難度越來越大。

為從根本上解決舊 MapReduce 框架的性能瓶頸，促進 Hadoop 框架的更長遠發(fā)展，從 0.23.0 版本開始，Hadoop 的 MapReduce 框架完全重構，發(fā)生了根本的變化。新的 Hadoop MapReduce 框架命名為 MapReduceV2，其架構圖如下圖所示：

新的 Hadoop MapReduce 框架架構

重構根本的思想是將 JobTracker 兩個主要的功能分離成單獨的組件，這兩個功能是資源管理和任務調(diào)度 / 監(jiān)控。新的資源管理器（ResourceManager ）全局管理所有應用程序計算資源的分配。
每一個應用（原來叫做一個mapreduce作業(yè)）都會有一個ApplicationMaster 負責相應的調(diào)度和協(xié)調(diào)

Resourcemanager:

Mapreducev1版本只有一個jobtracker，jobtracker用來跟蹤和分配諸如cpu和內(nèi)存之類的資源，并處理mapreduce相關的作業(yè)跟蹤

在YARN里jobtracker的資源管理部分由一個被稱為資源管理的后臺程序來負責（resource manager）

application master

每個應用是一個單獨的mapreduce作業(yè)，但不同于以前所有的作業(yè)都由一個單獨的jobtracker來負責，
現(xiàn)在每個作業(yè)都有一個被稱為應用管理者的進程（application master），它運行在集群中某個工作節(jié)點上，功能相等于jobtracker。
這與一個集中式的jobtracker有很大不同，因為一個作業(yè)的應用管理者現(xiàn)在已經(jīng)完全與其他作業(yè)分離，這意味著即使jobtracker發(fā)生了災難性的錯誤，其他作業(yè)也不會受到影響。
更進一步說，因為jobtracker已經(jīng)被完全指定到了某個作業(yè)，所以多個jobtracker能在集群上同時運行

container

容器我們可以簡單的理解為單獨為這個容器做了一個虛擬資源
ResourceManager 是基于應用程序?qū)Y源的需求進行調(diào)度的 ; 每一個應用程序需要不同類型的資源因此就需要不同的容器。
每一個應用的 ApplicationMaster 的職責有：向調(diào)度器索要適當?shù)馁Y源容器，運行任務，跟蹤應用程序的狀態(tài)和監(jiān)控它們的進程，處理任務的失敗原因。

NodeManager

NodeManager 監(jiān)控數(shù)據(jù)節(jié)點的應用程序的資源使用情況 (CPU，內(nèi)存，硬盤，網(wǎng)絡 ) 并且向resource manager 匯報
NodeManager 功能比較專一，就是負責 Container 狀態(tài)的維護，并向 RM 保持心跳。
NodeManager 并不完全等同于tasktracker，因為tasktracker需要運行任務并保持心跳，在V2版本里運行任務的功能分配給了Application Master