在前面寫到的三篇博客中，HDFS概述 和 MapReduce簡介寫的都是hadoop1.0的情況，針對1.0版本的各種不足，2.0都有相應的改動， HDFS再學習：HA和Federation機制寫的是存儲系統HDFS上的改動。針對我們的計算模型MapReduce，2.0版本設計了新的資源管理框架YARN。
| 組件 | Hadoop1.0的問題 | Hadoop2.0的改進 |
|---|---|---|
| HDFS | 單一節點問題 | Hdfs HA提供熱備機制 |
| HDFS | 單一命名空間 | Hdfs Federation管理多命名空間 |
| MapReduce | 資源管理效率低 | 新的資源管理框架YARN |
MapReduce1.0的缺陷
回顧一下MapReduce1.0的結構,，詳細的可以去看上一篇博客：
存在問題：
1、JobTracker“大包大攬”，導致任務過重且單結點限制了規模。
2、容易出現內存溢出問題。因爲分配資源時考慮的是MapReduce的任務數，不考慮CPU，內存等問題。
3、資源劃分不合理。如上一篇博客裏面介紹道，MR1.0裏面的資源單位爲槽slot，強制分爲MapSlot和ReduceSlot，即使沒有map任務，但是reduce任務槽數不夠用，reduce任務也沒法使用map任務的槽。
YARN的設計思路
YARN是一個分佈式資源管理系統，用於提高分佈式的集羣環境下資源的利用率，這些資源包括內存，I/O，網絡，磁盤等。其產生的原因是爲了解決MapReduce框架的不足。
我們從MapReduce1.0的結構圖可以看到，1.0版本既是一個計算框架，也是一個資源調度框架。資源調度方面的jobTracker不僅負責了資源的管理還負責任務的調度和任務的監控。2.0版本把資源調度的任務分離出來，形成了YARN，也就是說，YARN是一個純粹的資源管理調度框架，而2.0版本的mapReduce就只是一個純粹的計算框架了，不再自己負責資源管理服務。
2.0版本中把jobTracker的資源管理交給了全局的資源管理器ResourceManager，任務方面的調度和監控交給了應用相關的ApplicationMaster，用節點NodeManage來替代TaskTracker。
ResourceManager
RM是一個全局的資源管理器，負責整個系統的資源管理與分配，主要包括兩個組件：調度器Scheduler和應用程序管理器Applications Manager。
調度器接收來自ApplicationMaster的應用程序資源請求，把集羣中的資源以“容器”的形式分配給提出申請的應用程序，容器的選擇通常考慮應用程序所要處理的數據的位置，就近選擇，實現“計算向數據靠攏”。
Container容器
動態資源分配的單位，每個容器中都封裝一定數量的CPU、內存、磁盤等資源，從而限制每個應用程序可以使用的資源量。
scheduler調度器
是一個可插拔的組件，YARN不僅自身提供了很多可以直接用的調度器，也允許用戶自定義。
Applications Manager應用程序管理器
負責系統中所有應用程序的管理工作，主要包括應用程序提交，與調度器協商資源以啓動、監控、重啓ApplicationMaster。
ApplicationMaster
ResourceManager接收用戶提交的作業（記住，hadoop中處理的用戶程序都是以作業的形式來處理的，只是我們計算的時候把作業變成了一個個的map/reduce任務），按照作業的上下文信息及從NodeManager收集來的容器狀態信息，啓動調度過程，在NodeManager中啓動一個容器爲ApplicationMaster（applicationMaster的運行也佔用資源，它是由resourceManager在nodeManager中啓動的一個container)。
其作用是：
爲應用程序申請資源，並分配給內部任務。
負責這個任務的調度、監控與容錯（任務失敗時重申資源，重啓任務）。
NodeManager
單個節點上的資源管理，每個節點上就有一個。
監控節點上容器的資源使用情況。
跟蹤節點健康狀況。
以“心跳”方式與ResourceManager保持通信。
接收來自ResourceManager和ApplicationMaster的各種請求。
YARN的工作流程
1、用戶提交程序，包括ApplicationMaster程序，啓動AM的命令和用戶程序。
2、YARN中的ResourceManager負責接收和處理來自客戶端的程序，選擇NodeManager中的一個容器，啓動ApplicationMaster。
3、ApplicationMaster創建後會先向 ResourceManager註冊。
4、ApplicationMaster輪詢向ResourceManager申請資源。
5、ResourceManager以容器的方式向提出申請的AM分配資源。
6、在容器中啓動任務。
7、各個任務向Am報告狀態與進度。
8、應用程序結束後，AM向RM註銷並關閉自己。
YARN體系結構
集羣部署上，YARN的各個組件是與Hadoop集羣中的其他組件統一部署的。
ResourceManager和NameNode一起，是主節點。
ApplicationMaster可以和數據節點一起，由NodeManager管理。
container和數據節點一起，（方便計算），由NodeManager管理。
從MapReduce1.0框架發展到YARN框架，客戶端並沒有發生變化，其大部分調用API及接口都保持兼容，因此，原來針對Hadoop1.0開發的代碼不用做大的改動，就可以直接放到Hadoop2.0平臺上運行
Yarn與MapReduce1.0框架的對比分析
總體而言，YARN相對於MapReduce1.0來說具有以下優勢
1、大大減少了承擔中心服務功能的ResourceManager的資源消耗
ApplicationMaster來完成需要大量資源消耗的任務調度和監控
多個作業對應多個ApplicationMaster，實現了監控分佈化
2、MapReduce1.0既是一個計算框架，又是一個資源管理調度框架，但是，只能支持MapReduce編程模型。而YARN則是一個純粹的資源調度管理框架，在它上面可以運行包括MapReduce在內的不同類型的計算框架，比如storm實現流計算，spark實現內存計算等等，只要編程實現相應的ApplicationMaster
3、YARN中的資源管理比MapReduce1.0更加高效
以容器爲單位，而不是以slot爲單位
YARN的目標是實現“一個集羣多個框架”，即在一個集羣上部署一個統一的資源調度框架YARN，在此上可以部署其它各種計算框架。由YARN爲這些計算框架提供統一的資源調度管理服務，並且能根據各種計算框架的負載需求，調整各自佔用的資源，實現集羣資源共享與資源彈性收縮。
這樣，不同的計算框架可以共享底層的存儲，避免了數據集跨集羣的移動。