1 MapReduce2產(chǎn)生的原因

1.1 在hadoop1.X的時代，MapReduce做了很多的事情，其核心是JobTracker。

1.2 初探MapReduce1架構(gòu)

• 首先客戶端要編寫好mapreduce程序，然后提交作業(yè)也就是job，job的信息會發(fā)送到JobTracker上，并為該job分配一個ID值，接下來做檢查操作，確認輸入目錄是否存在，如果不存在，則會拋錯，如果存在繼續(xù)檢查輸出目錄是否存在，如果存在則會拋錯，否則繼續(xù)運行；當檢查工作都做好了JobTracker就會配置Job需要的資源了。
• JobTracker: 主要負責資源監(jiān)控管理和作業(yè)調(diào)度
  • （a）監(jiān)控所有TaskTracker 與job的健康狀況,一旦發(fā)現(xiàn)失敗,就將相應的任務轉(zhuǎn)移到其他節(jié)點；
  • （b）同時JobTracker會跟蹤任務的執(zhí)行進度、資源使用量等信息,并將這些信息告訴任務調(diào)度器,而調(diào)度器會在資源出現(xiàn)空閑時,選擇合適的任務使用這些資源。
• TaskTracker：是JobTracker與Task之前的橋梁
  • （a）從JobTracker接收并執(zhí)行各種命令:運行任務、提交任務、Kill任務、重新初始化任務;
  • （b）周期性地通過心跳機制,將節(jié)點健康情況和資源使用情況、各個任務的進度和狀態(tài)等匯報給JobTracker。
• Task Scheduler: 任務調(diào)度器(默認FIFO,先按照作業(yè)的優(yōu)先級高低,再按照到達時間的先后選擇被執(zhí)行的作業(yè))

1.3MapReduce1缺陷

• Hadoop1.x的MapReduce框架的主要局限：
  • （1）JobTracker 是 Map-reduce 的集中處理點，存在單點故障，可靠性差；
  • （2）JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的內(nèi)存開銷，潛在來說，也增加了 JobTracker 失效的風險，這也是業(yè)界普遍總結(jié)出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點主機的上限，擴展性能差。
  • （3）可預測的延遲：這是用戶非常關(guān)心的。小作業(yè)應該盡可能快得被調(diào)度，而當前基于TaskTracker->JobTracker ping（heartbeat）的通信方式代價和延遲過大，比較好的方式是JobTracker->TaskTracker ping, 這樣JobTracker可以主動掃描有作業(yè)運行的TaskTracker。

面對上訴一系列問題mr1已經(jīng)不能滿足我們的需求，因此在hadoop2.x中MapReduce2應運而生，下面我們一起學習MapReduce2。

2 MapReduce2架構(gòu)設(shè)計

2.1 官網(wǎng)初析MapReduce2

• 從官網(wǎng)上我們可以看到，在Apache Hadoop 2.x中，我們將資源管理和作業(yè)調(diào)度功能分解為Apache Hadoop YARN來進行管理，它一種通用的分布式應用程序管理框架，而Apache Hadoop MapReduce（又名MRv2）是一個純粹的分布式計算框架。官網(wǎng)地址
• 之前的MapReduce運行時（又名MRv1）已經(jīng)被重用，沒有進行較大的變化。因此，MRv2能夠確保與MRv1應用的令人滿意的兼容性。但是，由于一些改進和代碼重構(gòu)，一些API已經(jīng)向后兼容。
• 可以看出不同的是資源管理和作業(yè)管理系統(tǒng)，MRv1中資源管理和作業(yè)管理均是由JobTracker實現(xiàn)的，集兩個功能于一身，而在MRv2中，將這兩部分分開了。

MRv2最基本的設(shè)計思想是將JobTracker的兩個主要功能，即資源管理和作業(yè)調(diào)度/監(jiān)控分成兩個獨立的進程。在該解決方案中包含兩個組件：全局的ResourceManager（RM）和與每個應用相關(guān)的ApplicationMaster（AM）。這里的“應用”指一個單獨的MapReduce作業(yè)。RM和與NodeManager（NM，每個節(jié)點一個）共同組成整個數(shù)據(jù)計算框架。RM是系統(tǒng)中將資源分配給各個應用的最終決策者。AM實際上是一個具體的框架庫，它的任務是【與RM協(xié)商獲取應用所需資源】和【與NM合作，以完成執(zhí)行和監(jiān)控task的任務】。

2.2 MapReduce2組成部分

• ResourceManager（RM）包含兩個主要的組件：定時調(diào)用器(Scheduler)以及應用管理器(ApplicationManager)
  • （1）調(diào)度器（Scheduler）：根據(jù)容量，隊列等限制條件，將系統(tǒng)中的資源分配給各個正在運行的應用。這里的調(diào)度器是一個“純調(diào)度器”，因為它不再負責監(jiān)控或者跟蹤應用的執(zhí)行狀態(tài)等，此外，他也不負責重新啟動因應用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務。調(diào)度器僅根據(jù)各個應用的資源需求進行調(diào)度，這是通過抽象概念“資源容器”完成的，資源容器（Resource Container）將內(nèi)存，CPU，磁盤，網(wǎng)絡等資源封裝在一起，從而限定每個任務使用的資源量。總而言之，定時調(diào)度器負責向應用程序分配資源，它不做監(jiān)控以及應用程序的狀態(tài)跟蹤，并且它不保證會重啟由于應用程序本身或硬件出錯而執(zhí)行失敗的應用程序。
  • （2）應用管理器（ApplicationsManager，ASM）：ASM主要負責接收作業(yè)，協(xié)商獲取第一個容器用于執(zhí)行AM和提供重啟失敗AM container的服務。
• NodeManager：NM是每個節(jié)點上的框架代理，主要負責啟動應用所需的容器，監(jiān)控資源（內(nèi)存，CPU，磁盤，網(wǎng)絡等）的使用情況并將之匯報給調(diào)度器（Scheduler）。
• ApplicationMaster：每個應用程序的ApplicationMaster負責從Scheduler申請資源，以及跟蹤這些資源的使用情況以及任務進度的監(jiān)控。
• Container：是YARN中資源的抽象，它將內(nèi)存、CPU、磁盤、網(wǎng)絡等資源封裝在一起。當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。

3 MapReduce2提交應用程序的過程分析

• 在作業(yè)的提交階段，client向RM提交一個job，這時RM會進行檢查，如果沒有問題，會返回作業(yè)文件提交的路徑和jod id；client向HDFS上傳文件，準備就緒后請求RM運行作業(yè)；
• 作業(yè)初始化階段，用戶將應用程序提交到ResourceManager后，RM為該作業(yè)分配第一個Container，并與對應的NM通信，在Container中啟動作業(yè)的MRAppMaster；
• MRAppMaster首先向ResourceManager注冊，這樣用戶可以直接通過ResourceManage查看應用程序的運行狀態(tài)，然后它將為各個任務申請資源，并監(jiān)控它的運行狀態(tài)；
• MRAppMaster采用輪詢的方式式通過RPC協(xié)議向RM申請任務所需資源；
• 一旦MRAppMaster申請到資源后，便與對應的NodeManager通信，要求它啟動任務；
• NodeManager為任務設(shè)置好運行環(huán)境（包括環(huán)境變量、JAR包、二進制程序等）后，將任務啟動命令寫到一個腳本中，并通過運行該腳本啟動任務；
• 各個任務通過某個RPC協(xié)議向MRAppMaster匯報自己的狀態(tài)和進度，以讓MRAppMaster隨時掌握各個任務的運行狀態(tài)，從而可以在任務失敗時重新啟動任務。在應用程序運行過程中，用戶可隨時通過RPC向MRAppMaster查詢應用程序的當前運行狀態(tài);
• 應用程序運行完成后，ApplicationMaster向ResourceManager注銷并關(guān)閉自己。

當用戶向YARN中提交一個應用程序后，YARN將分兩個階段運行該應用程序：

a. 第一個階段是啟動ApplicationMaster；
b. 第二個階段是由ApplicationMaster創(chuàng)建應用程序，為它申請資源，并監(jiān)控它的整個運行過程，直到運行完

以上就是MapReduce2框架的原理解析的詳細內(nèi)容，更多關(guān)于MapReduce2框架的資料請關(guān)注腳本之家其它相關(guān)文章！