Hadoop-MapReduce2.x-yarn框架

1.mapreduce1.0的不足

1. JobTracker 是 Map-reduce 的集中處理點(diǎn)，存在單點(diǎn)故障。
2. JobTracker 完成了太多的任務(wù)，造成了過多的資源消耗，當(dāng) map-reduce job 非常多的時(shí)候，會(huì)造成很大的內(nèi)存開銷，潛在來說，也增加了 JobTracker fail 的風(fēng)險(xiǎn)，這也是業(yè)界普遍總結(jié)出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點(diǎn)主機(jī)的上限。
3. 在 TaskTracker 端，以 map/reduce task 的數(shù)目作為資源的表示過于簡單，沒有考慮到 cpu/內(nèi)存的占用情況，如果兩個(gè)大內(nèi)存消耗的 task 被調(diào)度到了一塊，很容易出現(xiàn) OOM。
4. 在 TaskTracker 端，把資源強(qiáng)制劃分為 map task slot 和 reduce task slot, 如果當(dāng)系統(tǒng)中只有 map task 或者只有 reduce task 的時(shí)候，會(huì)造成資源的浪費(fèi)，也就是前面提過的集群資源利用的問題。源代碼層面分析的時(shí)候，會(huì)發(fā)現(xiàn)代碼非常的難讀，常常因?yàn)橐粋€(gè) class 做了太多的事情，代碼量達(dá) 3000 多行造成 class 的任務(wù)不清晰，增加 bug 修復(fù)和版本維護(hù)的難度。

5. 從操作的角度來看，現(xiàn)在的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復(fù)，性能提升和特性化 ) 時(shí)，都會(huì)強(qiáng)制進(jìn)行系統(tǒng)級別的升級更新。更糟的是，它不管用戶的喜好，強(qiáng)制讓分布式集群系統(tǒng)的每一個(gè)用戶端同時(shí)更新。這些更新會(huì)讓用戶為了驗(yàn)證他們之前的應(yīng)用程序是不是適用新的 Hadoop 版本而浪費(fèi)大量時(shí)間。

2.Hadoop2.x中新方案YARN+MapReduce

首先的不要被YARN給迷惑住了,它只是負(fù)責(zé)資源調(diào)度管理,而MapReduce才是負(fù)責(zé)運(yùn)算的家伙,所以YARN != MapReduce2.這是大師說的:

YARN并不是下一代MapReduce（MRv2），下一代MapReduce與第一代MapReduce（MRv1）在編程接口、數(shù)據(jù)處理引擎（MapTask和ReduceTask）是完全一樣的， 可認(rèn)為MRv2重用了MRv1的這些模塊，不同的是資源管理和作業(yè)管理系統(tǒng)，MRv1中資源管理和作業(yè)管理均是由JobTracker實(shí)現(xiàn)的，集兩個(gè)功能于一身，而在MRv2中，將這兩部分分開了， 其中，作業(yè)管理由ApplicationMaster實(shí)現(xiàn)，而資源管理由新增系統(tǒng)YARN完成，由于YARN具有通用性，因此YARN也可以作為其他計(jì)算框架的資源管理系統(tǒng)，不僅限于MapReduce，也是其他計(jì)算框架(Spark).

img

? 看上圖我們可以知道Hadoop1中mapreduce可以說是啥事都干,而Hadoop2中的MapReduce的話則是專門處理數(shù)據(jù)分析.而YARN的話則做為資源管理器存在.

在Hadoop2中將JobTracker兩個(gè)主要的功能分離成單獨(dú)的組件，這兩個(gè)功能是資源管理和任務(wù)調(diào)度/監(jiān)控。新的資源管理器全局管理所有應(yīng)用程序計(jì)算資源的分配，每一個(gè)應(yīng)用的 ApplicationMaster 負(fù)責(zé)相應(yīng)的調(diào)度和協(xié)調(diào)。一個(gè)應(yīng)用程序無非是一個(gè)單獨(dú)的傳統(tǒng)的 MapReduce 任務(wù)或者是一個(gè) DAG( 有向無環(huán)圖 ) 任務(wù)。ResourceManager 和每一臺(tái)機(jī)器的節(jié)點(diǎn)管理服務(wù)器能夠管理用戶在那臺(tái)機(jī)器上的進(jìn)程并能對計(jì)算進(jìn)行組織。
1.事實(shí)上，每一個(gè)應(yīng)用的ApplicationMaster是一個(gè)詳細(xì)的框架庫，它結(jié)合從ResourceManager獲得的資源和 NodeManagr 協(xié)同工作來運(yùn)行和監(jiān)控任務(wù)。
2.在上圖中ResourceManager支持分層級的應(yīng)用隊(duì)列，這些隊(duì)列享有集群一定比例的資源。從某種意義上講它就是一個(gè)純粹的調(diào)度器，它在執(zhí)行過程中不對應(yīng)用進(jìn)行監(jiān)控和狀態(tài)跟蹤。同樣，它也不能重啟因應(yīng)用失敗或者硬件錯(cuò)誤而運(yùn)行失敗的任務(wù)。
ResourceManager 是基于應(yīng)用程序?qū)Y源的需求進(jìn)行調(diào)度的 ; 每一個(gè)應(yīng)用程序需要不同類型的資源因此就需要不同的容器。資源包括：內(nèi)存，CPU，磁盤，網(wǎng)絡(luò)等等。可以看出，這同現(xiàn) Mapreduce 固定類型的資源使用模型有顯著區(qū)別，它給集群的使用帶來負(fù)面的影響。資源管理器提供一個(gè)調(diào)度策略的插件，它負(fù)責(zé)將集群資源分配給多個(gè)隊(duì)列和應(yīng)用程序。調(diào)度插件可以基于現(xiàn)有的能力調(diào)度和公平調(diào)度模型。
3.在上圖中 NodeManager 是每一臺(tái)機(jī)器框架的代理，是執(zhí)行應(yīng)用程序的容器，監(jiān)控應(yīng)用程序的資源使用情況 (CPU，內(nèi)存，硬盤，網(wǎng)絡(luò) ) 并且向調(diào)度器匯報(bào)。
4.在上圖中,每一個(gè)應(yīng)用的 ApplicationMaster的職責(zé)有：向調(diào)度器索要適當(dāng)?shù)馁Y源容器，運(yùn)行任務(wù)，跟蹤應(yīng)用程序的狀態(tài)和監(jiān)控它們的進(jìn)程，處理任務(wù)的失敗原因。

1.客戶端的mapreduce程序通過hadoop shell提交到hadoop的集群中.
2.程序會(huì)通過RPC通信將打成jar包的程序的有關(guān)信息傳遞給Hadoop集群中RM(ResourceManager),可稱為領(lǐng)取JOBID的過程
3.RM更加提交上來的信息給任務(wù)分配一個(gè)唯一的ID,同時(shí)會(huì)將run.jar的在HDFS上的存儲(chǔ)路徑發(fā)送給客戶端.
4.客戶端得到那個(gè)存儲(chǔ)路徑之后,會(huì)相應(yīng)的拼接出最終的存放路徑目錄,然后將run.jar分多份存儲(chǔ)在HDFS目錄中,默認(rèn)情況下備份數(shù)量為10份.可配置.
5.客戶端提交一些配置信息,例如:最終存儲(chǔ)路徑，JOB ID等.
6.RM會(huì)將這些配置信息放入一個(gè)隊(duì)列當(dāng)中,所謂的調(diào)度器.至于調(diào)度的算法,則不必深究.
7.NM(NodeManager)和RM是通過心跳機(jī)制保持著通信的,NM會(huì)定期的向RM去領(lǐng)取任務(wù).
8.RM會(huì)在任意的一臺(tái)或多臺(tái)的NM中，啟動(dòng)任務(wù)監(jiān)控的進(jìn)程Application Master.用來監(jiān)控其他NM中YARN CHild的執(zhí)行的情況
9.NM在領(lǐng)取到任務(wù)之后,得到信息，會(huì)去HDFS的下載run.jar.然后在本地的機(jī)器上啟動(dòng)YARN Child進(jìn)程來執(zhí)行map或者reduce函數(shù).map函數(shù)的處理之后的中間結(jié)果數(shù)據(jù)會(huì)放在本地文件系統(tǒng)中的.
10.在結(jié)束程序之后,將結(jié)果數(shù)據(jù)寫會(huì)HDFS中.整個(gè)流程大概就是這樣子的.

3.執(zhí)行過程

作業(yè)提交

Job實(shí)例調(diào)用submit()方法提交一個(gè)作業(yè)，這個(gè)方法會(huì)創(chuàng)建一個(gè)JobSubmitter實(shí)例(圖中第1步)。提交完作業(yè)后，waitForCompletion(如果代碼中調(diào)用了的話)方法會(huì)每隔一秒查看作業(yè)的狀態(tài)并且將變化(如果有的話)打印到終端。

在JobSubmitter中會(huì)做如下事情：

向Yarn RM中請求一個(gè)新的應(yīng)用ID，分配給這個(gè)MR作業(yè)(第2步)。 檢查作業(yè)的輸出需求。例如，如果輸出目錄已經(jīng)存在，則不提交作業(yè)并且拋出一個(gè)異常。 計(jì)算作業(yè)的輸入切片(準(zhǔn)確說是切片信息)。如果切片不能被計(jì)算出來(例如輸入目錄不存在)，同樣作業(yè)不會(huì)被提交并且發(fā)出一個(gè)異常。 拷貝各種作業(yè)資源(例如作業(yè)的jar包，配置文件，切片信息等)到分布式文件系統(tǒng)下的一個(gè)被命名為job ID的目錄下(第3步)。 調(diào)用submitApplicatiion方法提交作業(yè)到Y(jié)arn RM(第4步)。

作業(yè)初始化

當(dāng)Yarn RM收到了submitApplicatiion方法中的請求。它將這個(gè)請求交給Yarn調(diào)度器。調(diào)度器會(huì)分配一個(gè)容器，然后Yarn RM在這個(gè)容器中啟動(dòng)一個(gè)AM(在NM管理下)(5a和5b)。

AM是一個(gè)java應(yīng)用，它的主類叫做MRAppMaster。這個(gè)類會(huì)創(chuàng)建一些記錄對象，用來獲取來自任務(wù)的報(bào)告(第6步)。然后會(huì)從分布式文件系統(tǒng)中獲取切片信息(第7步)。為每一個(gè)分片創(chuàng)建一個(gè)map任務(wù)，而reduce任務(wù)的個(gè)數(shù)由mapreduce.job.reduces屬性或者setNumReduceTasks方法指定。同樣任務(wù)的ID也在這個(gè)時(shí)候被分配。

AM也需要決定如何運(yùn)行這些任務(wù)。如果作業(yè)太小，AM則把所有的任務(wù)跑在一個(gè)JVM中。這種作業(yè)被稱為uber任務(wù)。

任務(wù)分配

如果作業(yè)不是uber任務(wù)，AM則會(huì)從RM那里為每一個(gè)map和reduce任務(wù)請求一個(gè)容器(第8步)。當(dāng)然為map請求容器的優(yōu)先級要高于reduce。事實(shí)上，reduce任務(wù)的請求直到至少5%的map任務(wù)完成才會(huì)被提出。

還需要注意到, map任務(wù)會(huì)盡量遵守locality約束，而reduce任務(wù)則可以運(yùn)行在集群的任意地方。

任務(wù)執(zhí)行

一旦RM給某個(gè)任務(wù)分配了某個(gè)特定節(jié)點(diǎn)上的容器，AM通過NM啟動(dòng)這個(gè)容器(9a和9b)。這個(gè)任務(wù)是一個(gè)Java應(yīng)用并且主類叫做YarnChild。在運(yùn)行這個(gè)任務(wù)之前，它會(huì)先從分布式文件系統(tǒng)中獲取各種資源(第10步)。最后，它運(yùn)行這個(gè)任務(wù)(第11步)。

狀態(tài)更新

當(dāng)任務(wù)運(yùn)行時(shí)，它記錄了自己的進(jìn)度。對于map任務(wù)，是自己處理的分片的比例。對于reduce任務(wù)，稍微復(fù)雜一點(diǎn)，需要把整個(gè)過程分為三個(gè)部分，即shuffle和sort的三個(gè)階段：copy, sort 和reduce，然后再估算。

每個(gè)任務(wù)，會(huì)每三秒通過一個(gè)臍帶(umbilical)接口向AM報(bào)告自己的狀態(tài)，而client則每一秒從AM那里收到最新的進(jìn)度。

作業(yè)完成

當(dāng)AM收到最后一個(gè)任務(wù)完成的消息時(shí)，它會(huì)把作業(yè)的狀態(tài)變?yōu)椤俺晒Α?。Job實(shí)例則獲得這個(gè)狀態(tài)后，告訴用戶并且它的waitForCompletion方法會(huì)返回值，同時(shí)各種統(tǒng)計(jì)信息會(huì)被打印出來。

稍微提一點(diǎn)的是，通過配置mapreduce.job.end-notification.url property參數(shù)，AM也會(huì)發(fā)送HTTP通知。

最后AM和任務(wù)的容器會(huì)清理它們的狀態(tài)。以及一些其他的收尾工作也在這時(shí)候被完成。