hadoop1存在的問題及hadoop2的優點對比

對 hadoop1 和 hadoop  2  作了一個解釋 圖片不錯 拿來看看

 

Hadoop 1.0

 

從上圖中能夠清楚的看出原 MapReduce 程序的流程及設計思路：

• 首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他須要與集羣中的機器定時通訊 (heartbeat), 須要管理哪些程序應該跑在哪些機器上，須要管理全部 job 失敗、重啓等操做。
• TaskTracker 是 Map-reduce 集羣中每臺機器都有的一個部分，他作的事情主要是監視本身所在機器的資源狀況。
• TaskTracker 同時監視當前機器的 tasks 運行情況。TaskTracker 須要把這些信息經過 heartbeat 發送給 JobTracker，JobTracker 會蒐集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發送 - 接收的過程。
  

能夠看得出原來的 map-reduce 架構是簡單明瞭的，在最初推出的幾年，也獲得了衆多的成功案例，得到業界普遍的支持和確定，但隨着分佈式系統集羣的規模和其工做負荷的增加，原框架的問題逐漸浮出水面，主要的問題集中以下：

• JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
• JobTracker 完成了太多的任務，形成了過多的資源消耗，當 map-reduce job 很是多的時候，會形成很大的內存開銷，潛在來講，也增長了 JobTracker fail 的風險，這也是業界廣泛總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限。
• 在 TaskTracker 端，以 map/reduce task 的數目做爲資源的表示過於簡單，沒有考慮到 cpu/ 內存的佔用狀況，若是兩個大內存消耗的 task 被調度到了一塊，很容易出現 OOM。
• 在 TaskTracker 端，把資源強制劃分爲 map task slot 和 reduce task slot, 若是當系統中只有 map task 或者只有 reduce task 的時候，會形成資源的浪費，也就是前面提過的集羣資源利用的問題。
• 源代碼層面分析的時候，會發現代碼很是的難讀，經常由於一個 class 作了太多的事情，代碼量達 3000 多行，，形成 class 的任務不清晰，增長 bug 修復和版本維護的難度。
• 從操做的角度來看，如今的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提高和特性化 ) 時，都會強制進行系統級別的升級更新。更糟的是，它無論用戶的喜愛，強制讓分佈式集羣系統的每個用戶端同時更新。這些更新會讓用戶爲了驗證他們以前的應用程序是否是適用新的 Hadoop 版本而浪費大量時間。
  

hadoop2.0：

 
從業界使用分佈式系統的變化趨勢和 hadoop 框架的長遠發展來看，MapReduce 的 JobTracker/TaskTracker 機制須要大規模的調整來修復它在可擴展性，內存消耗，線程模型，可靠性和性能上的缺陷。在過去的幾年中，hadoop 開發團隊作了一些 bug 的修復，可是最近這些修復的成本愈來愈高，這代表對原框架作出改變的難度愈來愈大。

爲從根本上解決舊 MapReduce 框架的性能瓶頸，促進 Hadoop 框架的更長遠發展，從 0.23.0 版本開始，Hadoop 的 MapReduce 框架徹底重構，發生了根本的變化。新的 Hadoop MapReduce 框架命名爲 MapReduceV2 或者叫 Yarn，

重構根本的思想是將 JobTracker 兩個主要的功能分離成單獨的組件，這兩個功能是資源管理和任務調度 / 監控。新的資源管理器全局管理全部應用程序計算資源的分配，每個應用的 ApplicationMaster 負責相應的調度和協調。一個應用程序無非是一個單獨的傳統的 MapReduce 任務或者是一個 DAG( 有向無環圖 ) 任務。ResourceManager 和每一臺機器的節點管理服務器可以管理用戶在那臺機器上的進程並能對計算進行組織。

事實上，每個應用的 ApplicationMaster 是一個詳細的框架庫，它結合從 ResourceManager 得到的資源和 NodeManager 協同工做來運行和監控任務。

上圖中 ResourceManager 支持分層級的應用隊列，這些隊列享有集羣必定比例的資源。從某種意義上講它就是一個純粹的調度器，它在執行過程當中不對應用進行監控和狀態跟蹤。一樣，它也不能重啓因應用失敗或者硬件錯誤而運行失敗的任務。

ResourceManager 是基於應用程序對資源的需求進行調度的 ; 每個應用程序須要不一樣類型的資源所以就須要不一樣的容器。資源包括：內存，CPU，磁盤，網絡等等。能夠看出，這同現 Mapreduce 固定類型的資源使用模型有顯著區別，它給集羣的使用帶來負面的影響。資源管理器提供一個調度策略的插件，它負責將集羣資源分配給多個隊列和應用程序。調度插件能夠基於現有的能力調度和公平調度模型。

上圖中 NodeManager 是每一臺機器框架的代理，是執行應用程序的容器，監控應用程序的資源使用狀況 (CPU，內存，硬盤，網絡 ) 而且向調度器彙報。

每個應用的 ApplicationMaster 的職責有：向調度器索要適當的資源容器，運行任務，跟蹤應用程序的狀態和監控它們的進程，處理任務的失敗緣由。