經典版的MapReduce
所謂的經典版本的MapReduce框架，也是Hadoop第一版成熟的商用框架，簡單易用是它的特點，來看一幅圖架構圖：
上面的這幅圖我們暫且可以稱謂Hadoop的V1.0版本，思路很清晰，各個Client提交Job給一個統一的Job Tracker，然后Job Tracker將Job拆分成N個Task,然后進行分發到各個節點（Node）進行并行協同運行，然后再將各自的運行結果反饋至Job Tracker,進而輸出結果。
但是，這種框架有它自身的限制性和局限，我們來簡單的分析幾點：
1、單點故障，首先，單點故障也是最致命的一點，從上圖中可以看到所有的Job的完成都得益于JobTracker的調度和分配，一旦此節點宕機就意味著整個平臺的癱瘓，當然，在實際中大部分通過一個JobTracker slaver來解決。但是，在一個以分布式運算為特性的框架中，將這種核心的計算集中與一臺機器不是一個最優的方案。
2、可擴展性，同樣，在上面的架構圖中可以看到，Job Tracker不但承載著Client所提供的Job和分發和調度，還需要管理所有的Job的失敗、重啟，監視每個Node的資源利用情況，實現原理無非就是Heartbeat(心跳檢測)，隨著Node的數量的增加，Job Tracker的任務就會變得越來愈大，在疲于應付各個子節點運行檢測的同時，還要進行新的Job的分發，所以這種框架官方給出了限制節點數（<4000 節點）。
3、資料浪費，在傳統的架構中，每一個Job的分配，是通過Node資源的數量進行分配的方式，顯然這種分配方式不能動態的實現負載均衡，比如，兩個大的內存消耗的task調度到了一個Node上，這也就意味著狀態機器壓力很大，而相應的某些節點就比較輕松，顯然在分布式計算中這是一種很大的資源浪費。
4、版本耦合，其實這一點也是影響一個平臺做大的致命缺陷，以上的架構中，MapReduce框架有著任何的或者不重要的變更（比如BUG修復、性能提升或某些特性），都會強制進行系統級別的升級更新。而且，不管用戶是否同意，都得強制讓分布式系統的每一個用戶端進行更新。
以上四點，是V1.0框架之上所帶來的局限性，總結的來看，問題主要是集中在中間節的主線程Job tracker上面，所以解決這個線程的問題，基本也就解決了上面所提到的性能浪費和擴展性等諸多問題。
下面我們再詳細的分析下Job Track在MapReduce中的詳細職責，解決擴張性的問題無非就是責任解耦，我們來看一下：
1、管理集群中的計算資源，涉及到維護活動節點列表，可用和占用的Map和Reduce Slots列表。以及依據所選的調度策略可用的Slots分配給合適的作用和任務
2、協調集群中運行的任務，這涉及到指導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(資源管理)，然后這個名字更適合它的職責。
我們先來一幅圖看看
哈，長得基本和上一代的架構圖一樣，只是責任有了明顯的分離，我們來分析一下，首先來確定一下圖中的名詞：
1、ResourceManager(RM)全局群集資源管理器
2、ApplicationMaster(AM)專用的JobTracker,途中可以看出，目前已經將JobTracker的職責分離到了Node中了。
3、NodeManage（NM）管理各個子節點，代替以前的TaskTracker,不過功能基本類似，只不過添加了一個每個節點的的自管理功能，也是對RM的責任分擔。
4、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.
我們來總結一下，這個架構所解決的問題：
1、更高的集群利用率，一個框架未使用的資源可由另一個框架進行使用，充分的避免資源浪費
2、很高的擴展性，采用了這種責任下方的架構思路，已經解決了第一版4000node的限制，到目前可以充分的擴展資源。
3、在新的Yarn中，通過加入ApplicationMaster是一個可變更的部分，用戶可以針對不同的編程模型編寫自己的AppMst,讓更多的編程模型運行在Hadoop集群中。
4、在上一版框架中，JobTracker一個很大的負擔就是監控Job的tasks運行情況，現在，這個部分下放到了ApplicationMaster中。
除了上面幾點之外，我們特別來分析以下，在新版框架中的ResouceManager的功能亮點。
上個圖看看：
當一個Client提交應用程序的時候，首先進去的就是ResourceManager，它維護著集群上運行的應用程序列表，以及每個活動的NodeManager上的可用資源列表。ResourceManager首先要確定就是那個應用程序可以運行此Job,會存放到相應的Container中去，當然這里會分配一部分的集群資源，這一部分資源的選擇會受到許多的限制，比如：隊列容量，ACL和公平性。下一步就是另外一個可插拔的組件Scheduler來下發任務（這里不是分發！），Scheduler近執行調度，不會對應用程序內的執行過程有任何監視，Scheduler就好比秘書一樣，將大Boss(RM)分配的任務傳遞到相應的部門。
然后，就是部門的領導（ApplicationMaster）來分配任務給員工（DataNode）了，而這個分發的過程就是Map-Redure，所以在這個過程中，ApplicationMaster負責此應用程序的整個周期，當然在運行過程中，它可以跟老大（RM）進行一些相應的資源需求，比如：
1、一定量的硬件資源，比如內存量和CPU份額。
2、一個首選的位置，比如某臺Node，通常需要制定主機名、機架名等。
3、Task分配后的優先級。
然后，找到相應的資源之后，就開始甩開膀子進行任務的完成，而這些跑批則發生在（Node）中,但是Node中也有它自己的小隊長（NodeManager）,它負責監視自己node種的資源使用情況，比如，自己的任務比當初分配的少，提前完成了，它會結束該容器，釋放資源。
而在上面的過程中，ApplicationMaster會竭盡全力協調容器，自動所需要的任務來完成它的應用程序，他會監視應用程序的進度，重新啟動失敗的任務，以及向Client提交應用程序的報告進度。應用程序完成后，ApplicationMaster會關閉自己并釋放自己的容器。
當然，這個過程之中，如果ApplicationMaster自己掛掉了，這時候ResouceManager會重新重新找一個領導（新的容器中啟動它），直至整個程序完成。
結束語
Hadoop是一個非常牛掰的分布式架構平臺，它的優越性我想不需要我跟大家分享，很多成功的案例都已經在暗示著我們，未來所謂的大數據，所謂的互聯網+，所謂的云....都會找到它的立腳點。
參考資源
百度百科：yarn
Apache Hadoop 0.23 中的 MRv2，這是對一個 JARN 集群的重要技術細節的不錯介紹。
Hadoop官網 Apache Hadoop 項目站點。
文章列表
留言列表
