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”等
總結(jié)：
mapreduce v1 與 v2 都是hadoop的計算框架
而yarn 是 分離開來的資源管理框架
下面可以看到 v2 與 YARN的關(guān)系：
原 Hadoop MapReduce 框架的問題
原來的 map-reduce V1 架構(gòu)是簡單明了的，在最初推出的幾年场航，也得到了眾多的成功案例缠导，獲得業(yè)界廣泛的支持和肯定，但隨著分布式系統(tǒng)集群的規(guī)模和其工作負荷的增長旗闽，原框架的問題逐漸浮出水面酬核，主要的問題集中如下：
- JobTracker 是 Map-reduce 的集中處理點，存在單點故障适室。
- JobTracker 完成了太多的任務(wù)嫡意，造成了過多的資源消耗，當(dāng) map-reduce job 非常多的時候捣辆，會造成很大的內(nèi)存開銷蔬螟，潛在來說，也增加了 JobTracker fail 的風(fēng)險汽畴，這也是業(yè)界普遍總結(jié)出老 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)整來修復(fù)它在可擴展性，內(nèi)存消耗嘁酿，線程模型隙券，可靠性和性能上的缺陷。在過去的幾年中闹司，hadoop 開發(fā)團隊做了一些 bug 的修復(fù)娱仔，但是最近這些修復(fù)的成本越來越高，這表明對原框架做出改變的難度越來越大游桩。
為從根本上解決舊 MapReduce 框架的性能瓶頸牲迫，促進 Hadoop 框架的更長遠發(fā)展，從 0.23.0 版本開始借卧，Hadoop 的 MapReduce 框架完全重構(gòu)恩溅，發(fā)生了根本的變化。新的 Hadoop MapReduce 框架命名為 MapReduceV2谓娃，其架構(gòu)圖如下圖所示：
重構(gòu)根本的思想是將 JobTracker 兩個主要的功能分離成單獨的組件脚乡，這兩個功能是資源管理和任務(wù)調(diào)度 / 監(jiān)控。新的資源管理器（ResourceManager ）全局管理所有應(yīng)用程序計算資源的分配。
每一個應(yīng)用（原來叫做一個mapreduce作業(yè)）都會有一個ApplicationMaster 負責(zé)相應(yīng)的調(diào)度和協(xié)調(diào)
Resourcemanager:
Mapreducev1版本只有一個jobtracker奶稠，jobtracker用來跟蹤和分配諸如cpu和內(nèi)存之類的資源俯艰，并處理mapreduce相關(guān)的作業(yè)跟蹤
在YARN里jobtracker的資源管理部分由一個被稱為資源管理的后臺程序來負責(zé)（resource manager）
application master
每個應(yīng)用是一個單獨的mapreduce作業(yè)，但不同于以前所有的作業(yè)都由一個單獨的jobtracker來負責(zé)锌订，
現(xiàn)在每個作業(yè)都有一個被稱為應(yīng)用管理者的進程（application master）竹握，它運行在集群中某個工作節(jié)點上，功能相等于jobtracker辆飘。
這與一個集中式的jobtracker有很大不同啦辐，因為一個作業(yè)的應(yīng)用管理者現(xiàn)在已經(jīng)完全與其他作業(yè)分離，這意味著即使jobtracker發(fā)生了災(zāi)難性的錯誤蜈项，其他作業(yè)也不會受到影響芹关。
更進一步說，因為jobtracker已經(jīng)被完全指定到了某個作業(yè)紧卒，所以多個jobtracker能在集群上同時運行
container
容器我們可以簡單的理解為單獨為這個容器做了一個虛擬資源
ResourceManager 是基于應(yīng)用程序?qū)Y源的需求進行調(diào)度的 ; 每一個應(yīng)用程序需要不同類型的資源因此就需要不同的容器侥衬。
每一個應(yīng)用的 ApplicationMaster 的職責(zé)有：向調(diào)度器索要適當(dāng)?shù)馁Y源容器，運行任務(wù)跑芳，跟蹤應(yīng)用程序的狀態(tài)和監(jiān)控它們的進程轴总，處理任務(wù)的失敗原因。
NodeManager
NodeManager 監(jiān)控數(shù)據(jù)節(jié)點的應(yīng)用程序的資源使用情況 (CPU博个，內(nèi)存怀樟，硬盤，網(wǎng)絡(luò) ) 并且向resource manager 匯報
NodeManager 功能比較專一盆佣，就是負責(zé) Container 狀態(tài)的維護往堡，并向 RM 保持心跳。
NodeManager 并不完全等同于tasktracker罪塔，因為tasktracker需要運行任務(wù)并保持心跳，在V2版本里運行任務(wù)的功能分配給了Application Master
