1.YARN

本質(zhì)上是資源管理系統(tǒng)。YARN提供了資源管理和資源調(diào)度等機(jī)制

1.1原 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.2Hadoop 原 MapReduce 架構(gòu)

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

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

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

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

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

JobTracker 是 Map-reduce 的集中處理點(diǎn)，存在單點(diǎn)故障。

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ī)的上限。

在 TaskTracker 端，以 map/reduce task 的數(shù)目作為資源的表示過于簡(jiǎn)單，沒有考慮到 cpu/ 內(nèi)存的占用情況，如果兩個(gè)大內(nèi)存消耗的 task 被調(diào)度到了一塊，很容易出現(xiàn) OOM。

在 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ù)的難度。

從操作的角度來看，現(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í)間。

1.3新 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)

新的 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)用程序無非是一個(gè)單獨(dú)的傳統(tǒng)的MapReduce 任務(wù)或者是一個(gè) DAG( 有向無環(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ù)的失敗原因。

新舊 Hadoop MapReduce 框架比對(duì)

讓我們來對(duì)新舊 MapReduce 框架做詳細(xì)的分析和對(duì)比，可以看到有以下幾點(diǎn)顯著變化：

首先客戶端不變，其調(diào)用 API 及接口大部分保持兼容，這也是為了對(duì)開發(fā)使用者透明化，使其不必對(duì)原有代碼做大的改變 ( 詳見 2.3 Demo 代碼開發(fā)及詳解)，但是原框架中核心的JobTracker 和 TaskTracker 不見了，取而代之的是 ResourceManager, ApplicationMaster 與NodeManager 三個(gè)部分。

我們來詳細(xì)解釋這三個(gè)部分，首先 ResourceManager 是一個(gè)中心的服務(wù)，它做的事情是調(diào)度、啟動(dòng)每一個(gè) Job 所屬的 ApplicationMaster、另外監(jiān)控 ApplicationMaster 的存在情況。細(xì)心的讀者會(huì)發(fā)現(xiàn)：Job 里面所在的 task 的監(jiān)控、重啟等等內(nèi)容不見了。這就是 AppMst 存在的原因。ResourceManager 負(fù)責(zé)作業(yè)與資源的調(diào)度。接收 JobSubmitter 提交的作業(yè)，按照作業(yè)的上下文 (Context) 信息，以及從 NodeManager 收集來的狀態(tài)信息，啟動(dòng)調(diào)度過程，分配一個(gè) Container 作為 App Mstr

NodeManager 功能比較專一，就是負(fù)責(zé) Container 狀態(tài)的維護(hù)，并向 RM 保持心跳。

ApplicationMaster 負(fù)責(zé)一個(gè) Job 生命周期內(nèi)的所有工作，類似老的框架中 JobTracker。但注意每一個(gè) Job（不是每一種）都有一個(gè) ApplicationMaster，它可以運(yùn)行在 ResourceManager 以外的機(jī)器上。

1.4Yarn 框架相對(duì)于老的 MapReduce 框架什么優(yōu)勢(shì)呢？

我們可以看到：

這個(gè)設(shè)計(jì)大大減小了 JobTracker（也就是現(xiàn)在的 ResourceManager）的資源消耗，并且讓監(jiān)測(cè)每一個(gè) Job 子任務(wù) (tasks) 狀態(tài)的程序分布式化了，更安全、更優(yōu)美。

在新的 Yarn 中，ApplicationMaster 是一個(gè)可變更的部分，用戶可以對(duì)不同的編程模型寫自己的 AppMst，讓更多類型的編程模型能夠跑在 Hadoop 集群中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。

對(duì)于資源的表示以內(nèi)存為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的占用 )，比之前以剩余 slot 數(shù)目更合理。

老的框架中，JobTracker 一個(gè)很大的負(fù)擔(dān)就是監(jiān)控 job 下的 tasks 的運(yùn)行狀況，現(xiàn)在，這個(gè)部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個(gè)模塊叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是監(jiān)測(cè) ApplicationMaster 的運(yùn)行狀況，如果出問題，會(huì)將其在其他機(jī)器上重啟。

Container 是 Yarn 為了將來作資源隔離而提出的一個(gè)框架。這一點(diǎn)應(yīng)該借鑒了 Mesos 的工作，目前是一個(gè)框架，僅僅提供 java 虛擬機(jī)內(nèi)存的隔離 ,hadoop 團(tuán)隊(duì)的設(shè)計(jì)思路應(yīng)該后續(xù)能支持更多的資源調(diào)度和控制 , 既然資源表示成內(nèi)存量，那就沒有了之前的 map slot/reduce slot 分開造成集群資源閑置的尷尬情況。

新的 Yarn 框架相對(duì)舊 MapRduce 框架而言，其配置文件 , 啟停腳本及全局變量等也發(fā)生了一些變化，主要的改變?nèi)缦拢?/p>

1.5配置文件

安裝完成后的Hadoop默認(rèn)配置就可以啟動(dòng)，但其工作于本地模式；為了模擬hadoop集群的工作環(huán)境，完成配置測(cè)試，MarReduce程序測(cè)試等工作，可以配置其在單臺(tái)主機(jī)模擬提供分布式的hadoop，即偽分布式。

hadoop的配置共有四種級(jí)別：集群、進(jìn)程、作業(yè)和單獨(dú)操作，前兩類由集群管理員負(fù)責(zé)配置，后面的兩類則屬于程序員的工作范疇。

hadoop的配置文件位于conf目錄中，其中的core-site.xml、mapred-site.xml和hdfs-site.xml三個(gè)配置文件最為關(guān)鍵。

core-site.xml用于配置hadoop集群的特性，它作用于全部進(jìn)程及客戶端。mapred-site.xml配置mapreduce集群的工作屬性。

hdfs-site.xml配置hdfs集群的工作屬性。

此三個(gè)文件均為XML格式，其每個(gè)屬性配置請(qǐng)求格式如下：

some.property.name

some-value

另外還有三個(gè)配置文件需要留意。hadoop-env.sh是Hadoop的多個(gè)腳本執(zhí)行時(shí)source的配置信息，其用于為Hadoop指定運(yùn)行時(shí)使用的JDK、各進(jìn)程的JDK屬性、PID文件及日志文件的保存目錄等。masters則用于指定輔助名稱節(jié)點(diǎn)(SecondaryNameNode)的主機(jī)名或主機(jī)地址，slaves用于指定各從服務(wù)器(TaskTracker或DataNode)的主機(jī)名或主機(jī)地址。對(duì)偽分布式的Hadoop集群來講，這些節(jié)點(diǎn)均為本機(jī)。