[[150760]]

Apache Hadoop 是最流行的大數(shù)據(jù)處理工具之一。它多年來被許多公司成功部署在生產(chǎn)中。盡管 Hadoop 被視為可靠的、可擴(kuò)展的、富有成本效益的解決方案，但大型開發(fā)人員社區(qū)仍在不斷改進(jìn)它。最終，2.0 版提供了多項(xiàng)革命性功能，其中包括 Yet Another Resource Negotiator (YARN)、HDFS Federation 和一個高度可用的 NameNode，它使得 Hadoop 集群更加高效、強(qiáng)大和可靠。在本文中，將對 YARN 與 Hadoop 中的分布式處理層的以前版本進(jìn)行比較，了解 YARN 所帶來的優(yōu)勢。

簡介

Apache Hadoop 2.0 包含 YARN，它將資源管理和處理組件分開。基于 YARN 的架構(gòu)不受 MapReduce 約束。本文將介紹 YARN，以及它相對于 Hadoop 中以前的分布式處理層的一些優(yōu)勢。本文將了解如何使用 YARN 的可伸縮性、效率和靈活性增強(qiáng)您的集群。

Apache Hadoop 簡介

Apache Hadoop 是一個開源軟件框架，可安裝在一個商用機(jī)器集群中，使機(jī)器可彼此通信并協(xié)同工作，以高度分布式的方式共同存儲和處理大量數(shù)據(jù)。最初，Hadoop 包含以下兩個主要組件：Hadoop Distributed File System (HDFS) 和一個分布式計(jì)算引擎，該引擎支持以 MapReduce 作業(yè)的形式實(shí)現(xiàn)和運(yùn)行程序。

MapReduce 是 Google 推廣的一個簡單的編程模型，它對以高度并行和可擴(kuò)展的方式處理大數(shù)據(jù)集很有用。MapReduce 的靈感來源于函數(shù)式編程，用戶可將他們的計(jì)算表達(dá)為 map 和 reduce 函數(shù)，將數(shù)據(jù)作為鍵值對來處理。Hadoop 提供了一個高級 API 來在各種語言中實(shí)現(xiàn)自定義的 map 和 reduce 函數(shù)。

Hadoop 還提供了軟件基礎(chǔ)架構(gòu)，以一系列 map 和 reduce 任務(wù)的形式運(yùn)行 MapReduce 作業(yè)。Map 任務(wù) 在輸入數(shù)據(jù)的子集上調(diào)用 map 函數(shù)。在完成這些調(diào)用后，reduce 任務(wù) 開始在 map 函數(shù)所生成的中間數(shù)據(jù)上調(diào)用 reduce 任務(wù)，生成最終的輸出。 map 和 reduce 任務(wù)彼此單獨(dú)運(yùn)行，這支持并行和容錯的計(jì)算。

最重要的是，Hadoop 基礎(chǔ)架構(gòu)負(fù)責(zé)處理分布式處理的所有復(fù)雜方面：并行化、調(diào)度、資源管理、機(jī)器間通信、軟件和硬件故障處理，等等。得益于這種干凈的抽象，實(shí)現(xiàn)處理數(shù)百（或者甚至數(shù)千）個機(jī)器上的數(shù) TB 數(shù)據(jù)的分布式應(yīng)用程序從未像現(xiàn)在這么容易過，甚至對于之前沒有使用分布式系統(tǒng)的經(jīng)驗(yàn)的開發(fā)人員也是如此。

Hadoop 的黃金時代

盡管 MapReduce 模型存在著多種開源實(shí)現(xiàn)，但 Hadoop MapReduce 很快就變得非常流行。Hadoop 也是全球最令人興奮的開源項(xiàng)目之一，它提供了多項(xiàng)出色的功能：高級 API、近線性的可伸縮性、開源許可、在商用硬件上運(yùn)行的能力，以及容錯。它已獲得數(shù)百（或許已達(dá)數(shù)千）個公司的成功部署，是大規(guī)模分布式存儲和處理的最新標(biāo)準(zhǔn)。

一些早期的 Hadoop 采用者，比如 Yahoo! 和 Facebook，構(gòu)建了包含 4,000 個節(jié)點(diǎn)的大型集群，以滿足不斷增長和變化的數(shù)據(jù)處理需求。但是，在構(gòu)建自己的集群后，他們開始注意到了 Hadoop MapReduce 框架的一些局限性。

經(jīng)典 MapReduce 的局限性

經(jīng)典 MapReduce 的最嚴(yán)重的限制主要關(guān)系到可伸縮性、資源利用和對與 MapReduce 不同的工作負(fù)載的支持。在 MapReduce 框架中，作業(yè)執(zhí)行受兩種類型的進(jìn)程控制：

一個稱為 JobTracker 的主要進(jìn)程，它協(xié)調(diào)在集群上運(yùn)行的所有作業(yè)，分配要在 TaskTracker 上運(yùn)行的 map 和 reduce 任務(wù)。

許多稱為 TaskTracker 的下級進(jìn)程，它們運(yùn)行分配的任務(wù)并定期向 JobTracker 報(bào)告進(jìn)度。

Apache Hadoop 的經(jīng)典版本 (MRv1)

該圖顯示了 Apache Hadoop 的經(jīng)典版本 (MRv1)

大型的 Hadoop 集群顯現(xiàn)出了由單個 JobTracker 導(dǎo)致的可伸縮性瓶頸。依據(jù) Yahoo!，在集群中有 5,000 個節(jié)點(diǎn)和 40,000 個任務(wù)同時運(yùn)行時，這樣一種設(shè)計(jì)實(shí)際上就會受到限制。由于此限制，必須創(chuàng)建和維護(hù)更小的、功能更差的集群。

此外，較小和較大的 Hadoop 集群都從未最高效地使用他們的計(jì)算資源。在 Hadoop MapReduce 中，每個從屬節(jié)點(diǎn)上的計(jì)算資源由集群管理員分解為固定數(shù)量的 map 和 reduce slot，這些 slot 不可替代。設(shè)定 map slot 和 reduce slot 的數(shù)量后，節(jié)點(diǎn)在任何時刻都不能運(yùn)行比 map slot 更多的 map 任務(wù)，即使沒有 reduce 任務(wù)在運(yùn)行。這影響了集群的利用率，因?yàn)樵谒?map slot 都被使用（而且我們還需要更多）時，我們無法使用任何 reduce slot，即使它們可用，反之亦然。

最后但同樣重要的是，Hadoop 設(shè)計(jì)為僅運(yùn)行 MapReduce 作業(yè)。隨著替代性的編程模型（比如 Apache Giraph 所提供的圖形處理）的到來，除 MapReduce 外，越來越需要為可通過高效的、公平的方式在同一個集群上運(yùn)行并共享資源的其他編程模型提供支持。

2010 年，Yahoo! 的工程師開始研究一種全新的 Hadoop 架構(gòu)，用這種架構(gòu)來解決上述所有限制并增加多種附加功能。

解決可伸縮性問題

在 Hadoop MapReduce 中，JobTracker 具有兩種不同的職責(zé)：

• 管理集群中的計(jì)算資源，這涉及到維護(hù)活動節(jié)點(diǎn)列表、可用和占用的 map 和 reduce slots 列表，以及依據(jù)所選的調(diào)度策略將可用 slots 分配給合適的作業(yè)和任務(wù)
• 協(xié)調(diào)在集群上運(yùn)行的所有任務(wù)，這涉及到指導(dǎo) TaskTracker 啟動 map 和 reduce 任務(wù)，監(jiān)視任務(wù)的執(zhí)行，重新啟動失敗的任務(wù)，推測性地運(yùn)行緩慢的任務(wù)，計(jì)算作業(yè)計(jì)數(shù)器值的總和，等等

為單個進(jìn)程安排大量職責(zé)會導(dǎo)致重大的可伸縮性問題，尤其是在較大的集群上，JobTracker 必須不斷跟蹤數(shù)千個 TaskTracker、數(shù)百個作業(yè)，以及數(shù)萬個 map 和 reduce 任務(wù)。下圖演示了這一問題。相反，TaskTracker 通常近運(yùn)行十來個任務(wù)，這些任務(wù)由勤勉的 JobTracker 分配給它們。

大型 Apache Hadoop 集群 (MRv1) 上繁忙的 JobTracker

該圖顯示了大型 Apache Hadoop 集群 (MRv1) 上繁忙的 JobTracker

為了解決可伸縮性問題，一個簡單而又絕妙的想法應(yīng)運(yùn)而生：我們減少了單個 JobTracker 的職責(zé)，將部分職責(zé)委派給 TaskTracker，因?yàn)榧褐杏性S多 TaskTracker。在新設(shè)計(jì)中，這個概念通過將 JobTracker 的雙重職責(zé)（集群資源管理和任務(wù)協(xié)調(diào)）分開為兩種不同類型的進(jìn)程來反映。

不再擁有單個 JobTracker，一種新方法引入了一個集群管理器，它惟一的職責(zé)就是跟蹤集群中的活動節(jié)點(diǎn)和可用資源，并將它們分配給任務(wù)。對于提交給集群的每個作業(yè)，會啟動一個專用的、短暫的 JobTracker 來控制該作業(yè)中的任務(wù)的執(zhí)行。有趣的是，短暫的 JobTracker 由在從屬節(jié)點(diǎn)上運(yùn)行的 TaskTracker 啟動。因此，作業(yè)的生命周期的協(xié)調(diào)工作分散在集群中所有可用的機(jī)器上。得益于這種行為，更多工作可并行運(yùn)行，可伸縮性得到了顯著提高。

ARN：下一代 Hadoop 計(jì)算平臺

我們現(xiàn)在稍微改變一下用辭。以下名稱的改動有助于更好地了解 YARN 的設(shè)計(jì)：

• ResourceManager 代替集群管理器
• ApplicationMaster 代替一個專用且短暫的 JobTracker
• NodeManager 代替 TaskTracker
• 一個分布式應(yīng)用程序代替一個 MapReduce 作業(yè)

YARN 是下一代 Hadoop 計(jì)算平臺，如下所示。

該圖顯示了 YARN 的架構(gòu)

在 YARN 架構(gòu)中，一個全局 ResourceManager 以主要后臺進(jìn)程的形式運(yùn)行，它通常在專用機(jī)器上運(yùn)行，在各種競爭的應(yīng)用程序之間仲裁可用的集群資源。ResourceManager 會追蹤集群中有多少可用的活動節(jié)點(diǎn)和資源，協(xié)調(diào)用戶提交的哪些應(yīng)用程序應(yīng)該在何時獲取這些資源。ResourceManager 是惟一擁有此信息的進(jìn)程，所以它可通過某種共享的、安全的、多租戶的方式制定分配（或者調(diào)度）決策（例如，依據(jù)應(yīng)用程序優(yōu)先級、隊(duì)列容量、ACLs、數(shù)據(jù)位置等）。

在用戶提交一個應(yīng)用程序時，一個稱為 ApplicationMaster 的輕量型進(jìn)程實(shí)例會啟動來協(xié)調(diào)應(yīng)用程序內(nèi)的所有任務(wù)的執(zhí)行。這包括監(jiān)視任務(wù)，重新啟動失敗的任務(wù)，推測性地運(yùn)行緩慢的任務(wù)，以及計(jì)算應(yīng)用程序計(jì)數(shù)器值的總和。這些職責(zé)以前分配給所有作業(yè)的單個 JobTracker。ApplicationMaster 和屬于它的應(yīng)用程序的任務(wù)，在受 NodeManager 控制的資源容器中運(yùn)行。

NodeManager 是 TaskTracker 的一種更加普通和高效的版本。沒有固定數(shù)量的 map 和 reduce slots，NodeManager 擁有許多動態(tài)創(chuàng)建的資源容器。容器的大小取決于它所包含的資源量，比如內(nèi)存、CPU、磁盤和網(wǎng)絡(luò) IO。目前，僅支持內(nèi)存和 CPU (YARN-3)。未來可使用 cgroups 來控制磁盤和網(wǎng)絡(luò) IO。一個節(jié)點(diǎn)上的容器數(shù)量，由配置參數(shù)與專用于從屬后臺進(jìn)程和操作系統(tǒng)的資源以外的節(jié)點(diǎn)資源總量（比如總 CPU 數(shù)和總內(nèi)存）共同決定。

有趣的是，ApplicationMaster 可在容器內(nèi)運(yùn)行任何類型的任務(wù)。例如，MapReduce ApplicationMaster 請求一個容器來啟動 map 或 reduce 任務(wù)，而 Giraph ApplicationMaster 請求一個容器來運(yùn)行 Giraph 任務(wù)。您還可以實(shí)現(xiàn)一個自定義的 ApplicationMaster 來運(yùn)行特定的任務(wù)，進(jìn)而發(fā)明出一種全新的分布式應(yīng)用程序框架，改變大數(shù)據(jù)世界的格局。您可以查閱 Apache Twill，它旨在簡化 YARN 之上的分布式應(yīng)用程序的編寫。

在 YARN 中，MapReduce 降級為一個分布式應(yīng)用程序的一個角色（但仍是一個非常流行且有用的角色），現(xiàn)在稱為 MRv2。MRv2 是經(jīng)典 MapReduce 引擎（現(xiàn)在稱為 MRv1）的重現(xiàn)，運(yùn)行在 YARN 之上。

一個可運(yùn)行任何分布式應(yīng)用程序的集群

ResourceManager、NodeManager 和容器都不關(guān)心應(yīng)用程序或任務(wù)的類型。所有特定于應(yīng)用程序框架的代碼都轉(zhuǎn)移到它的 ApplicationMaster，以便任何分布式框架都可以受 YARN 支持 — 只要有人為它實(shí)現(xiàn)了相應(yīng)的 ApplicationMaster。

得益于這個一般性的方法，Hadoop YARN 集群運(yùn)行許多不同工作負(fù)載的夢想才得以實(shí)現(xiàn)。想像一下：您數(shù)據(jù)中心中的一個 Hadoop 集群可運(yùn)行 MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI 等。

單一集群方法明顯提供了大量優(yōu)勢，其中包括：

• 更高的集群利用率，一個框架未使用的資源可由另一個框架使用
• 更低的操作成本，因?yàn)橹挥幸粋€ “包辦一切的” 集群需要管理和調(diào)節(jié)
• 更少的數(shù)據(jù)移動，無需在 Hadoop YARN 與在不同機(jī)器集群上運(yùn)行的系統(tǒng)之間移動數(shù)據(jù)

管理單個集群還會得到一個更環(huán)保的數(shù)據(jù)處理解決方案。使用的數(shù)據(jù)中心空間更少，浪費(fèi)的硅片更少，使用的電源更少，排放的碳更少，這只是因?yàn)槲覀冊诟〉咝У?Hadoop 集群上運(yùn)行同樣的計(jì)算。

YARN 中的應(yīng)用程序提交

本節(jié)討論在應(yīng)用程序提交到 YARN 集群時，ResourceManager、ApplicationMaster、NodeManagers 和容器如何相互交互。下圖顯示了一個例子。

YARN 中的應(yīng)用程序提交

假設(shè)用戶采用與 MRv1 中相同的方式鍵入 hadoop jar 命令，將應(yīng)用程序提交到 ResourceManager。ResourceManager 維護(hù)在集群上運(yùn)行的應(yīng)用程序列表，以及每個活動的 NodeManager 上的可用資源列表。ResourceManager 需要確定哪個應(yīng)用程序接下來應(yīng)該獲得一部分集群資源。該決策受到許多限制，比如隊(duì)列容量、ACL 和公平性。ResourceManager 使用一個可插拔的 Scheduler。Scheduler 僅執(zhí)行調(diào)度；它管理誰在何時獲取集群資源（以容器的形式），但不會對應(yīng)用程序內(nèi)的任務(wù)執(zhí)行任何監(jiān)視，所以它不會嘗試重新啟動失敗的任務(wù)。

在 ResourceManager 接受一個新應(yīng)用程序提交時，Scheduler 制定的第一個決策是選擇將用來運(yùn)行 ApplicationMaster 的容器。在 ApplicationMaster 啟動后，它將負(fù)責(zé)此應(yīng)用程序的整個生命周期。首先也是最重要的是，它將資源請求發(fā)送到 ResourceManager，請求運(yùn)行應(yīng)用程序的任務(wù)所需的容器。資源請求是對一些容器的請求，用以滿足一些資源需求，比如：

• 一定量的資源，目前使用 MB 內(nèi)存和 CPU 份額來表示
• 一個首選的位置，由主機(jī)名、機(jī)架名稱指定，或者使用 * 來表示沒有偏好
• 此應(yīng)用程序中的一個優(yōu)先級，而不是跨多個應(yīng)用程序

如果可能的話，ResourceManager 會分配一個滿足 ApplicationMaster 在資源請求中所請求的需求的容器（表達(dá)為容器 ID 和主機(jī)名）。該容器允許應(yīng)用程序使用特定主機(jī)上給定的資源量。分配一個容器后，ApplicationMaster 會要求 NodeManager（管理分配容器的主機(jī)）使用這些資源來啟動一個特定于應(yīng)用程序的任務(wù)。此任務(wù)可以是在任何框架中編寫的任何進(jìn)程（比如一個 MapReduce 任務(wù)或一個 Giraph 任務(wù)）。NodeManager 不會監(jiān)視任務(wù)；它僅監(jiān)視容器中的資源使用情況，舉例而言，如果一個容器消耗的內(nèi)存比最初分配的更多，它會結(jié)束該容器。

ApplicationMaster 會竭盡全力協(xié)調(diào)容器，啟動所有需要的任務(wù)來完成它的應(yīng)用程序。它還監(jiān)視應(yīng)用程序及其任務(wù)的進(jìn)度，在新請求的容器中重新啟動失敗的任務(wù)，以及向提交應(yīng)用程序的客戶端報(bào)告進(jìn)度。應(yīng)用程序完成后，ApplicationMaster 會關(guān)閉自己并釋放自己的容器。

盡管 ResourceManager 不會對應(yīng)用程序內(nèi)的任務(wù)執(zhí)行任何監(jiān)視，但它會檢查 ApplicationMaster 的健康狀況。如果 ApplicationMaster 失敗，ResourceManager 可在一個新容器中重新啟動它。您可以認(rèn)為 ResourceManager 負(fù)責(zé)管理 ApplicationMaster，而 ApplicationMasters 負(fù)責(zé)管理任務(wù)。

有趣的事實(shí)和特性

YARN 提供了多種其他的優(yōu)秀特性。介紹所有這些特性不屬于本文的范疇，我僅列出一些值得注意的特性：

• 如果作業(yè)足夠小，Uberization 支持在 ApplicationMaster 的 JVM 中運(yùn)行一個 MapReduce 作業(yè)的所有任務(wù)。這樣，您就可避免從 ResourceManager 請求容器以及要求 NodeManagers 啟動（可能很小的）任務(wù)的開銷。
• 與為 MRv1 編寫的 MapReduce 作業(yè)的二進(jìn)制或源代碼兼容性 (MAPREDUCE-5108)。
• 針對 ResourceManager 的高可用性 (YARN-149)。此工作正在進(jìn)行中，已由一些供應(yīng)商完成。
• 重新啟動 ResourceManager 后的應(yīng)用程序恢復(fù) (YARN-128)。ResourceManager 將正在運(yùn)行的應(yīng)用程序和已完成的任務(wù)的信息存儲在 HDFS 中。如果 ResourceManager 重新啟動，它會重新創(chuàng)建應(yīng)用程序的狀態(tài)，僅重新運(yùn)行不完整的任務(wù)。此工作已接近完成，社區(qū)正在積極測試。它已由一些供應(yīng)商完成。
• 簡化的用戶日志管理和訪問。應(yīng)用程序生成的日志不會留在各個從屬節(jié)點(diǎn)上（像 MRv1 一樣），而轉(zhuǎn)移到一個中央存儲區(qū)，比如 HDFS。在以后，它們可用于調(diào)試用途，或者用于歷史分析來發(fā)現(xiàn)性能問題。
• Web 界面的新外觀。

結(jié)束語

YARN 是一個完全重寫的 Hadoop 集群架構(gòu)。它似乎在商用機(jī)器集群上實(shí)現(xiàn)和執(zhí)行分布式應(yīng)用程序的方式上帶來了變革。

與第一版 Hadoop 中經(jīng)典的 MapReduce 引擎相比，YARN 在可伸縮性、效率和靈活性上提供了明顯的優(yōu)勢。小型和大型 Hadoop 集群都從 YARN 中受益匪淺。對于最終用戶（開發(fā)人員，而不是管理員），這些更改幾乎是不可見的，因?yàn)榭梢允褂孟嗤?MapReduce API 和 CLI 運(yùn)行未經(jīng)修改的 MapReduce 作業(yè)。

沒有理由不將 MRv1 遷移到 YARN。最大型的 Hadoop 供應(yīng)商都同意這一點(diǎn)，而且為 Hadoop YARN 的運(yùn)行提供了廣泛的支持。如今，YARN 已被許多公司成功應(yīng)用在生產(chǎn)中，比如 Yahoo!、eBay、Spotify、Xing、Allegro 等。