Hadoop 之 MapReduce 框架演變詳解

經典版的MapReduce

所謂的經典版本的MapReduce框架，也是Hadoop初版成熟的商用框架，簡單易用是它的特色，來看一幅圖架構圖：

上面的這幅圖咱們暫且能夠稱謂Hadoop的V1.0版本，思路很清晰，各個Client提交Job給一個統一的Job Tracker，而後Job Tracker將Job拆分紅N個Task,而後進行分發到各個節點（Node）進行並行協同運行，而後再將各自的運行結果反饋至Job Tracker,進而輸出結果。

可是，這種框架有它自身的限制性和侷限，咱們來簡單的分析幾點：

一、單點故障，首先，單點故障也是最致命的一點，從上圖中能夠看到全部的Job的完成都得益於JobTracker的調度和分配，一旦此節點宕機就意味着整個平臺的癱瘓，固然，在實際中大部分經過一個JobTracker slaver來解決。可是，在一個以分佈式運算爲特性的框架中，將這種核心的計算集中與一臺機器不是一個最優的方案。

二、可擴展性，一樣，在上面的架構圖中能夠看到，Job Tracker不但承載着Client所提供的Job和分發和調度，還須要管理全部的Job的失敗、重啓，監視每一個Node的資源利用狀況，實現原理無非就是Heartbeat(心跳檢測)，隨着Node的數量的增長，Job Tracker的任務就會變得越來愈大，在疲於應付各個子節點運行檢測的同時，還要進行新的Job的分發，因此這種框架官方給出了限制節點數（<4000 節點）。

三、資料浪費，在傳統的架構中，每個Job的分配，是經過Node資源的數量進行分配的方式，顯然這種分配方式不能動態的實現負載均衡，好比，兩個大的內存消耗的task調度到了一個Node上，這也就意味着狀態機器壓力很大，而相應的某些節點就比較輕鬆，顯然在分佈式計算中這是一種很大的資源浪費。

四、版本耦合，其實這一點也是影響一個平臺作大的致命缺陷，以上的架構中，MapReduce框架有着任何的或者不重要的變動（好比BUG修復、性能提高或某些特性），都會強制進行系統級別的升級更新。並且，無論用戶是否贊成，都得強制讓分佈式系統的每個用戶端進行更新。

 

以上四點，是V1.0框架之上所帶來的侷限性，總結的來看，問題主要是集中在中間節的主線程Job tracker上面，因此解決這個線程的問題，基本也就解決了上面所提到的性能浪費和擴展性等諸多問題。

下面咱們再詳細的分析下Job Track在MapReduce中的詳細職責，解決擴張性的問題無非就是責任解耦，咱們來看一下：

一、管理集羣中的計算資源，涉及到維護活動節點列表，可用和佔用的Map和Reduce Slots列表。以及依據所選的調度策略可用的Slots分配給合適的做用和任務

二、協調集羣中運行的任務，這涉及到指導Task Tracker啓動Map和Reduce任務，監視任務的運行狀態，從新啓動執行失敗任務，推測性能運行緩慢的任務，計算做業計數器值的總和，等等。

看看，JobTrack是否是很累.....這樣的安排放在一個進程中會致使重大的伸縮性問題，尤爲是在較大的集羣上面，JobTracker必須不斷的跟蹤數千個TaskTracker、數百個做業，以及數以萬計的Map和Reduce任務，下面來個圖看看：

上圖中顯示了一臺比較忙的Job Tracker在忙碌的分配着任務.....

因此，分析到此，彷佛解決問題的方式已經呼之欲出了：減小單個JobTracker的職責！

既然減小JobTracker的職責，也就意味着須要將不屬於他的職責分配給別人去幹，通過上面的簡述，咱們基本上能夠將JobTracker的職責分爲兩大部分：集羣資源管理和任務協調。

這兩大任務之間，顯然集羣管理的任務要更重要，它意味着整個平臺的性能的健壯和平臺的擴展性，而相比較，任務協調之類的事情就能夠分配到某一個下屬的Node來幹，而且因爲每個Client所提到的Job分配過程和執行過程而言，分配過程顯得短暫而且靈活。

通俗一點的講：就是將上面架構中的JobTracker責任進行剝離，讓它就負責整個平臺的資源管理就能夠了，至於任務的分配和協調就交給屬下（Node）來幹就行了。就比如一個公司來個活，大Boss只負責整個公司的資源管理，而這個活就扔給相應的部分就能夠了。

通過上面的分析，好像基本下一個版本的架構優化方式也基本明確，咱們來接着分析Hadoop的新一版的架構。

 

新一代的架構設計YARN

來看一下官方的定義：

Apache Hadoop YARN （Yet Another Resource Negotiator，另外一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可爲上層應用提供統一的資源管理和調度，它的引入爲集羣在利用率、資源統一管理和數據共享等方面帶來了巨大好處。

通過第一部分的分析，咱們基本已經確認了將之前的JobTracker這個主線程的責任更改成整個集羣的資源管理和分配。從這一點講這裏若是這個線程的命名仍是JobTracker顯然就不合適了。

因此在新通常的架構圖中他的名字變成了ResourceManager(資源管理)，而後這個名字更適合它的職責。

咱們先來一幅圖看看

哈，長得基本和上一代的架構圖同樣，只是責任有了明顯的分離，咱們來分析一下，首先來肯定一下圖中的名詞：

一、ResourceManager(RM)全局羣集資源管理器

二、ApplicationMaster(AM)專用的JobTracker,途中能夠看出，目前已經將JobTracker的職責分離到了Node中了。

三、NodeManage（NM）管理各個子節點，代替之前的TaskTracker,不過功能基本相似，只不過添加了一個每一個節點的的自管理功能，也是對RM的責任分擔。

四、Containers,用Application來提到之前的MapReduce做業，而承載Application的容器就爲Container,目的是爲了更多應用能運行在Hadoop平臺下，爲了之後的擴充。

咱們來簡述一下，整個框架的運行流程。

在YARN構架中，一個全局的ResourceManager主要是以一個後臺進程的形式運行。它通常分配在一個獨有的機器上，在各類競爭的應用程序之間獨裁可用的集羣資源。ResourceManageer會追蹤集羣中有多少可用的活動節點和資源，協調用戶提交的那些應用程序在什麼時候獲取這些資源。

ResourceManager是惟一擁有此信息的進程，因此它可經過某種共享的，安全的，多租戶的方式制定分配（或者調度）決策（例如，依據應用程序的優先級，隊列容量，ACLs,數據位置等）

在用戶提交一個應用程序時，一個稱爲ApplicationMaster的輕量級進程實例會啓動協調應用程序內的全部任務的執行。包括監視任務，從新啓動失敗的任務，推測的運行緩慢的任務，以及計算應用程序計數值的總和。這些職責之前就是JobTracker.如今已經獨立出來，而且運行在NodeManager控制的資源容器中運行。

NodeManager是TaskTracker的一種更加普通和高效的版本，NodeManager擁有許多動態建立的資源容器，容器的大小取決於所包含的資源量，好比：內存、CPU、磁盤和網絡IO.可是目前僅支持內存和CPU(YARN-3).其實這裏平臺提供的一個接口，方便後續的擴展，將來可以使用cgroups來控制磁盤和網絡IO.

其實，簡單點講，NodeManager是一個高度自治的內在節點，包括節點內的JobTracker.

咱們再來看另一幅圖，來詳細的看一下，YARN內新的Job內在流程在各個節點（Node）中的流轉：

從這幅圖中能夠看到，和以前的初版的架構圖相比，是多了後面節點之間的交互，由於，在新的結構圖中咱們將JobTracker的職責下放到NodeManager中的ApplicationMaster中了，也就是會在ApplicationMaster中進行傳統的Map-Redurce的分發，因此會形成各個不一樣的Noder之間發生交互。

固然，這全部的過程都會他們的老大ResourceManager進行調度和管理。

以上的架構，在Hadoop版本中稱之爲MRv2.

咱們來總結一下，這個架構所解決的問題：

一、更高的集羣利用率，一個框架未使用的資源可由另外一個框架進行使用，充分的避免資源浪費

二、很高的擴展性，採用了這種責任下方的架構思路，已經解決了初版4000node的限制，到目前能夠充分的擴展資源。

三、在新的Yarn中，經過加入ApplicationMaster是一個可變動的部分，用戶能夠針對不一樣的編程模型編寫本身的AppMst,讓更多的編程模型運行在Hadoop集羣中。

四、在上一版框架中，JobTracker一個很大的負擔就是監控Job的tasks運行狀況，如今，這個部分下放到了ApplicationMaster中。

除了上面幾點以外，咱們特別來分析如下，在新版框架中的ResouceManager的功能亮點。

上個圖看看：

當一個Client提交應用程序的時候，首先進去的就是ResourceManager，它維護着集羣上運行的應用程序列表，以及每一個活動的NodeManager上的可用資源列表。ResourceManager首先要肯定就是那個應用程序能夠運行此Job,會存放到相應的Container中去，固然這裏會分配一部分的集羣資源，這一部分資源的選擇會受到許多的限制，好比：隊列容量，ACL和公平性。下一步就是另一個可插拔的組件Scheduler來下發任務（這裏不是分發！），Scheduler近執行調度，不會對應用程序內的執行過程有任何監視，Scheduler就比如祕書同樣，將大Boss(RM)分配的任務傳遞到相應的部門。

而後，就是部門的領導（ApplicationMaster）來分配任務給員工（DataNode）了，而這個分發的過程就是Map-Redure，因此在這個過程當中，ApplicationMaster負責此應用程序的整個週期，固然在運行過程當中，它能夠跟老大（RM）進行一些相應的資源需求，好比：

一、必定量的硬件資源，好比內存量和CPU份額。

二、一個首選的位置，好比某臺Node，一般須要制定主機名、機架名等。

三、Task分配後的優先級。

而後，找到相應的資源以後，就開始甩開膀子進行任務的完成，而這些跑批則發生在（Node）中,可是Node中也有它本身的小隊長（NodeManager）,它負責監視本身node種的資源使用狀況，好比，本身的任務比當初分配的少，提早完成了，它會結束該容器，釋放資源。

而在上面的過程當中，ApplicationMaster會不遺餘力協調容器，自動所須要的任務來完成它的應用程序，他會監視應用程序的進度，從新啓動失敗的任務，以及向Client提交應用程序的報告進度。應用程序完成後，ApplicationMaster會關閉本身並釋放本身的容器。

固然，這個過程之中，若是ApplicationMaster本身掛掉了，這時候ResouceManager會從新從新找一個領導（新的容器中啓動它），直至整個程序完成。

結束語

Hadoop是一個很是牛掰的分佈式架構平臺，它的優越性我想不須要我跟你們分享，不少成功的案例都已經在暗示着咱們，將來所謂的大數據，所謂的互聯網+，所謂的雲....都會找到它的立腳點。

 

參考資源

百度百科：yarn

Apache Hadoop 0.23 中的 MRv2，這是對一個 JARN 集羣的重要技術細節的不錯介紹。

Hadoop官網 Apache Hadoop 項目站點。