一. Hadoop Yarn 是什么

在古老的 Hadoop1.0 中，MapReduce 的 JobTracker 負(fù)責(zé)了太多的工作，包括資源調(diào)度，管理眾多的 TaskTracker 等工作。這自然是不合理的，于是 Hadoop 在 1.0 到 2.0 的升級(jí)過程中，便將 JobTracker 的資源調(diào)度工作獨(dú)立了出來，而這一改動(dòng)，直接讓 Hadoop 成為大數(shù)據(jù)中最穩(wěn)固的那一塊基石，而這個(gè)獨(dú)立出來的資源管理框架，就是 Yarn 。

在詳細(xì)介紹 Yarn 之前，我們先簡單聊聊 Yarn ，Yarn 的全稱是 Yet Another Resource Negotiator，意思是“另一種資源調(diào)度器”，這種命名和“有間客棧”這種可謂是異曲同工之妙。這里多說一句，以前 Java 有一個(gè)項(xiàng)目編譯工具，叫做 Ant，他的命名也是類似的，叫做 “Another Neat Tool”的縮寫，翻譯過來是”另一種整理工具“。

既然都叫做資源調(diào)度器了，那么自然，它的功能也是負(fù)責(zé)資源管理和調(diào)度的，接下來，我們就深入到 Yarn 這個(gè)東西內(nèi)部一探究竟吧。

二. Yarn 架構(gòu)

我們主要圍繞上面這張圖展開，不過在介紹圖中內(nèi)容時(shí)，需要先了解 Yarn 中的 Container 的概念，然后會(huì)介紹圖中一個(gè)個(gè)組件，最后看看提交一個(gè)程序的流程。

2.1 Container

容器(Container)這個(gè)東西是 Yarn 對(duì)資源做的一層抽象。就像我們平時(shí)開發(fā)過程中，經(jīng)常需要對(duì)底層一些東西進(jìn)行封裝，只提供給上層一個(gè)調(diào)用接口一樣，Yarn 對(duì)資源的管理也是用到了這種思想。

如上所示，Yarn 將CPU核數(shù)，內(nèi)存這些計(jì)算資源都封裝成為一個(gè)個(gè)的容器(Container)。需要注意兩點(diǎn)：

• 容器由 NodeManager 啟動(dòng)和管理，并被它所監(jiān)控。
• 容器被 ResourceManager 進(jìn)行調(diào)度。

NodeManager 和 ResourceManager 這兩個(gè)組件會(huì)在下面講到。

2.2 三個(gè)主要組件

再看最上面的圖，我們能直觀發(fā)現(xiàn)的兩個(gè)主要的組件是 ResourceManager 和 NodeManager ，但其實(shí)還有一個(gè) ApplicationMaster 在圖中沒有直觀顯示。我們分別來看這三個(gè)組件。

ResourceManager

我們先來說說上圖中最中央的那個(gè) ResourceManager(RM)。從名字上我們就能知道這個(gè)組件是負(fù)責(zé)資源管理的，整個(gè)系統(tǒng)有且只有一個(gè) RM ，來負(fù)責(zé)資源的調(diào)度。它也包含了兩個(gè)主要的組件：定時(shí)調(diào)用器(Scheduler)以及應(yīng)用管理器(ApplicationManager)。

定時(shí)調(diào)度器(Scheduler)：從本質(zhì)上來說，定時(shí)調(diào)度器就是一種策略，或者說一種算法。當(dāng) Client 提交一個(gè)任務(wù)的時(shí)候，它會(huì)根據(jù)所需要的資源以及當(dāng)前集群的資源狀況進(jìn)行分配。注意，它只負(fù)責(zé)向應(yīng)用程序分配資源，并不做監(jiān)控以及應(yīng)用程序的狀態(tài)跟蹤。

應(yīng)用管理器(ApplicationManager)：同樣，聽名字就能大概知道它是干嘛的。應(yīng)用管理器就是負(fù)責(zé)管理 Client 用戶提交的應(yīng)用。上面不是說到定時(shí)調(diào)度器(Scheduler)不對(duì)用戶提交的程序監(jiān)控嘛，其實(shí)啊，監(jiān)控應(yīng)用的工作正是由應(yīng)用管理器(ApplicationManager)完成的。

ApplicationMaster

每當(dāng) Client 提交一個(gè) Application 時(shí)候，就會(huì)新建一個(gè) ApplicationMaster 。由這個(gè) ApplicationMaster 去與 ResourceManager 申請容器資源，獲得資源后會(huì)將要運(yùn)行的程序發(fā)送到容器上啟動(dòng)，然后進(jìn)行分布式計(jì)算。

這里可能有些難以理解，為什么是把運(yùn)行程序發(fā)送到容器上去運(yùn)行?如果以傳統(tǒng)的思路來看，是程序運(yùn)行著不動(dòng)，然后數(shù)據(jù)進(jìn)進(jìn)出出不停流轉(zhuǎn)。但當(dāng)數(shù)據(jù)量大的時(shí)候就沒法這么玩了，因?yàn)楹Ａ繑?shù)據(jù)移動(dòng)成本太大，時(shí)間太長。但是中國有一句老話山不過來，我就過去。大數(shù)據(jù)分布式計(jì)算就是這種思想，既然大數(shù)據(jù)難以移動(dòng)，那我就把容易移動(dòng)的應(yīng)用程序發(fā)布到各個(gè)節(jié)點(diǎn)進(jìn)行計(jì)算唄，這就是大數(shù)據(jù)分布式計(jì)算的思路。

NodeManager

NodeManager 是 ResourceManager 在每臺(tái)機(jī)器的上代理，負(fù)責(zé)容器的管理，并監(jiān)控他們的資源使用情況(cpu，內(nèi)存，磁盤及網(wǎng)絡(luò)等)，以及向 ResourceManager/Scheduler 提供這些資源使用報(bào)告。

三. 提交一個(gè) Application 到 Yarn 的流程

這張圖簡單地標(biāo)明了提交一個(gè)程序所經(jīng)歷的流程，接下來我們來具體說說每一步的過程。

Client 向 Yarn 提交 Application，這里我們假設(shè)是一個(gè) MapReduce 作業(yè)。

ResourceManager 向 NodeManager 通信，為該 Application 分配第一個(gè)容器。并在這個(gè)容器中運(yùn)行這個(gè)應(yīng)用程序?qū)?yīng)的 ApplicationMaster。

ApplicationMaster 啟動(dòng)以后，對(duì) 作業(yè)(也就是 Application) 進(jìn)行拆分，拆分 task 出來，這些 task 可以運(yùn)行在一個(gè)或多個(gè)容器中。然后向 ResourceManager 申請要運(yùn)行程序的容器，并定時(shí)向 ResourceManager 發(fā)送心跳。

申請到容器后，ApplicationMaster 會(huì)去和容器對(duì)應(yīng)的 NodeManager 通信，而后將作業(yè)分發(fā)到對(duì)應(yīng)的 NodeManager 中的容器去運(yùn)行，這里會(huì)將拆分后的 MapReduce 進(jìn)行分發(fā)，對(duì)應(yīng)容器中運(yùn)行的可能是 Map 任務(wù)，也可能是 Reduce 任務(wù)。

容器中運(yùn)行的任務(wù)會(huì)向 ApplicationMaster 發(fā)送心跳，匯報(bào)自身情況。當(dāng)程序運(yùn)行完成后， ApplicationMaster 再向 ResourceManager 注銷并釋放容器資源。

以上就是一個(gè)作業(yè)的大體運(yùn)行流程。

為什么會(huì)有 Yarn ?

上面說了這么多，最后我們來聊聊為什么會(huì)有 Yarn 吧。

直接的原因呢，就是因?yàn)?Hadoop1.0 中架構(gòu)的缺陷，在 MapReduce 中，jobTracker 擔(dān)負(fù)起了太多的責(zé)任了，接收任務(wù)是它，資源調(diào)度是它，監(jiān)控 TaskTracker 運(yùn)行情況還是它。這樣實(shí)現(xiàn)的好處是比較簡單，但相對(duì)的，就容易出現(xiàn)一些問題，比如常見的單點(diǎn)故障問題。

要解決這些問題，只能將 jobTracker 進(jìn)行拆分，將其中部分功能拆解出來。彼時(shí)業(yè)內(nèi)已經(jīng)有了一部分的資源管理框架，比如 mesos，于是照著這個(gè)思路，就開發(fā)出了 Yarn。這里多說個(gè)冷知識(shí)，其實(shí) Spark 早期是為了推廣 mesos 而產(chǎn)生的，這也是它名字的由來，不過后來反正是 Spark 火起來了。。。

閑話不多說，其實(shí) Hadoop 能有今天這個(gè)地位，Yarn 可以說是功不可沒。因?yàn)橛辛?Yarn ，更多計(jì)算框架可以接入到 Hdfs 中，而不單單是 MapReduce，到現(xiàn)在我們都知道，MapReduce 早已經(jīng)被 Spark 等計(jì)算框架趕超，而 Hdfs 卻依然屹立不倒。究其原因，正式因?yàn)?Yarn 的包容，使得其他計(jì)算框架能專注于計(jì)算性能的提升。Hdfs 可能不是最優(yōu)秀的大數(shù)據(jù)存儲(chǔ)系統(tǒng)，但卻是應(yīng)用最廣泛的大數(shù)據(jù)存儲(chǔ)系統(tǒng)，Yarn 功不可沒。