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

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

1.2 初探MapReduce1架構(gòu)

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

1.3MapReduce1缺陷

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

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

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

2.1 官網(wǎng)初析MapReduce2

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

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

2.2 MapReduce2組成部分

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

3 MapReduce2提交應(yīng)用程序的過程分析

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

當(dāng)用戶向YARN中提交一個(gè)應(yīng)用程序后，YARN將分兩個(gè)階段運(yùn)行該應(yīng)用程序：

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

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

最新評論