Hadoop學習（二）——MapReduce\Yarn架構

其餘更多java基礎文章：
java基礎學習(目錄)

---

學習資料
理解Hadoop YARN架構

本文先講MapReduce 1.x的框架。再講MapReduce 1.x升級改進後MapReduce 2.x/Yarn的框架。目前主要是用MapReduce 2.x/Yarn的框架。

MapReduce 1.x

MapReduce 1.x重點概念

JobClient

用戶編寫的MapReduce程序經過Client提交到JobTracker端；同時，用戶可經過Client提供的一些接口查看做業運行狀態。在Hadoop內部用「做業」 （Job）表示MapReduce程序。每個Job都會在用戶端經過Client類將應用程序以及參數配置Configuration打包成Jar文件存儲在HDFS，並把路徑提交到JobTracker，而後由JobTracker建立每個Task（即MapTask和ReduceTask），將它們分發到各個TaskTracker服務中去執行。

JobClient提交Job的詳細流程主要以下：

JobClient在獲取了JobTracker爲Job分配的id以後，會在JobTracker的系統目錄(HDFS)下爲該Job建立一個單獨的目錄，目錄的名字便是Job的id，該目錄下會包含文件job.xml、job.jar、job.split等，其中，job.xml文件記錄了Job的詳細配置信息，job.jar保存了用戶定義的關於job的map、reduce操縱，job.split保存了job任務的切分信息。

JobTracker

JobTracker 主要負責資源監控和做業調度。JobTracker 監控全部 TaskTracker 與做業Job的健康情況，一旦發現失敗狀況後，其會將相應的任務轉移到其餘節點；同時，JobTracker 會跟蹤任務的執行進度、資源使用量等信息，並將這些信息告訴任務調度器，而調度器會在資源出現空閒時，選擇合適的任務使用這些資源。在Hadoop 中，任務調度器是一個可插拔的模塊，用戶能夠根據本身的須要設計相應的調度器。

如下引用 www.aboutyun.com/thread-7778…

JobTracker爲做業的提交作了兩件事：一.爲做業生成一個Job；二.接受該做業。 咱們都知道，客戶端的JobClient把做業的全部相關信息都保存到了JobTracker的系統目錄下(固然是HDFS了)，這樣作的一個最大的好處就是客戶端幹了它所能幹的事情同時也減小了服務器端JobTracker的負載。下面就來看看JobTracker是如何來完成客戶端做業的提交的吧！哦。對了，在這裏我不得不提的是客戶端的JobClient向JobTracker正式提交做業時直傳給了它一個改做業的JobId，這是由於與Job相關的全部信息已經存在於JobTracker的系統目錄下，JobTracker只要根據JobId就能獲得這個Job目錄。

對於上面的Job的提交處理流程，我將簡單的介紹如下幾個過程：

1. 建立Job的JobInProgress
   JobInProgress對象詳細的記錄了Job的配置信息，以及它的執行狀況，確切的來講應該是Job被分解的map、reduce任務。在JobInProgress對象的建立過程當中，它主要乾了兩件事，一是把Job的job.xml、job.jar文件從Job目錄copy到JobTracker的本地文件系統(job.xml->/jobTracker/jobid.xml，job.jar->/jobTracker/jobid.jar)；二是建立JobStatus和Job的mapTask、reduceTask存隊列來跟蹤Job的狀態信息。
2. 檢查客戶端是否有權限提交Job
   JobTracker驗證客戶端是否有權限提交Job其實是交給QueueManager來處理的。
3. 檢查當前mapreduce集羣可以知足Job的內存需求
   客戶端提交做業以前，會根據實際的應用狀況配置做業任務的內存需求，同時JobTracker爲了提升做業的吞吐量會限制做業任務的內存需求，因此在Job的提交時，JobTracker須要檢查Job的內存需求是否知足JobTracker的設置。

上面流程已經完畢，能夠總結爲下圖：

TaskTracker

TaskTracker會週期性地經過心跳機制將本節點上資源的使用狀況和任務的運行進度彙報給JobTracker，同時接收JobTracker發送過來的命令並執行相應的操做（如啓動新任務、殺死 任務等）。TaskTracker 使用「slot」等量劃分本節點上的資源量。 「slot」表明計算資源（CPU、 內存等）。一個 Task 獲取到一個slot 後纔有機會運行，而Hadoop調度器的做用就是將各個TaskTracker上的空閒slot分配給Task使用。slot分爲Map slot和Reduce slot 兩種，分別供Map Task和Reduce Task使用。TaskTracker經過slot數目（可配置參數）限定Task的併發度。

這裏可能有人會混淆JobTracker、TaskTracker和Hadoop學習（一）——hdfs架構中所講的的DataNode、NameNode。其實JobTracker對應於NameNode，TaskTracker對應於DataNode。DataNode和NameNode是針對數據存放來而言的，JobTracker和TaskTracker是對於MapReduce執行而言的。

MapTask和ReduceTask

Task 分爲 Map Task 和 Reduce Task 兩種，均由TaskTracker啓動。從Hadoop學習（一）——hdfs架構中咱們知道，HDFS以固定大小的block 爲基本單位存儲數據，而對於MapReduce的輸入而言，其處理單位是split。 split 與 block 的對應關係默認是1:1。split 是一個邏輯概念，它只包含一些元數據信息，好比數據起始位置、數據長度、數據所在節點等。它的劃分方法徹底由用戶本身決定。但須要注意的是，split的多少決定了Map Task的數目，由於每一個split會交由一個Map Task處理。split會在後面MapReduce的執行過程當中詳細講。

MapReduce 1.x工做流程

www.aboutyun.com/thread-1549…

整個MapReduce做業的工做過程，以下所示：

1. 做業的提交 JobClient的submitJob()方法實現的做業提交過程，以下所示： 經過JobTracker的getNewJobId()請求一個新的做業ID；（2） 檢查做業的輸出說明（好比沒有指定輸出目錄或輸出目錄已經存在，就拋出異常）； 計算做業的輸入分片（當分片沒法計算時，好比輸入路徑不存在等緣由，就拋出異常）； 將運行做業所需的資源（好比做業Jar文件，配置文件，計算所得的輸入分片等）複製到一個以做業ID命名的目錄中。（集羣中有多個副本可供TaskTracker訪問）（3） 經過調用JobTracker的submitJob()方法告知做業準備執行。（4）

2. 做業的初始化 JobTracker接收到對其submitJob()方法的調用後，就會把這個調用放入一個內部隊列中，交由做業調度器（好比先進先出調度器，容量調度器，公平調度器等）進行調度；（5） 初始化主要是建立一個表示正在運行做業的對象——封裝任務和記錄信息，以便跟蹤任務的狀態和進程；（5） 爲了建立任務運行列表，做業調度器首先從HDFS中獲取JobClient已計算好的輸入分片信息（6）。而後爲每一個分片建立一個MapTask，而且建立ReduceTask。（Task在此時被指定ID，請區分清楚Job的ID和Task的ID）。

3. 任務的分配 TaskTracker按期經過「心跳」與JobTracker進行通訊，主要是告知JobTracker自身是否還存活，以及是否已經準備好運行新的任務等；（7） JobTracker在爲TaskTracker選擇任務以前，必須先經過做業調度器選定任務所在的做業； 對於MapTask和ReduceTask，TaskTracker有固定數量的任務槽（準確數量由TaskTracker核的數量和內存大小來決定）。JobTracker會先將TaskTracker的MapTask填滿，而後分配ReduceTask到TaskTracker； 對於MapTrask，JobTracker經過會選取一個距離其輸入分片文件最近的TaskTracker。對於ReduceTask，由於沒法考慮數據的本地化，因此也沒有什麼標準來選擇哪一個TaskTracker。

4. 任務的執行 TaskTracker分配到一個任務後，經過從HDFS把做業的Jar文件複製到TaskTracker所在的文件系統（Jar本地化用來啓動JVM），同時TaskTracker將應用程序所須要的所有文件從分佈式緩存複製到本地磁盤；（8） TaskTracker爲任務新建一個本地工做目錄，並把Jar文件中的內容解壓到這個文件夾中； TaskTracker啓動一個新的JVM（9）來運行每一個Task（包括MapTask和ReduceTask），這樣Client的MapReduce就不會影響TaskTracker守護進程（好比，致使崩潰或掛起等）； 子進程經過umbilical接口與父進程進行通訊，Task的子進程每隔幾秒便告知父進程它的進度，直到任務完成。

5. 進程和狀態的更新 一個做業和它的每一個任務都有一個狀態信息，包括做業或任務的運行狀態，Map和Reduce的進度，計數器值，狀態消息或描述（能夠由用戶代碼來設置）。這些狀態信息在做業期間不斷改變，它們是如何與Client通訊的呢？

• 任務在運行時，對其進度（即任務完成的百分比）保持追蹤。對於MapTask，任務進度是已處理輸入所佔的比例。對於ReduceTask，狀況稍微有點複雜，但系統仍然會估計已處理Reduce輸入的比例；
• 這些消息經過必定的時間間隔由Child JVM—>TaskTracker—>JobTracker匯聚。JobTracker將產生一個代表全部運行做業及其任務狀態的全局視圖。能夠經過Web UI查看。同時JobClient經過每秒查詢JobTracker來得到最新狀態，而且輸出到控制檯上。

6. 做業的完成 當JobTracker收到做業最後一個任務已完成的通知後，便把做業的狀態設置爲"成功"。而後，在JobClient查詢狀態時，便知道做業已成功完成，因而JobClient打印一條消息告知用戶，最後從runJob()方法返回。

MapReduce 1.x的缺點

隨着分佈式系統集羣的規模和其工做負荷的增加，原框架的問題逐漸浮出水面，主要的問題集中以下：

1. JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
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 版本而浪費大量時間。

MapReduce 2.x/Yarn框架

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

YARN是Hadoop 2.0中的資源管理系統，它的基本設計思想是將MRv1中的JobTracker拆分紅了兩個獨立的服務：一個全局的資源管理器ResourceManager和每一個應用程序特有的ApplicationMaster。其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。ApplicationMaster 承擔了之前的 TaskTracker 的一些角色，ResourceManager 承擔了 JobTracker 的角色。

YARN是一個資源管理、任務調度的框架，主要包含三大模塊：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）。其中，ResourceManager負責全部資源的監控、分配和管理；ApplicationMaster負責每個具體應用程序的調度和協調；NodeManager負責每個節點的維護。對於全部的applications，RM擁有絕對的控制權和對資源的分配權。而每一個AM則會和RM協商資源，同時和NodeManager通訊來執行和監控task。 幾個模塊之間的關係如圖所示。

MapReduce 2.x重點概念

ResourceManager(RM)

RM是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，AsM）。

• 調度器

  調度器根據容量、隊列等限制條件（如每一個隊列分配必定的資源，最多執行必定數量的做業等），將系統中的資源分配給各個正在運行的應用程序。

  須要注意的是，該調度器是一個「純調度器」，它再也不從事任何與具體應用程序相關的工做，好比不負責監控或者跟蹤應用的執行狀態等，也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據本身的須要設計新的調度器，YARN提供了多種直接可用的調度器，好比Fair Scheduler和Capacity Scheduler等。

• 應用程序管理器

  應用程序管理器負責管理整個系統中全部應用程序，包括應用程序提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時從新啓動它等。

NodeManager（NM）

NM是每一個節點上的資源和任務管理器，一方面，它會定時地向RM彙報本節點上的資源使用狀況和各個Container的運行狀態；另外一方面，它接收並處理來自AM的Container啓動/中止等各類請求。

ApplicationMaster（AM）

用戶提交的應用程序均包含一個AM，負責爲應用程序申請資源並分配給內部的任務，應用的監控，跟蹤應用執行狀態，重啓失敗任務等。ApplicationMaster是應用框架，它負責向ResourceManager協調資源，而且與NodeManager協同工做完成Task的執行和監控。MapReduce就是原生支持的一種框架，能夠在YARN上運行Mapreduce做業。有不少分佈式應用都開發了對應的應用程序框架，用於在YARN上運行任務，例如Spark，Storm等。若是須要，咱們也能夠本身寫一個符合規範的YARN application。

Container

Container 是 YARN 中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM爲AM返回的資源即是用Container表示的。YARN會爲每一個任務分配一個Container，且該任務只能使用該Container中描述的資源。每一個Container能夠根據須要運行ApplicationMaster、Map、Reduce或者任意的程序。

YARN應用工做流程

1. 用戶向YARN中提交應用程序，其中包括AM程序、啓動AM的命令、命令參數、用戶程序等；事實上，須要準確描述運行ApplicationMaster的unix進程的全部信息。提交工做一般由YarnClient來完成。

2. RM爲該應用程序分配第一個Container，並與對應的NM通訊，要求它在這個Container中啓動AM；

3. AM首先向RM註冊，這樣用戶能夠直接經過RM査看應用程序的運行狀態，運行狀態經過 AMRMClientAsync.CallbackHandler的getProgress() 方法來傳遞給RM。 而後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟4〜7；

4. AM採用輪詢的方式經過RPC協議向RM申請和領取資源；資源的協調經過 AMRMClientAsync異步完成,相應的處理方法封裝在AMRMClientAsync.CallbackHandler中。

5. —旦AM申請到資源後，便與對應的NM通訊，要求它啓動任務；一般須要指定一個ContainerLaunchContext，提供Container啓動時須要的信息。

6. NM爲任務設置好運行環境(包括環境變量、JAR包、二進制程序等)後，將任務啓動命令寫到一個腳本中，並經過運行該腳本啓動任務；

7. 各個任務經過某個RPC協議向AM彙報本身的狀態和進度，以讓AM隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務；ApplicationMaster與NM的通訊經過NMClientAsync object來完成，容器的全部事件經過NMClientAsync.CallbackHandler來處理。例如啓動、狀態更新、中止等。

8. 應用程序運行完成後，AM向RM註銷並關閉本身。