第一次接觸Hadoop的時候，啟動hadoop出現的節點是：
NameNode
SecondaryNameNode
JobTracker
TaskTracker
DataNode
NameNode
如今啟動hadoop出現的節點是：
SecondaryNameNode
NodeManager
ResourceManager
NameNode
DataNode
發現現在的Hadoop中，JobTracker和TaskTracker消失了，多了NodeManager和ResourceManager
后來一查，發現原來Hadoop的框架已經發生了變化。
下面着重介紹下新的hadoop的框架，Yarn。
Hadoop是開源分布式文件存儲及處理框架，
首先先整理下原MapReduce的流程以及設計思路：
1.首先用戶程序（JobClient）提交了一個job，job的信息會發送到JobTracker中，JobTracker是MapReduce框架的中心，
需要與集群中的機器定時通信（heartbeat），需要管理哪些程序應該跑在哪些機器上，需要管理所有job失敗、重啟等操作。
2.TaskTracker是MapReduce集群中每台機器都有的一個部分，他做的事情主要是監視自己所在機器的資源情況
3.TaskTracker同時監視當前機器的tasks運行狀況。TaskTracker需要把這些信息通過heartbeat發送給JobTracker，
JobTracker會搜集這些信息以給新提交的job分配運行在哪些機器上。
下面幾張圖便於理解：
MapReduce運行：
首先是客戶端要編寫好mapreduce程序，配置好mapreduce的作業也就是job，
接下來就是提交job了，提交job是提交到JobTracker上的，這個時候JobTracker就會構建這個job，具體就是分配一個新的job任務的ID值，
接下來它會做檢查操作，這個檢查就是確定輸出目錄是否存在，如果存在那么job就不能正常運行下去，JobTracker會拋出錯誤給客戶端，
接下來還要檢查輸入目錄是否存在，如果不存在同樣拋出錯誤，如果存在JobTracker會根據輸入計算輸入分片（Input Split），如果分片計算不出來也會拋出錯誤，這些都做好了JobTracker就會配置Job需要的資源了。
分配好資源后，JobTracker就會初始化作業，初始化主要做的是將Job放入一個內部的隊列，讓配置好的作業調度器能調度到這個作業，作業調度器會初始化這個job，初始化就是創建一個正在運行的job對象（封裝任務和記錄信息），以便JobTracker跟蹤job的狀態和進程。
初始化完畢后，作業調度器會獲取輸入分片信息（input split），每個分片創建一個map任務。接下來就是任務分配了，這個時候tasktracker會運行一個簡單的循環機制定期發送心跳給jobtracker，心跳間隔是5秒，程序員可以配置這個時間，心跳就是jobtracker和tasktracker溝通的橋梁，
通過心跳，jobtracker可以監控tasktracker是否存活，也可以獲取tasktracker處理的狀態和問題，同時tasktracker也可以通過心跳里的返回值獲取jobtracker給它的操作指令。任務分配好后就是執行任務了。在任務執行時候jobtracker可以通過心跳機制監控tasktracker的狀態和進度，同時也能計算出整個job的狀態和進度，而tasktracker也可以本地監控自己的狀態和進度。
當jobtracker獲得了最后一個完成指定任務的tasktracker操作成功的通知時候，jobtracker會把整個job狀態置為成功，然后當客戶端查詢job運行狀態時候（注意：這個是異步操作），客戶端會查到job完成的通知的。如果job中途失敗，mapreduce也會有相應機制處理，一般而言如果不是程序員程序本身有bug，mapreduce錯誤處理機制都能保證提交的job能正常完成。
但是隨着分布式系統集群的規模和工作負荷的增長，原框架出現許多問題，主要表現形式如下：
1.JobTracker是MapReduce的集中處理點，存在單點故障。
2.JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的內存開銷，
潛在來說，也增加了 JobTracker fail 的風險，這也是業界普遍總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限。
3.在 TaskTracker 端，以 map/reduce task 的數目作為資源的表示過於簡單，沒有考慮到 cpu/ 內存的占用情況，
如果兩個大內存消耗的 task 被調度到了一塊，很容易出現 OOM。
4.在 TaskTracker 端，把資源強制划分為 map task slot 和 reduce task slot, 如果當系統中只有 map task 或者只有 reduce task 的時候，會造成資源的浪費，也就是前面提過的集群資源利用的問題。
5.源代碼層面分析的時候，會發現代碼非常的難讀，常常因為一個 class 做了太多的事情，代碼量達 3000 多行，，造成 class 的任務不清晰，增加 bug 修復和版本維護的難度。
6.從操作的角度來看，現在的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提升和特性化 ) 時，都會強制進行系統級別的升級更新。更糟的是，它不管用戶的喜好，強制讓分布式集群系統的每一個用戶端同時更新。這些更新會讓用戶為了驗證他們之前的應用程序是不是適用新的 Hadoop 版本而浪費大量時間。
新的框架----YARN
重構根本的思想是將 JobTracker 兩個主要的功能分離成單獨的組件，
這兩個功能是資源管理和任務調度 / 監控。
新的資源管理器全局管理所有應用程序計算資源的分配，每一個應用的 ApplicationMaster 負責相應的調度和協調。
一個應用程序無非是一個單獨的傳統的 MapReduce 任務或者是一個 DAG( 有向無環圖 ) 任務。
ResourceManager 和每一台機器的節點管理服務器能夠管理用戶在那台機器上的進程並能對計算進行組織。
事實上，每一個應用的 ApplicationMaster 是一個詳細的框架庫，它結合從 ResourceManager 獲得的資源和 NodeManager 協同工作來運行和監控任務。
上圖中 ResourceManager 支持分層級的應用隊列，這些隊列享有集群一定比例的資源。從某種意義上講它就是一個純粹的調度器，它在執行過程中不對應用進行監控和狀態跟蹤。同樣，它也不能重啟因應用失敗或者硬件錯誤而運行失敗的任務。
ResourceManager 是基於應用程序對資源的需求進行調度的 ; 每一個應用程序需要不同類型的資源因此就需要不同的容器。資源包括：內存，CPU，磁盤，網絡等等。可以看出，這同現 Mapreduce 固定類型的資源使用模型有顯著區別，它給集群的使用帶來負面的影響。資源管理器提供一個調度策略的插件，它負責將集群資源分配給多個隊列和應用程序。調度插件可以基於現有的能力調度和公平調度模型。
上圖中 NodeManager 是每一台機器框架的代理，是執行應用程序的容器，監控應用程序的資源使用情況 (CPU，內存，硬盤，網絡 ) 並且向調度器匯報。
每一個應用的 ApplicationMaster 的職責有：向調度器索要適當的資源容器，運行任務，跟蹤應用程序的狀態和監控它們的進程，處理任務的失敗原因。
新舊Hadoop MapReduce框架對比
讓我們來對新舊 MapReduce 框架做詳細的分析和對比，可以看到有以下幾點顯著變化：
首先客戶端不變，其調用 API 及接口大部分保持兼容，這也是為了對開發使用者透明化，使其不必對原有代碼做大的改變 ( 詳見 2.3 Demo 代碼開發及詳解)，但是原框架中核心的 JobTracker 和 TaskTracker 不見了，取而代之的是 ResourceManager, ApplicationMaster 與 NodeManager 三個部分。
我們來詳細解釋這三個部分，
首先 ResourceManager 是一個中心的服務，它做的事情是調度、啟動每一個 Job 所屬的 ApplicationMaster、另外監控 ApplicationMaster 的存在情況。細心的讀者會發現：Job 里面所在的 task 的監控、重啟等等內容不見了。這就是 AppMst 存在的原因。
ResourceManager 負責作業與資源的調度。接收 JobSubmitter 提交的作業，按照作業的上下文 (Context) 信息，以及從 NodeManager 收集來的狀態信息，啟動調度過程，分配一個 Container 作為 App Mstr
NodeManager 功能比較專一，就是負責 Container 狀態的維護，並向 RM 保持心跳。
ApplicationMaster 負責一個 Job 生命周期內的所有工作，類似老的框架中 JobTracker。但注意每一個 Job（不是每一種）都有一個 ApplicationMaster，它可以運行在 ResourceManager 以外的機器上。
Yarn 框架相對於老的 MapReduce 框架什么優勢呢？我們可以看到：
1.這個設計大大減小了 JobTracker（也就是現在的 ResourceManager）的資源消耗，並且讓監測每一個 Job 子任務 (tasks) 狀態的程序分布式化了，更安全、更優美。
2.在新的 Yarn 中，ApplicationMaster 是一個可變更的部分，用戶可以對不同的編程模型寫自己的 AppMst，讓更多類型的編程模型能夠跑在 Hadoop 集群中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
3.對於資源的表示以內存為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的占用 )，比之前以剩余 slot 數目更合理。
4.老的框架中，JobTracker 一個很大的負擔就是監控 job 下的 tasks 的運行狀況，現在，這個部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個模塊叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是監測 ApplicationMaster 的運行狀況，如果出問題，會將其在其他機器上重啟。
5.Container 是 Yarn 為了將來作資源隔離而提出的一個框架。這一點應該借鑒了 Mesos 的工作，目前是一個框架，僅僅提供 java 虛擬機內存的隔離 ,hadoop 團隊的設計思路應該后續能支持更多的資源調度和控制 , 既然資源表示成內存量，那就沒有了之前的 map slot/reduce slot 分開造成集群資源閑置的尷尬情況。
經過簡單的分析理解之后，對新一代的hadoop有了一個新的認識。