YARN 簡介

YARN 簡介

Adam Kawa
2014 年 12 月 18 日發佈

WeiboGoogle+用電子郵件發送本頁面

 

簡介

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)

大型的 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

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

再也不擁有單個 JobTracker，一種新方法引入了一個集羣管理器，它唯一的職責就是跟蹤集羣中的活動節點和可用資源，並將它們分配給任務。對於提交給集羣的每一個做業，會啓動一個專用的、短暫的 JobTracker 來控制該做業中的任務的執行。有趣的是，短暫的 JobTracker 由在從屬節點上運行的 TaskTracker 啓動。所以，做業的生命週期的協調工做分散在集羣中全部可用的機器上。得益於這種行爲，更多工做可並行運行，可伸縮性獲得了顯著提升。

YARN：下一代 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 等。

致謝

感謝 Piotr Krewski 和 Fabian Alenius 對本文進行技術審閱。