[[150760]]

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

簡介

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

Apache Hadoop 簡介

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

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

Hadoop 還提供了軟件基礎架構，以一系列 map 和 reduce 任務的形式運行 MapReduce 作業。Map 任務 在輸入數據的子集上調用 map 函數。在完成這些調用后，reduce 任務 開始在 map 函數所生成的中間數據上調用 reduce 任務，生成最終的輸出。 map 和 reduce 任務彼此單獨運行，這支持并行和容錯的計算。

最重要的是，Hadoop 基礎架構負責處理分布式處理的所有復雜方面：并行化、調度、資源管理、機器間通信、軟件和硬件故障處理，等等。得益于這種干凈的抽象，實現處理數百（或者甚至數千）個機器上的數 TB 數據的分布式應用程序從未像現在這么容易過，甚至對于之前沒有使用分布式系統的經驗的開發人員也是如此。

Hadoop 的黃金時代

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

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

經典 MapReduce 的局限性

經典 MapReduce 的最嚴重的限制主要關系到可伸縮性、資源利用和對與 MapReduce 不同的工作負載的支持。在 MapReduce 框架中，作業執行受兩種類型的進程控制：

一個稱為 JobTracker 的主要進程，它協調在集群上運行的所有作業，分配要在 TaskTracker 上運行的 map 和 reduce 任務。

許多稱為 TaskTracker 的下級進程，它們運行分配的任務并定期向 JobTracker 報告進度。

Apache Hadoop 的經典版本 (MRv1)

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

大型的 Hadoop 集群顯現出了由單個 JobTracker 導致的可伸縮性瓶頸。依據 Yahoo!，在集群中有 5,000 個節點和 40,000 個任務同時運行時，這樣一種設計實際上就會受到限制。由于此限制，必須創建和維護更小的、功能更差的集群。

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

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

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

解決可伸縮性問題

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

• 管理集群中的計算資源，這涉及到維護活動節點列表、可用和占用的 map 和 reduce slots 列表，以及依據所選的調度策略將可用 slots 分配給合適的作業和任務
• 協調在集群上運行的所有任務，這涉及到指導 TaskTracker 啟動 map 和 reduce 任務，監視任務的執行，重新啟動失敗的任務，推測性地運行緩慢的任務，計算作業計數器值的總和，等等

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

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

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

為了解決可伸縮性問題，一個簡單而又絕妙的想法應運而生：我們減少了單個 JobTracker 的職責，將部分職責委派給 TaskTracker，因為集群中有許多 TaskTracker。在新設計中，這個概念通過將 JobTracker 的雙重職責（集群資源管理和任務協調）分開為兩種不同類型的進程來反映。

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

ARN：下一代 Hadoop 計算平臺

我們現在稍微改變一下用辭。以下名稱的改動有助于更好地了解 YARN 的設計：

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

YARN 是下一代 Hadoop 計算平臺，如下所示。

該圖顯示了 YARN 的架構

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

在用戶提交一個應用程序時，一個稱為 ApplicationMaster 的輕量型進程實例會啟動來協調應用程序內的所有任務的執行。這包括監視任務，重新啟動失敗的任務，推測性地運行緩慢的任務，以及計算應用程序計數器值的總和。這些職責以前分配給所有作業的單個 JobTracker。ApplicationMaster 和屬于它的應用程序的任務，在受 NodeManager 控制的資源容器中運行。

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

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

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

一個可運行任何分布式應用程序的集群

ResourceManager、NodeManager 和容器都不關心應用程序或任務的類型。所有特定于應用程序框架的代碼都轉移到它的 ApplicationMaster，以便任何分布式框架都可以受 YARN 支持 — 只要有人為它實現了相應的 ApplicationMaster。

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

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

• 更高的集群利用率，一個框架未使用的資源可由另一個框架使用
• 更低的操作成本，因為只有一個 “包辦一切的” 集群需要管理和調節
• 更少的數據移動，無需在 Hadoop YARN 與在不同機器集群上運行的系統之間移動數據

管理單個集群還會得到一個更環保的數據處理解決方案。使用的數據中心空間更少，浪費的硅片更少，使用的電源更少，排放的碳更少，這只是因為我們在更小但更高效的 Hadoop 集群上運行同樣的計算。

YARN 中的應用程序提交

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

YARN 中的應用程序提交

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

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

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

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

ApplicationMaster 會竭盡全力協調容器，啟動所有需要的任務來完成它的應用程序。它還監視應用程序及其任務的進度，在新請求的容器中重新啟動失敗的任務，以及向提交應用程序的客戶端報告進度。應用程序完成后，ApplicationMaster 會關閉自己并釋放自己的容器。

盡管 ResourceManager 不會對應用程序內的任務執行任何監視，但它會檢查 ApplicationMaster 的健康狀況。如果 ApplicationMaster 失敗，ResourceManager 可在一個新容器中重新啟動它。您可以認為 ResourceManager 負責管理 ApplicationMaster，而 ApplicationMasters 負責管理任務。

有趣的事實和特性

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

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

結束語

YARN 是一個完全重寫的 Hadoop 集群架構。它似乎在商用機器集群上實現和執行分布式應用程序的方式上帶來了變革。

與第一版 Hadoop 中經典的 MapReduce 引擎相比，YARN 在可伸縮性、效率和靈活性上提供了明顯的優勢。小型和大型 Hadoop 集群都從 YARN 中受益匪淺。對于最終用戶（開發人員，而不是管理員），這些更改幾乎是不可見的，因為可以使用相同的 MapReduce API 和 CLI 運行未經修改的 MapReduce 作業。

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