如何實(shí)現(xiàn)MRv1和Yarn對(duì)比

這篇文章跟大家分析一下“如何實(shí)現(xiàn)MRv1和Yarn對(duì)比”。內(nèi)容詳細(xì)易懂，對(duì)“如何實(shí)現(xiàn)MRv1和Yarn對(duì)比”感興趣的朋友可以跟著小編的思路慢慢深入來閱讀一下，希望閱讀后能夠?qū)Υ蠹矣兴鶐椭?。下面跟著小編一起深入學(xué)習(xí)“如何實(shí)現(xiàn)MRv1和Yarn對(duì)比”的知識(shí)吧。

      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、Storm等，  通常而言，我們一般將運(yùn)行在YARN上的計(jì)算框架稱為“X on YARN”，比如“MapReduce On YARN”, "Spark On YARN"，“Storm On YARN”等。

     這在官網(wǎng)上描述的很清楚：

• Hadoop Common:       The common utilities that support the other Hadoop modules.

• Hadoop Distributed File System (HDFS?):       A distributed file system that provides high-throughput access to application data.

• Hadoop YARN:       A framework for job scheduling and cluster resource management.

• Hadoop MapReduce:       A YARN-based system for parallel processing of large data sets.

原Hadoop MapReduce 框架的問題

對(duì)于業(yè)界的大數(shù)據(jù)存儲(chǔ)及分布式處理系統(tǒng)來說，Hadoop 是耳熟能詳?shù)淖吭介_源分布式文件存儲(chǔ)及處理框架，對(duì)于 Hadoop 框架的介紹在此不再累述，讀者可參考 Hadoop 官方簡(jiǎn)介。使用和學(xué)習(xí)過老 Hadoop 框架（0.20.0 及之前版本）的同仁應(yīng)該很熟悉如下的原 MapReduce 框架圖：

圖 1.Hadoop 原 MapReduce 架構(gòu)

從上圖中可以清楚的看出原 MapReduce 程序的流程及設(shè)計(jì)思路：

1. 首先用戶程序 (JobClient) 提交了一個(gè) job，job 的信息會(huì)發(fā)送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要與集群中的機(jī)器定時(shí)通信 (heartbeat), 需要管理哪些程序應(yīng)該跑在哪些機(jī)器上，需要管理所有 job 失敗、重啟等操作。

2. TaskTracker 是 Map-reduce 集群中每臺(tái)機(jī)器都有的一個(gè)部分，他做的事情主要是監(jiān)視自己所在機(jī)器的資源情況。

3. TaskTracker 同時(shí)監(jiān)視當(dāng)前機(jī)器的 tasks 運(yùn)行狀況。TaskTracker 需要把這些信息通過 heartbeat 發(fā)送給 JobTracker，JobTracker 會(huì)搜集這些信息以給新提交的 job 分配運(yùn)行在哪些機(jī)器上。上圖虛線箭頭就是表示消息的發(fā)送 - 接收的過程。

可以看得出原來的 map-reduce 架構(gòu)是簡(jiǎn)單明了的，在最初推出的幾年，也得到了眾多的成功案例，獲得業(yè)界廣泛的支持和肯定，但隨著分布式系統(tǒng)集群的規(guī)模和其工作負(fù)荷的增長(zhǎng)，原框架的問題逐漸浮出水面，主要的問題集中如下：

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ù)目作為資源的表示過于簡(jiǎn)單，沒有考慮到 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)，也就是前面提過的集群資源利用的問題。

5. 源代碼層面分析的時(shí)候，會(huì)發(fā)現(xiàn)代碼非常的難讀，常常因?yàn)橐粋€(gè) class 做了太多的事情，代碼量達(dá) 3000 多行，，造成 class 的任務(wù)不清晰，增加 bug 修復(fù)和版本維護(hù)的難度。

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

新 Hadoop Yarn 框架原理及運(yùn)作機(jī)制

從業(yè)界使用分布式系統(tǒng)的變化趨勢(shì)和 hadoop 框架的長(zhǎng)遠(yuǎn)發(fā)展來看，MapReduce 的 JobTracker/TaskTracker 機(jī)制需要大規(guī)模的調(diào)整來修復(fù)它在可擴(kuò)展性，內(nèi)存消耗，線程模型，可靠性和性能上的缺陷。在過去的幾年中，hadoop 開發(fā)團(tuán)隊(duì)做了一些 bug 的修復(fù)，但是最近這些修復(fù)的成本越來越高，這表明對(duì)原框架做出改變的難度越來越大。

為從根本上解決舊 MapReduce 框架的性能瓶頸，促進(jìn) Hadoop 框架的更長(zhǎng)遠(yuǎn)發(fā)展，從 0.23.0 版本開始，Hadoop 的 MapReduce 框架完全重構(gòu)，發(fā)生了根本的變化。新的 Hadoop MapReduce 框架命名為 MapReduceV2 或者叫 Yarn，其架構(gòu)圖如下圖所示：

圖 2. 新的 Hadoop MapReduce 框架（Yarn）架構(gòu)

重構(gòu)根本的思想是將 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)用程序無(wú)非是一個(gè)單獨(dú)的傳統(tǒng)的 MapReduce 任務(wù)或者是一個(gè) DAG( 有向無(wú)環(huán)圖 ) 任務(wù)。ResourceManager 和每一臺(tái)機(jī)器的節(jié)點(diǎn)管理服務(wù)器能夠管理用戶在那臺(tái)機(jī)器上的進(jìn)程并能對(duì)計(jì)算進(jìn)行組織。

事實(shí)上，每一個(gè)應(yīng)用的 ApplicationMaster 是一個(gè)詳細(xì)的框架庫(kù)，它結(jié)合從 ResourceManager 獲得的資源和 NodeManager 協(xié)同工作來運(yùn)行和監(jiān)控任務(wù)。

上圖中 ResourceManager 支持分層級(jí)的應(yīng)用隊(duì)列，這些隊(duì)列享有集群一定比例的資源。從某種意義上講它就是一個(gè)純粹的調(diào)度器，它在執(zhí)行過程中不對(duì)應(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)度模型。

上圖中 NodeManager 是每一臺(tái)機(jī)器框架的代理，是執(zhí)行應(yīng)用程序的容器，監(jiān)控應(yīng)用程序的資源使用情況 (CPU，內(nèi)存，硬盤，網(wǎng)絡(luò) ) 并且向調(diào)度器匯報(bào)。

每一個(gè)應(yīng)用的 ApplicationMaster 的職責(zé)有：向調(diào)度器索要適當(dāng)?shù)馁Y源容器，運(yùn)行任務(wù)，跟蹤應(yīng)用程序的狀態(tài)和監(jiān)控它們的進(jìn)程，處理任務(wù)的失敗原因。

Yarn執(zhí)行任務(wù)流程

它的基本設(shè)計(jì)思想是將MapReduce中的JobTracker拆分成了兩個(gè)獨(dú)立的服務(wù)：一個(gè)全局的資源管理器ResourceManager和每個(gè)應(yīng) 用程序特有的ApplicationMaster。其中ResourceManager負(fù)責(zé)整個(gè)系統(tǒng)的資源管理和分配，而 ApplicationMaster則負(fù)責(zé)單個(gè)應(yīng)用程序的管理。

當(dāng)用戶向YARN中提交一個(gè)應(yīng)用程序后，YARN將分兩個(gè)階段運(yùn)行該應(yīng)用程序：第一個(gè)階段是啟動(dòng)ApplicationMaster；第二個(gè)階段是 由ApplicationMaster創(chuàng)建應(yīng)用程序，為它申請(qǐng)資源，并監(jiān)控它的整個(gè)運(yùn)行過程，直到運(yùn)行成功。如圖2-7所示，YARN的工作流程分為以下 幾個(gè)步驟：

步驟1 用戶向YARN中提交應(yīng)用程序，其中包括ApplicationMaster程序、啟動(dòng)ApplicationMaster的命令、用戶程序等。

步驟2 ResourceManager為該應(yīng)用程序分配第一個(gè)Container，并與對(duì)應(yīng)的NodeManager通信，要求它在這個(gè)Container中啟動(dòng)應(yīng)用程序的ApplicationMaster。

步驟3 ApplicationMaster首先向ResourceManager注冊(cè)，這樣，用戶可以直接通過ResourceManage查看應(yīng)用程序的運(yùn)行狀態(tài)，然后，它將為各個(gè)任務(wù)申請(qǐng)資源，并監(jiān)控它的運(yùn)行狀態(tài)，直到運(yùn)行結(jié)束，即重復(fù)步驟4~7。

步驟4 ApplicationMaster采用輪詢的方式通過RPC協(xié)議向ResourceManager申請(qǐng)和領(lǐng)取資源。

步驟5 一旦ApplicationMaster申請(qǐng)到資源后，則與對(duì)應(yīng)的NodeManager通信，要求其啟動(dòng)任務(wù)。

步驟6 NodeManager為任務(wù)設(shè)置好運(yùn)行環(huán)境（包括環(huán)境變量、jar包、二進(jìn)制程序等）后，將任務(wù)啟動(dòng)命令寫到一個(gè)腳本中，并通過運(yùn)行該腳本啟動(dòng)任務(wù)。

步驟7 各個(gè)任務(wù)通過某個(gè)RPC協(xié)議向ApplicationMaster匯報(bào)自己的狀態(tài)和進(jìn)度，以讓ApplicationMaster隨時(shí)掌握各個(gè)任務(wù)的運(yùn)行 狀態(tài)，從而可以在任務(wù)失敗時(shí)重新啟動(dòng)任務(wù)。在應(yīng)用程序運(yùn)行過程中，用戶可隨時(shí)通過RPC向ApplicationMaster查詢應(yīng)用程序的當(dāng)前運(yùn)行狀 態(tài)。

步驟8 應(yīng)用程序運(yùn)行完成后，ApplicationMaster向ResourceManager注銷，并關(guān)閉自己。

關(guān)于如何實(shí)現(xiàn)MRv1和Yarn對(duì)比就分享到這里啦，希望上述內(nèi)容能夠讓大家有所提升。如果想要學(xué)習(xí)更多知識(shí)，請(qǐng)大家多多留意小編的更新。謝謝大家關(guān)注一下億速云網(wǎng)站！