一、Hadoop2.0產(chǎn)生的背景
——Hadoop 1.0中HDFS和MapReduce在高可用、擴展性等方面存在問題
——HDFS存在的問題
·NameNode單點故障，難以應用于在線場景 HA
·NameNode壓力過大，且內(nèi)存受限，影擴展性 F
——MapReduce存在的問題響系統(tǒng)
·JobTracker訪問壓力大，影響系統(tǒng)擴展性
·難以支持除MapReduce之外的計算框架，比如Spark、Storm等
二、Hadoop 1.x與Hadoop 2.x
——Hadoop 2.x由HDFS、MapReduce和YARN三個分支構(gòu)成；
·HDFS：NN Federation（聯(lián)邦）、HA；
---2.X:只支持2個節(jié)點HA，3.0實現(xiàn)了一主多備
·MapReduce：運行在YARN上的MR；
---離線計算，基于磁盤I/O計算
·YARN：資源管理系統(tǒng)
Hadoop1.0
從上圖中可以清楚的看出原 MapReduce 程序的流程及設計思路：
首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發(fā)送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要與集群中的機器定時通信 (heartbeat), 需要管理哪些程序應該跑在哪些機器上，需要管理所有 job 失敗、重啟等操作。
TaskTracker 是 Map-reduce 集群中每臺機器都有的一個部分，他做的事情主要是監(jiān)視自己所在機器的資源情況。
TaskTracker 同時監(jiān)視當前機器的 tasks 運行狀況。TaskTracker 需要把這些信息通過 heartbeat 發(fā)送給 JobTracker，JobTracker 會搜集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發(fā)送 - 接收的過程。
可以看得出原來的 map-reduce 架構(gòu)是簡單明了的，在最初推出的幾年，也得到了眾多的成功案例，獲得業(yè)界廣泛的支持和肯定，但隨著分布式系統(tǒng)集群的規(guī)模和其工作負荷的增長，原框架的問題逐漸浮出水面，主要的問題集中如下：
JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的內(nèi)存開銷，潛在來說，也增加了 JobTracker fail 的風險，這也是業(yè)界普遍總結(jié)出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點主機的上限。
在 TaskTracker 端，以 map/reduce task 的數(shù)目作為資源的表示過于簡單，沒有考慮到 cpu/ 內(nèi)存的占用情況，如果兩個大內(nèi)存消耗的 task 被調(diào)度到了一塊，很容易出現(xiàn) OOM。
在 TaskTracker 端，把資源強制劃分為 map task slot 和 reduce task slot, 如果當系統(tǒng)中只有 map task 或者只有 reduce task 的時候，會造成資源的浪費，也就是前面提過的集群資源利用的問題。
源代碼層面分析的時候，會發(fā)現(xiàn)代碼非常的難讀，常常因為一個 class 做了太多的事情，代碼量達 3000 多行，，造成 class 的任務不清晰，增加 bug 修復和版本維護的難度。
從操作的角度來看，現(xiàn)在的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提升和特性化 ) 時，都會強制進行系統(tǒng)級別的升級更新。更糟的是，它不管用戶的喜好，強制讓分布式集群系統(tǒng)的每一個用戶端同時更新。這些更新會讓用戶為了驗證他們之前的應用程序是不是適用新的 Hadoop 版本而浪費大量時間。
Hadoop2.0
從業(yè)界使用分布式系統(tǒng)的變化趨勢和 hadoop 框架的長遠發(fā)展來看，MapReduce JobTracker/TaskTracker 機制需要大規(guī)模的調(diào)整來修復它在可擴展性，內(nèi)存消耗，線程模型，可靠性和性能上的缺陷。在過去的幾年中，hadoop 開發(fā)團隊做了一些 bug 的修復，但是最近這些修復的成本越來越高，這表明對原框架做出改變的難度越來越大。
為從根本上解決舊 MapReduce 框架的性能瓶頸，促進 Hadoop 框架的更長遠發(fā)展，從 0.23.0 版本開始，Hadoop 的 MapReduce 框架完全重構(gòu)，發(fā)生了根本的變化。新的 Hadoop MapReduce 框架命名為 MapReduceV2 或者叫 Yarn，重構(gòu)根本的思想是將 JobTracker 兩個主要的功能分離成單獨的組件，這兩個功能是資源管理和任務調(diào)度 / 監(jiān)控。新的資源管理器全局管理所有應用程序計算資源的分配，每一個應用的 ApplicationMaster 負責相應的調(diào)度和協(xié)調(diào)。一個應用程序無非是一個單獨的傳統(tǒng)的 MapReduce 任務或者是一個 DAG( 有向無環(huán)圖 ) 任務。ResourceManager 和每一臺機器的節(jié)點管理服務器能夠管理用戶在那臺機器上的進程并能對計算進行組織。
事實上，每一個應用的 ApplicationMaster 是一個詳細的框架庫，它結(jié)合ResourceManager 獲得的資源和 NodeManager 協(xié)同工作來運行和監(jiān)控任務。
上圖中 ResourceManager 支持分層級的應用隊列，這些隊列享有集群一定比例的資源。從某種意義上講它就是一個純粹的調(diào)度器，它在執(zhí)行過程中不對應用進行監(jiān)控和狀態(tài)跟蹤。同樣，它也不能重啟因應用失敗或者硬件錯誤而運行失敗的任務。
ResourceManager 是基于應用程序?qū)Y源的需求進行調(diào)度的 ; 每一個應用程序需要不同類型的資源因此就需要不同的容器。資源包括：內(nèi)存，CPU，磁盤，網(wǎng)絡等等。可以看出，這同現(xiàn) Mapreduce 固定類型的資源使用模型有顯著區(qū)別，它給集群的使用帶來負面的影響。資源管理器提供一個調(diào)度策略的插件，它負責將集群資源分配給多個隊列和應用程序。調(diào)度插件可以基于現(xiàn)有的能力調(diào)度和公平調(diào)度模型。
上圖中 NodeManager 是每一臺機器框架的代理，是執(zhí)行應用程序的容器，監(jiān)控應用程序的資源使用情況 (CPU，內(nèi)存，硬盤，網(wǎng)絡 ) 并且向調(diào)度器匯報。
每一個應用的 ApplicationMaster 的職責有：向調(diào)度器索要適當?shù)馁Y源容器，運行任務，跟蹤應用程序的狀態(tài)和監(jiān)控它們的進程，處理任務的失敗原因。
