Apache Hadoop YARN：另一個資源協調者

摘要

Apache Hadoop[1]的最初設計重點關注於運行大規模的MapReduce作業以處理Web爬蟲。對於越來越多樣化的公司而言，Hadoop已成爲數據和計算的市場-共享和訪問數據及計算資源的實際場所。這種廣泛的應用和無處不在的使用使初始設計遠遠超出了預期的目標，從而暴露出兩個主要缺點：1）特定編程模型與資源管理基礎設施的緊密耦合，迫使開發人員濫用MapReduce編程模型，以及2）集中式作業控制流的處理，導致調度器無盡的擴展性問題。

在本文中，我們總結了下一代Hadoop計算平臺YARN的設計、開發和當前部署狀態。我們引入的新架構將編程模型與資源管理基礎架構分離開來，並將許多調度功能（例如任務容錯）委託給每個應用程序組件。我們提供實驗證據來證明我們所做的改進，通過報告在生產環境（包括100％的Yahoo!網格）上運行YARN的經驗來確認提高的效率，並通過討論將幾種編程框架移植到YARN上，如Dryad、Giraph、Hoya、Hadoop MapReduce、REEF、Spark、Storm和Tez，來確認靈活性要求。

1. 引言

Apache Hadoop最初是MapReduce[12]的許多開源實現之一，其重點是解決Web爬蟲索引所需的前所未有的規模。針對此用例對其執行架構進行了調整，重點是針對大量數據密集型計算的強大容錯能力。在許多大型Web公司和初創公司中，Hadoop集羣是存儲和處理操作數據的常見場所。

更重要的是，它成爲組織中工程師和研究人員可以即時且幾乎不受限制地訪問大量計算資源和公司數據庫的地方。這既是Hadoop成功的原因，也是最大的詛咒，因爲開發人員的羣體將MapReduce編程模型擴展到了集羣管理基礎之外。通用模式提交“僅map”作業以生成集羣中的任意進程。濫用的示例包括派生Web服務器和按組調度以進行迭代作業計算。爲了利用物理資源，開發人員通常採用聰明的解決方法來避開MapReduce API的限制。

這些限制和誤用激發了一大類的論文使用Hadoop作爲無關環境的基線。儘管許多論文都暴露了有關Hadoop架構或實現的實質性問題，但有些論文只是（或多或少地）譴責了這些濫用的一些副作用。到目前爲止，學術界和開源社區都已經很好地瞭解了原始Hadoop架構的侷限性。

在本文中，我們提出了一個社區驅動的工作，旨在使Hadoop超越其最初的化身。我們介紹了稱爲YARN的下一代Hadoop計算平臺，它脫離了其熟悉的整體式架構。通過將資源管理功能與編程模型分離，YARN將許多與調度相關的功能委託給每個作業組件。在此新的上下文中，MapReduce只是在YARN之上運行的應用程序之一。這種分離爲編程框架的選擇提供了很大的靈活性。在YARN上可用的替代編程模型的示例包括：Dryad[18]、Giraph、Hoya、REEF[10]、Spark[32]、Storm[4]和Tez[2]。在YARN上運行的編程框架根據需要協調應用程序內部通信、執行流程和動態優化，從而顯著提高了性能。我們從早期架構師和實現者的角度描述YARN的起源、設計、開源開發和部署。

2. 歷史和基本原理

在本節中，我們描述YARN的需求是如何從現實需要應運而生的起源概述。歡迎對需求的起源不感興趣的讀者掠過本節（爲方便起見，需求進行粗體顯示），然後繼續閱讀第3節，我們將對YARN的體系結構進行簡要描述。

Yahoo!在2006年採用Apache Hadoop取代了驅動其WebMap應用[11]的基礎架構，該技術可構建已知網絡的圖來驅動其搜索引擎。當時，該網絡圖包含超過1000億個節點和1萬億條邊。先前的基礎架構名爲“Dreadnaught”[25]已達到800臺機器的可擴展性極限，並且需要對架構進行重大調整以適應Web的發展速度。Dreadnaught已經執行過的分佈式應用程序類似於MapReduce[12]程序，因此通過採用可擴展性更高的MapReduce框架，可以輕鬆遷移搜索流水線的重要部分。這突顯了在整個Hadoop早期版本中始終存在的第一要求，一直到YARN-[R1：]可擴展性。

除了Yahoo!的超大型流水線外， 搜索、優化廣告分析、垃圾郵件過濾和內容優化的科學家推動了許多早期需求。隨着Apache Hadoop社區擴展平臺以處理越來越大的MapReduce作業，圍繞**[R2：]多租戶**的需求開始形成。在這種情況下，可以最好地理解計算平臺的工程優先級和中間階段。YARN的架構基於MapReduce平臺不斷髮展的經驗，可以滿足許多長期的要求。在本文的其餘部分，我們將假設您對傳統Hadoop架構有基本瞭解，附錄A中提供了其簡要概述。

2.1 專用集羣的時代

Hadoop最早的一些用戶會在少數幾個節點上建立集羣，將其數據加載到Hadoop分佈式文件系統（HDFS）[27]，通過編寫MapReduce作業來獲得他們感興趣的結果，接着將其拉取下來[15]。隨着Hadoop的容錯能力的提高，持久化HDFS集羣已成爲常態。在Yahoo!，操作者會將“有趣”的數據集加載到共享集羣中，從而吸引了對從中獲取洞察感興趣的科學家。儘管大規模計算仍是開發的主要驅動力，但HDFS還獲得了權限模型、配額和其他功能，以改善其多租戶操作。

爲了解決一些多租戶問題，Yahoo!開發並部署了Hadoop on Demand（HoD），它使用Torque[7]和Maui[20]在共享的硬件池上分配Hadoop集羣。用戶可以提交他們的帶有大小適當的計算集羣描述的作業給Torque，然後Torque會對其排隊，直到有足夠的節點可用爲止。一旦節點可用，Torque將在頭節點上啓動HoD的“領導者”進程，該進程然後與Torque/Maui交互以啓動HoD的從屬進程，隨後爲該用戶生成JobTracker和TaskTrackers，然後接受一系列作業。當用戶釋放集羣時，系統將自動收集用戶的日誌，並將節點返回到共享池。由於HoD爲每個作業都設置了一個新的集羣，因此用戶可以（稍微）運行舊版本的Hadoop，並且開發人員可以輕鬆地測試新功能。自Hadoop每三個月發佈一次主要修訂以來，HoD的靈活性對於保持這種節奏至關重要 - 我們將升級依賴關係的這種脫鉤稱爲**[R3：]可維護性**。

儘管HoD也可以部署HDFS集羣，但大多數用戶都在共享的HDFS實例中部署了計算節點。隨着HDFS的擴展，可以在其之上分配更多的計算集羣，從而在更多數據集上形成增加用戶密度的良性循環，從而帶來新的洞察。由於大多數Hadoop集羣都小於Yahoo!上最大的HoD作業，因此JobTracker很少成爲瓶頸。

HoD證明了自己是一個通用平臺，可以預見Mesos[17]的某些特性，它將擴展主框架模型以支持在並行的各種編程模型之間進行動態資源分配。在沒有任何隔離和安全性方面的情況下，HoD也可以被視爲EC2 Elastic MapReduce和Azure HDInsight產品的私有云前身。

2.2 Hadoop on Demand的缺點

Yahoo!由於資源利用率中等，最終退休了HoD，轉而使用共享MapReduce集羣。在map階段，JobTracker會盡一切努力將任務放置在HDFS中靠近其輸入數據的位置，最好放在存儲該數據副本的節點上。由於Torque分配節點時不考慮位置，因此授予用戶JobTracker的節點子集可能只包含少數相關副本。考慮到大量的小作業，大多數讀取來自遠程主機。抑制這些舊特性的努力取得了好壞參半的結果；雖然跨機架分佈TaskTracker使得在機架內讀取共享數據集的可能性更高，但map任務和reduce任務之間的記錄shuffle必然會跨越機架，並且DAG中的後續作業將很少有機會解決其祖先的傾斜。[R4：]位置感知是YARN的重點要求。

諸如Pig[24]和Hive[30]之類的高級框架通常在DAG中組成MapReduce作業的工作流，它們在計算的每個階段都對數據進行過濾、彙總和預測。由於在使用HoD時，集羣的大小在作業之間沒有調整，因此在隨後的更小階段完成後，集羣中的大部分容量都處於閒置狀態。在一種極端但非常常見的情況下，在一個節點上運行單個reduce任務可能會阻止回收集羣。在此狀態下，一些作業使數百個節點處於空閒狀態。

最後，作業等待時間主要由分配集羣所花費的時間決定。用戶在估計他們的作業需要多少個節點時僅能依靠試探法，並且經常會要求數十倍的資源來滿足他們的直覺。集羣分配延遲是如此之高，用戶通常會與同事共享期待已久的集羣，將節點的保留時間延長到比預期更長的時間，從而進一步增加了延遲。儘管用戶喜歡HoD的許多功能，但集羣利用的經濟性迫使Yahoo!將其用戶打包到共享集羣中。[R5：]高集羣利用率是YARN的頭等大事。

2.3 共享集羣

最終，HoD的信息太少，無法對其分配做出明智的決策，其資源粒度太粗糙，並且其API迫使用戶向資源層提供誤導性約束。

但是，遷移到共享集羣並非易事。儘管數年間HDFS規模逐步擴大，但JobTracker卻被HoD隔離。刪除該防護後，MapReduce集羣突然變得很大，作業吞吐量急劇增加，並且無辜添加到JobTracker中的許多功能成爲了關鍵漏洞的源頭。更糟糕的是，雖然JobTracker故障沒有丟失一個作業流，但是造成了宕機，該宕機將丟失集羣中所有正在運行的作業，並要求用戶手動恢復其作業流。

宕機時間在處理流水線中造成作業積壓，重新啓動後將給JobTracker造成很大壓力。重新啓動通常涉及手動終止用戶的作業，直到集羣恢復。重新啓動通常涉及手動終止用戶的作業，直到集羣恢復。 由於爲每個作業存儲了複雜的狀態，因此從未完全調試過在重啓後保留作業的實現。

操作大型的多租戶Hadoop集羣非常困難。儘管容錯是設計的核心原則，但暴露給用戶應用程序的面卻很廣闊。考慮到單點故障暴露出的各種可用性問題，至關重要的是連續監視集羣中的工作負載以查找功能失常的作業。更爲巧妙的是，由於JobTracker需要爲其初始化的每個作業分配跟蹤結構，因此其允許控制邏輯包括保護其自身可用性的保障措施；這可能會延遲爲作業分配空閒集羣資源，因爲跟蹤作業的開銷可能使JobTracker進程不堪重負。所有這些關注點都可以歸類爲**[R6：]可靠性/可用性**。

隨着Hadoop管理更多的租戶、多樣化的用例和原始數據，其隔離要求變得更加嚴格，但是授權模型缺乏強大的可擴展身份驗證，這是多租戶集羣的一項關鍵功能。已添加並反向移植到多個版本。[R7：]安全且可審覈的操作必須在YARN中保留。開發人員逐漸強化了系統，以適應對資源的多樣化需求，這與面向插槽的資源視圖不同。

雖然MapReduce支持廣泛的用例，但它並不是所有大規模計算的理想模型。例如，許多機器學習程序需要對數據集進行多次迭代才能收斂到結果。如果將這一流程作爲一系列MapReduce作業進行組合，則調度開銷將顯著延遲結果[32]。類似地，許多圖算法可以使用批量同步並行模型（BSP）更好地表達，該模型使用消息傳遞在頂點之間進行通信，而不是在容錯的大規模MapReduce作業[22]中使用繁重的多對多的通信屏障。這種不匹配成爲阻礙用戶工作效率的障礙，但是Hadoop中以MapReduce爲中心的資源模型不允許使用任何競爭性應用程序模型。Hadoop在Yahoo!內部的廣泛部署和其數據流水線的慣性使這些緊張關係變得無法解決。這沒有阻礙用戶編寫“MapReduce”程序來生成替代框架。對於調度器，它們表現爲具有完全不同的資源曲線的純map作業，從而阻礙了內置在平臺中的假設，並導致利用率低下、潛在的死鎖和不穩定。YARN必須與用戶宣佈停戰，並提供顯式**[R8：]編程模型多樣性支持**。

除了與新興的框架要求不匹配外，類型化插槽還會損害利用率。雖然map和reduce的地位之間的隔離可防止死鎖，但它也可能成爲資源瓶頸。在Hadoop中，用戶爲每個提交的作業配置兩個階段之間的重疊。稍後開始執行的reduce任務可以增加集羣的吞吐量，而在作業執行的提早啓動它們可以減少其延遲。map和reduce槽位的數量由集羣操作員確定，因此空閒map容量不能用於生成reduce任務，反之亦然。由於這兩種任務類型以不同的速率完成，因此不能完美平衡配置。當任一插槽類型變得飽和時，可能都需要JobTracker對作業初始化施加反壓，從而形成典型的流水線氣泡。可替代的資源使調度複雜化，但是它們也使分配器能夠更緊密地打包集羣。這突出顯示了對**[R9：]靈活的資源模型**的需求。

與HoD相比，向共享集羣的遷移提高了利用率和本地性，這也大大減輕了人們對可維護性和可用性的擔憂。在共享集羣中部署新版本的Apache Hadoop是需要精心籌劃的，這是一件令人頭痛的常見事件。要修復MapReduce實現中的一個錯誤，操作者必須安排停機時間、關閉集羣、部署新位、驗證升級、然後接受新作業。通過將負責仲裁資源使用情況的平臺與表達該程序的框架相結合，人們被迫同時開發它們；當操作者提高平臺的分配效率時，用戶必須合併框架變更。因此，升級集羣要求用戶停止、驗證和恢復其流水線以進行無關聯改變。儘管更新通常只需要重新編譯，但用戶對內部框架詳細信息的假設或開發人員對用戶程序的假設有時會在網格上運行的流水線上造成阻塞的不兼容性。

基於不斷髮展的Apache Hadoop MapReduce的經驗教訓，YARN旨在滿足需求（R1-R9）。但是，MapReduce應用程序的龐大安裝基數、相關項目的生態系統、陳舊的部署實踐以及緊耦合的調試都無法忍受激進的重新設計。爲了避免陷入“第二系統症候羣” [6]，新架構儘可能重用了現有框架中的代碼，表現出熟悉的模式，並在規劃中留下了許多推測性的特性。這導致對YARN重新設計的最後要求：[R10：]向後兼容性。

在本文的其餘部分，我們將對YARN的體系結構進行說明（第3節），並報告有關YARN在現實世界中的採用情況（第4節），並提供實驗證據來驗證一些關鍵的體系結構決策（第5節），最後通過將YARN與一些相關工作進行比較來得出結論（第6節）。

3. 架構

爲了滿足我們在第2節中討論的需求，YARN將一些功能提升到負責資源管理的平臺層，而將邏輯執行計劃的協調留給了許多框架實現。具體來說，每個集羣的ResourceManager（RM）跟蹤資源使用情況和節點活躍性，強制分配不變性以及仲裁租戶之間的爭用。通過在JobTracker的章程中劃分這些職責，中央分配器可以對租戶要求進行抽象描述，而不用瞭解每個分配的語義。將該職責委派給ApplicationMaster（AM），該應用程序通過從RM請求資源，從其接收的資源中生成物理計劃並協調故障的執行來協調單個作業的邏輯計劃。

3.1 概述

RM在專用計算機上作爲守護程序運行，並充當在集羣中各種競爭應用程序之間仲裁資源的中央機構。考慮到集羣資源的集中和全局視圖，它可以在租戶之間強制執行豐富、熟悉的特性，例如公平性[R10]、容量[R10]和本地性[R4]。根據應用程序需求、調度優先級和資源可用性，RM爲應用程序動態分配租約（稱爲容器）以在特定節點上運行。容器是綁定到特定節點[R4，R9]上的邏輯資源束（例如，2GB RAM，1 CPU）。爲了執行和跟蹤此類分配，RM與運行在稱爲NodeManager（NM）的每個節點上的特殊系統守護程序進行交互。RM和NM之間的通信基於心跳，以實現可擴展性。NM負責監視資源可用性，報告故障和容器生命週期管理（例如，啓動和終止）。RM從這些NM狀態快照中組裝其全局視圖。

作業通過公共提交協議提交給RM，並進入准入控制階段，在此階段中，將驗證安全憑證並執行各種操作和管理檢查[R7]。接受的作業將傳遞到調度器以運行。一旦調度器擁有足夠的資源，應用程序就會從接受狀態轉移到運行狀態。除了內部記賬之外，這還涉及爲AM分配一個容器並將其生成在集羣中的某個節點上。在RM重新啓動或失敗的情況下，將接受的應用程序的記錄寫入持久化存儲並進行恢復。

ApplicationMaster是作業的“負責人”，管理生命週期的各個方面，包括動態增加和減少資源消耗、管理執行流程（例如，針對map輸出運行reducer）、處理故障和計算傾斜以及執行其他本地性優化。實際上，AM可以運行任意用戶代碼，並且可以用任何編程語言編寫，因爲與RM和NM的所有通信均使用可擴展的通信協議進行編碼 - 例如，請考慮我們在4.2節中討論的Dryad端口。YARN對AM所做的假設很少，儘管在實踐中我們預期大多數作業將使用更高級別的編程框架（例如MapReduce、Dryad、Tez和REEF等）。通過將所有這些功能委託給AM，YARN的體系結構獲得了很大的可擴展性[R1]、編程模型靈活性[R8]和改進了升級/測試[R3]流程（因爲同一框架的多個版本可以共存）。

通常，AM將需要利用多個節點上可用的資源（CPU，RAM，磁盤等）來完成一項工作。爲了獲得容器，AM向RM發出資源請求。這些請求的形式包括位置偏好和容器屬性的規範。RM將根據可用性和調度策略嘗試滿足來自每個應用程序的資源請求。當爲AM分配資源時，RM會爲資源生成一個租約，並由後續的AM心跳拉動。當AM將容器租約提供給NM[R4]時，基於令牌的安全機制將保證其真實性。一旦ApplicationMaster發現某個容器可供使用，它將使用租約對特定於應用程序的啓動請求進行編碼。在MapReduce中，容器中運行的代碼是map任務或reduce任務。如果需要，運行中的容器可以通過特定於應用程序的協議直接與AM通信，以報告狀態和活躍性並接收特定於框架的命令 - YARN既不提倡也不反對這種通信。總體而言，YARN部署爲生命週期管理和容器監控提供了一個基本而強大的基礎框架，而每個框架都管理着特定於應用程序的語義[R3，R8]。

本節總結了YARN的體系結構概述。在本節的其餘部分，我們將提供每個主要組件的詳細信息。

3.2 Resource Manager (RM)

ResourceManager暴露了兩個公共接口：1）客戶端提交應用程序，和2）ApplicationMaster動態協商獲取資源，以及一個面向NodeManagers的內部接口，用於集羣監控和資源訪問管理。在下文中，我們將重點介紹RM和AM之間的公共協議，因爲這最能代表YARN平臺與其上運行的各種應用程序/框架之間的重要邊界。

RM將集羣狀態的全局模型與正在運行的應用程序報告的資源需求摘要進行匹配。這樣就可以嚴格執行全局調度屬性（YARN中不同的調度器專注於不同的全局屬性，例如容量或公平性），但是它要求調度器對應用程序的資源需求有準確的瞭解。通信消息和調度器狀態必須緊湊高效，以使RM能夠根據應用程序需求和集羣的大小進行擴展[R1]。捕獲資源請求的方式在捕獲資源需求的準確性和緊湊性之間取得了平衡。幸運的是，調度器僅處理每個應用程序的整體資源配置文件，而忽略了本地優化和內部應用程序流。YARN完全從map和reduce資源的靜態劃分出發；它將集羣資源視爲（離散的）連續體[R9] - 正如我們將在4.1節中看到的，這極大地提高了集羣利用率。

ApplicationMasters通過一個或多個ResourceRequests來編纂對資源的需求，每個ResourceRequests跟蹤：

1. 容器數量（例如200個容器），
2. 每個容器的資源<2GB RAM，1 CPU>，
3. 位置偏好，以及
4. 應用程序中請求的優先級

ResourceRequests旨在允許用戶捕獲其需求的完整細節和/或需求的彙總信息（例如，可以指定節點級別，機架級別和全局位置偏好[R4]）。這允許將更統一的請求緊湊地表示爲合集。此外，這種設計將允許我們對ResourceRequests施加大小限制，從而利用ResourceRequests的彙總特性作爲應用程序偏好的有損壓縮。這使得調度器可以高效地進行此類請求的通信和存儲，並且允許應用程序清楚地表達其需求[R1，R5，R9]。這些請求的彙總性質還指導調度器（如果無法實現完美的本地性）選擇好的備選項（例如，如果所需節點繁忙，則進行機架本地分配）。

該資源模型可以在同類環境中很好地爲當前應用程序提供服務，但是我們希望隨着生態系統的成熟和新要求的出現，它會隨着時間的推移而發展。最新和發展中的擴展包括：明確跟蹤組計劃需求、以及軟/硬約束來表達任意相同位置或不相交位置的放置分配。

調度器使用推薦的NM心跳來通告可用資源以跟蹤、更新和滿足這些請求。作爲對AM請求的響應，RM生成容器和令牌，這些令牌授予對資源的訪問權限。RM將NM所報告的已完成容器的退出狀態轉發給負責的AM。當新的NM加入集羣時，也會通知AM，以便它們可以開始在新節點上請求資源。

該協議的最新擴展允許RM對稱地從應用程序請求資源。這通常在集羣資源變得稀缺並且調度器決定撤消分配給應用程序以維護調度不變性的某些資源時發生。我們使用類似於ResourceRequests的結構來捕獲位置偏好（可以是嚴格的或可以協商的）。AM在滿足此類“搶佔”請求時具有一定的靈活性，例如，通過產生對其工作而言不太重要的容器（例如，到目前爲止進展不大的任務）、檢查任務狀態或遷移計算到其他正在運行的容器。總體而言，與強制殺死容器以滿足資源約束的平臺相比，這允許應用程序保留工作。如果應用程序是非協商的，則RM在等待一定時間後，可以通過指示NM強制終止容器來獲取所需的資源。

對於第2節中的預先提出的要求，重要的是指出ResourceManager不負責什麼。如所討論的，它不負責協調應用程序執行或任務容錯，但不負責1）提供運行應用程序的狀態或指標（現在是ApplicationMaster的一部分），也不負責2）提供已完成作業的框架特定報告（現在已委派給每個框架的守護程序）。這與ResourceManager僅應處理實時資源調度的觀點相一致並有助於YARN中的中央組件擴展到Hadoop 1.0 JobTracker以外。

3.3 Application Master (AM)

應用程序可以是一組靜態進程、對作業的邏輯描述、甚至是長期運行的服務。ApplicationMaster是協調集羣中應用程序執行的進程，但它本身就像其他容器一樣在集羣中運行。RM的組件協商獲取容器以生成此引導進程。

AM會定期向RM發出心跳，以確認其活躍性並更新其需求記錄。在建立其需求模型之後，AM在向RM的心跳消息中編碼其偏好和約束。爲響應隨後的心跳，AM將在綁定到集羣中特定節點的資源束上收到容器租約。根據從RM收到的容器，AM可以更新其執行計劃，以適應得知到的資源的豐富或稀缺。與某些資源模型相反，對應用程序的分配是後期綁定：產生的進程不是綁定到請求，而是綁定到租約。導致AM發出請求的條件在它收到其資源時可能不會保持爲真，但是容器的語義是可替代的且框架相關的[R3，R8，R10]。AM還將更新其向RM請求的資源，因爲它收到的容器會影響其當前和將來的需求。

作爲說明，MapReduce AM針對具有相同資源需求的map任務之間的本地性進行了優化。在HDFS上運行時，每個輸入數據塊都在k臺計算機上覆制。AM收到容器後，會將其與待處理的map任務集進行匹配，選擇輸入數據靠近容器的任務。如果AM決定在容器中運行map任務mi，那麼存儲mi輸入數據副本的主機就不那麼吸引人了。AM將更新其請求以減少其他k-1個主機的權重。主機之間的關係對於RM仍然是不透明的；同樣，如果mi失敗，則AM負責更新其需求以進行補償。對於MapReduce，請注意，Hadoop JobTracker提供的某些服務（例如RPC上的作業進度、狀態的Web界面、對MapReduce特定的歷史數據的訪問）不再是YARN體系結構的一部分。這些服務由ApplicationMaster或框架守護程序提供。

由於RM不解釋容器狀態，因此通過RM，AM確定NM報告的容器退出狀態的成功或失敗的語義。由於AM本身是在不可靠的硬件集羣中運行的容器，因此它應該要能夠抵抗故障。YARN爲恢復提供了一些支持，但是由於容錯能力和應用程序語義如此緊密地交織在一起，因此許多負擔都落在了AM上。我們將在3.6節中討論容錯模型。

3.4 Node Manager (NM)

NodeManager是YARN中的“工作者”守護程序。它對容器租約進行身份驗證、管理容器的依賴關係、監視其執行情況併爲容器提供一系列服務。操作者對其進行配置，以報告該節點上可用並分配給YARN的內存、CPU和其他資源。向RM註冊後，NM會通過心跳發送其狀態並接收指示。

YARN中的所有容器（包括AM）都由容器啓動上下文（CLC）來描述。該記錄包括環境變量映射、可遠程訪問的存儲中存儲的依賴關係、安全令牌、NM服務的有效負載以及創建進程所需的命令。驗證租約[R7]的真實性後，NM爲容器配置環境，包括使用租約中指定的資源約束初始化其監視子系統。爲了啓動容器，NM將所有必需的依賴項（數據文件、可執行文件、壓縮文件）複製到本地存儲中。如果需要，CLC還包括用於認證下載的憑據。根據CLC中的指定，可以在應用程序中的容器之間、由同一租戶啓動的容器之間、甚至在租戶之間共享依賴關係。NM最終會垃圾收集運行容器未使用的依賴項。

NM也將按照RM或AM的指令殺死容器。當RM報告其擁有的應用程序已完成、當調度器決定將其移交給其他租戶時，或者當NM檢測到容器超出其租約限制時（R2，R3，R7），容器可能會被殺死。AM可能會在不再需要相應作業時要求殺死容器。每當容器退出時，NM都會清理本地存儲中的工作目錄。應用程序完成後，其容器所擁有的所有資源都會在所有節點上被丟棄，包括仍在集羣中運行的所有進程。

NM還定期監視物理節點的運行狀況。它監視本地磁盤的任何問題，並頻繁運行由管理員配置的腳本，該腳本反過來又可以指向任何硬件/軟件問題。發現此類問題後，NM將其狀態更改爲不健康，並報告RM大致相同的狀態，然後做出調度器相關的決定，以終止該節點上的容器和/或停止將來的分配，直到解決健康問題爲止。

除上述內容外，NM還爲該節點上運行的容器提供本地服務。例如，當前的實現包括一個日誌聚合服務，該服務將在應用程序完成後將應用程序寫入stdout和stderr的數據上載到HDFS。

最後，管理員可以使用一組可插拔的輔助服務來配置NM。退出容器後，將清理容器的本地存儲，但允許提倡保留一些輸出，直到應用程序退出。以這種方式，進程可以產生在容器的壽命之外持續存在的數據，以由節點來管理。這些服務的一個重要用例是Hadoop MapReduce應用程序，使用輔助服務爲其在map和reduce任務之間傳輸中間數據。如前所述，CLC允許AM將有效負載尋址到輔助服務；MapReduce應用程序使用此通道來傳遞令牌，及用來對reduce任務訪問shuffle服務進行身份驗證。

3.5 YARN框架/應用程序寫入者

從前面對核心體系結構的描述中，我們提取了YARN應用程序寫入者的職責：

1. 通過將ApplicationMaster的CLC傳遞給RM來提交應用程序。
2. RM啓動AM時，AM應向RM註冊並定期通過心跳協議通告其活躍性和需求。
3. RM分配容器後，AM可以構造CLC以在相應的NM上啓動容器。它還可以監視正在運行的容器的狀態，並在應回收資源時將其停止。監控容器內部作業的進度完全由AM負責。
4. AM完成工作後，應從RM中註銷並乾淨地退出。
5. 使用框架的開發者可以選擇在他們自己的客戶端之間添加控制流，以報告作業狀態並暴露控制界面。

即使是簡單的AM也可能相當複雜；一個具有少數功能的分佈式shell示例是超過450行Java代碼。存在簡化YARN應用程序開發的框架，我們將在4.2節中探討其中的一些框架。客戶端庫 - YarnClient、NMClient、AMRMClient - 與YARN一起提供，並暴露了更高級別的API，以避免針對低級別協議進行編碼。針對故障（包括自身故障）進行加強的AM並非易事。如果應用程序暴露服務或連接通信圖，則它還負責其安全操作的所有方面；YARN僅保護其部署。

3.6 容錯能力和可用性

從一開始，Hadoop就被設計爲在商業硬件上運行。通過在其堆棧的每一層中建立容錯能力，它隱藏了檢測和從用戶的硬件故障中恢復的複雜性。YARN繼承了這一理念，儘管現在責任已分配到集羣中運行的ResourceManager和ApplicationMaster之間。

在撰寫本文時，RM仍是YARN體系結構中的單點故障。通過在初始化時從持久性存儲中恢復其狀態，RM可以從自身故障中恢復。恢復過程完成後，它將殺死集羣中正在運行的所有容器，包括活躍的ApplicationMaster。然後，它啓動每個AM的新實例。如果該框架支持恢復（並且大多數情況下都是爲了常規容錯），則該平臺將自動恢復用戶的流水線[R6]。正在爲AM添加更多協議支持以使AM能在RM重新啓動時存活。這樣，AM可以在RM關閉時繼續使用現有容器進行處理，並可以在RM恢復後與RM重新同步。通過被動/主動故障恢復RM到備用節點，來解決YARN集羣的高可用性。

當NM發生故障時，RM會通過其心跳響應超時來對其進行檢測，將在該節點上運行的所有容器標記爲已殺死，然後將故障報告給所有正在運行的AM。如果故障是暫時的，則NM將與RM重新同步，清除其本地狀態，然後繼續。在這兩種情況下，AM都會對節點故障做出反應，有可能重做故障期間該節點上運行的任何容器所做的工作。

由於AM在集羣中運行，因此其故障不會影響集羣[R6，R8]的可用性，但是由於AM故障而導致應用程序出現故障的可能性高於Hadoop1.x。如果AM失敗，則RM可能會重啓AM，儘管平臺不支持恢復AM狀態。重新啓動的AM與自己正在運行的容器進行同步也不是該平臺關注的問題。例如，Hadoop MapReduce AM將恢復其已完成的任務，但是在撰寫本文時，正在運行的任務以及AM恢復期間完成的任務將被終止並重新運行。

最後，容器本身的故障處理完全留給框架。RM收集來自NM的所有容器退出事件，並在心跳響應中將其傳播到相應的AM。MapReduce ApplicationMaster已經偵聽這些通知，並通過從RM請求新容器來重試map或reduce任務。

這樣，我們就結束了對體系結構的介紹，並深入研究了YARN的實際安裝部署。

4. 現實中的YARN

我們知道一些大型公司正在積極使用YARN。以下報告了我們在Yahoo!上運行YARN的經驗。然後，我們接着討論一些已移植到YARN的流行框架。

4.1 Yahoo!上的YARN

Yahoo!將生產網格從傳統Hadoop的穩定分支之一升級到YARN。我們在下文中報告的統計數據是關於傳統Hadoop升級前的最後30天以及從升級時間（每個網格不同）到2013年6月13日的平均統計數據。在解釋以下統計數據時，請注意以下重要事項：我們將要呈現的結果來自大型集羣的實際升級經驗，該集羣的重點是保持關鍵共享資源的可用性，而不是像典型的合成實驗那樣注重科學的可重複性/一致性。爲了幫助讀者輕鬆地解釋結果，我們將報告一些全局統計數據，然後重點介紹在升級前後硬件（大部分）沒有變化的大型網格，最後確定該特定網格上的工作負載轉移特性。

4.1.1 所有集羣上的YARN

總之，升級後，YARN在所有集羣中每天處理約500000個作業，每天總計超過230個計算年。底層存儲超過350 PB。

YARN的最初目標之一是提高可擴展性，而Yahoo!報告表示它們運行的集羣不超過4000個節點，這些節點曾經是YARN之前最大的集羣。YARN帶來的資源利用率的顯著提高增加了每個網格可以維持的作業數量。這完全消除了當前進一步擴展的需要，甚至使運營團隊能夠延遲重新配置已停用的7000多個節點。

另一方面，YARN的日誌聚合組件似乎增加了對HDFS NameNode的壓力，尤其是對於大型作業。現在估計NameNode是Yahoo!集羣中的可擴展性的瓶頸。幸運的是，社區中正在進行大量工作，以通過優化YARN日誌聚合來提高NameNode的吞吐量並減輕NameNode的壓力。在具有大量小型應用程序的幾個大型集羣中，已觀察到YARN中的可擴展性問題，但是心跳處理方面的最新改進已緩解了其中一些問題。

4.1.2 某個特定集羣的統計信息

現在，我們將重點介紹Yahoo!網格運營團隊在一個特定的2500節點網格上運行YARN的經驗和統計數據。

圖2顯示了之前/之後，運營團隊可以輕鬆地在2500個機器集羣上運行的負載。這是Yahoo!上最繁忙的集羣一直被逼近極限。在圖2a中，我們顯示正在運行的作業數量顯著增加：從Hadoop 1.0版本上的約77k增長到YARN上的約10萬個定時作業。此外，這個集羣達到每天125K作業持續吞吐量，其峯值在每天約15萬作業（或幾乎兩倍於此集羣以前的舒適區的作業數量）。平均作業大小從58個map，20個reducer增加到85個map，16個reducer - 請注意，這些作業包括用戶作業以及系統應用程序產生的其他微小作業，例如通過distcp，Oozie[19]等進行數據複製/傳輸數據，以及其他數據管理框架。同樣，所有作業的任務數量從Hadoop 1.0上的4M增加到YARN上的平均約1000萬，持續負載約爲1200萬，峯值約爲1500萬 - 見圖2。

評估集羣管理系統效率的另一個關鍵指標是平均資源利用率。同樣，工作負載的變化使我們將要討論的統計信息在直接比較中的用處不大，但是我們發現CPU利用率（通過彙總所有計量的CPU時間併除以計量的節點正常運行時間進行計算。）顯著增加。在Hadoop 1.0上，評估的CPU使用率徘徊在2500臺計算機上的320％或3.2/16個核上。從本質上講，轉移到YARN時，CPU利用率幾乎翻了一番，相當於每次6個連續綁定的核，最高峯值爲10個完全利用的核。總體而言，這表明YARN能夠完全佔用約2.8 * 2500 = 7000個核來完全忙於運行用戶代碼。這與我們上面討論的集羣上運行的作業和任務數量的增加是一致的。可以部分解釋這些改進的最重要的體系結構差異之一就是消除了map和reduce槽之間的靜態拆分。

在圖3中，我們繪製了一段時間內的幾個作業統計信息：併發運行的和掛起的容器，已提交的、已完成的、正在運行的和待處理的作業。這顯示了資源管理器處理大量應用程序、容器請求和執行的能力。此集羣中使用的CapacityScheduler版本尚未使用搶佔功能，因爲這是最近添加的功能。儘管尚未對搶佔進行大規模測試，但我們認爲謹慎使用搶佔將顯著提高集羣利用率，但我們在5.3節中顯示了一個簡單的微基準測試。

爲了進一步表徵在此集羣上運行的工作負載的特性，我們在圖4中顯示了不同大小的應用程序的直方圖，該直方圖描繪了：1）每個存儲桶中的應用程序總數，2）該存儲桶中的應用程序使用的CPU總數 ，以及3）該存儲桶中應用程序使用的容器總數。正如過去觀察到的那樣，儘管大量應用程序非常小，但它們只佔集羣容量的一小部分（在這2500臺計算機集羣中，大約價值3.5核CPU每臺機器）。有趣的是，如果比較插槽利用率與CPU利用率，我們會發現大型作業似乎爲每個容器使用更多的CPU。這與更好地調整大型作業（例如，一致地使用壓縮）以及可能運行更長的任務相一致，從而分攤了啓動開銷。

總體而言，Yahoo!報告指出，爲將YARN加強爲可用於生產的可擴展系統而進行的工程工作非常值得。計劃繼續升級到最新版本2.1-beta，以保持快速發展勢頭。經過積累了36000年計算時間和數月的生產壓力測試，Yahoo的運營團隊證實YARN的架構轉變對他們的工作負載非常有利。在下面的引號中對此進行了很好的總結：“升級到YARN相當於增加1000臺機器[到目前爲止2500臺機器的集羣]”。

4.2 應用程序和框架

YARN的關鍵要求是使編程模型具有更大的靈活性。儘管YARN在撰寫本文時爲Beta版本，但它已經被YARN吸引的許多編程框架所證實。我們簡要總結了YARN原生的或移植到平臺上的一些項目，以說明其體系結構的通用性。

Apache Hadoop MapReduce已經可以在YARN上使用幾乎相同的功能集。它已進行了大規模測試，對生態系統中其他項目（如Pig、Hive、Oozie等）進行了修改，使其可以在YARN之上的MR之上工作，並具有與傳統Hadoop相比處於同等或更好水平的基準測試。MapReduce社區已確保針對1.x編寫的應用程序可以以完全二進制兼容的方式（mapred的API）或僅通過重新編譯（mapreduce API的源碼兼容性）在YARN上運行。

Apache Tez是一個Apache項目（在撰寫本文時爲Incubator），旨在提供通用的有向無環圖（DAG）執行框架。其目標之一是提供一組構建基塊，這些構建基塊可以組合成任意DAG（包括一個簡單的2階段（Map和Reduce）DAG，以保持與MapReduce的兼容性）。Tez爲諸如Hive和Pig的查詢執行系統提供了更爲自然的執行計劃模型，以免強制將這些計劃轉換爲MapReduce。當前的重點是加快複雜的Hive和Pig查詢，這些查詢通常需要多個MapReduce作業，從而可以作爲單個Tez作業運行。將來，將考慮更豐富的功能，例如對交互式查詢和通用DAG的一般支持。

Spark是來自加州大學伯克利分校[32]的開源研究項目，目標是機器學習和交互式查詢工作負載。針對此類應用程序，利用彈性分佈式數據集（RDD）的中心思想可以實現比傳統MapReduce顯著改進的性能。Spark最近已被移植到YARN[?]。

Dryad[18]將DAG作爲執行流的抽象，並且已與LINQ[31]集成在一起。移植到YARN的版本是100％原生C ++和C＃用於工作者節點，而ApplicationMaster利用一薄層Java與原生Dryad圖形管理器的ResourceManager進行對接。最終，Java層將被與協議緩衝區接口的直接交互所取代。YARN上的Dryad與其非YARN版本完全兼容。

Giraph是一個高度可擴展的、以頂點爲中心的圖形計算框架。它最初設計爲在Hadoop 1.0之上運行，僅作爲Map作業，在該作業中的一個map是特殊的並且充當協調者。移植到YARN的Giraph是很自然的，執行協調者的角色是由ApplicationMaster承擔，並動態請求資源。

Storm是一個開源的分佈式實時處理引擎，旨在跨集羣機器擴展並提供並行流處理。一個常見的用例是將Storm用於在線計算，並將MapReduce用作批處理程序。通過將Storm移植到YARN上，可以釋放資源分配的極大靈活性。此外，對底層HDFS存儲層的共享訪問簡化了多框架工作負載的設計。

REEF元數據框架：YARN的靈活性在於對應用程序實現者的巨大投入。編寫ApplicationMaster並處理容錯、執行流程、協調等所有方面都是重大的努力。REEF項目[10]認識到了這一點，並排除了許多應用程序通用的一些難以構建的組件。這包括存儲管理、高速緩存、故障檢測、檢查點、基於推送的控制流程（實驗稍後展示）和容器再利用。框架設計人員可以在REEF之上構建，比直接在YARN上構建更容易，並且可以重用REEF提供的許多常見服務/庫。REEF設計使其適用於MapReduce和DAG之類的執行以及迭代和交互式計算。

Hoya是一種Java工具，旨在利用YARN按需啓動動態HBase集羣[21]。在YARN上運行的HBase集羣也可以動態增長和收縮（在我們的測試集羣中，可以在不到20秒的時間內添加/刪除RegionServer）。儘管仍在探索YARN中混合服務和批處理工作負載的啓示，但該項目的早期結果令人鼓舞。

5. 實驗

在上一節中，我們通過報告大型生產部署和繁榮的框架生態系統建立了YARN在現實世界中的成功。在本節中，我們將提供更具體的實驗結果，以證明YARN的一些成功。

5.1 打破排序記錄

在撰寫本文時，YARN上的MapReduce實現正式持有Daytona和Indy GraySort基準測試記錄，排序爲1.42TB/min。同一系統也報告了（競賽之外）在一分鐘內排序1.61TB和1.50TB的MinuteSort成績，優於現有的記錄。實驗在2100個節點上運行，每個節點配備了兩個2.3Ghz hexcore Xeon E5-2630、64 GB內存和12x3TB磁盤。下表提供了結果摘要：

完整報告[16]提供了實驗的詳細說明。

5.2 MapReduce基準測試

MapReduce仍然是YARN上最重要和最常用的應用程序。我們很高興地報告，與當前穩定的Hadoop-1發佈版本1.2.1相比，大多數標準Hadoop基準測試在Hadoop 2.1.0中的YARN上表現更好。下面提供了將1.2.1與2.1.0進行比較的260節點集羣上MapReduce基準測試的摘要。每個從節點都運行總計16核的2.27GHz Intel Xeon CPU，具有38GB物理內存和6x1TB 7200 RPM磁盤，每個磁盤均使用ext3文件系統格式。每個節點的網絡帶寬爲1Gb/s。每個節點運行一個DataNode和一個NodeManager，併爲容器分配了24GB RAM。我們在1.2.1中運行6個map和3個reduce，並在2.1.0中運行9個容器。每個map佔用包含1.5GB JVM堆的2GB的總內存，而每個reduce佔用包含3GB堆的4GB的總內存。JobTracker/ResourceManager運行在專用計算機上，HDFS NameNode也運行在專用計算機上。

我們將這些基準測試的結果解釋如下。排序基準測試使用默認設置來衡量HDFS中1.52TB（每個節點6GB）排序的端到端時間。混洗基準測試可以僅使用合成數據校準將m個map的中間輸出混洗爲n個reduce的速度；記錄都不是從HDFS讀取或寫入。雖然排序基準測試通常可以從HDFS數據路徑的改進中受益，但兩個基準測試在YARN上的性能都更好，這主要是由於MapReduce運行時本身的重大改進：map端排序的改進，reduce客戶端流水線式的批量輸出，和基於Netty[3]的服務器端混洗。掃描和DFSIO作業是用於評估在Hadoop MapReduce下運行的HDFS和其他分佈式文件系統的規範基準；表1中的結果是我們實驗中可歸因於HDFS的效果的粗略度量。我們對集羣的訪問時間太短，無法調試和表徵2.1.0文件系統的中等性能。儘管有這種噪音，即使YARN的設計針對多租戶吞吐量進行了優化，但其單項作業的性能也可與中央協調器相競爭。

AM可擴展性基準測試通過使AM充滿容器簿記職責來衡量單作業的魯棒性。表1包括對MapReduce AM的兩次測量。第一個實驗是限制可用資源以匹配1.x部署的插槽可用性。當我們取消此人爲限制並允許YARN使用整個節點時，其性能將大大提高。這兩個實驗測量了類型化插槽的開銷。我們還將性能提高歸因於更頻繁的節點心跳和更快的調度週期，我們將在下面對此進行詳細討論。由於YARN主要負責分發和啓動應用程序，因此我們將可擴展性基準測試視爲一項關鍵指標。

我們在生產集羣中觀察到的針對YARN的瓶頸中的一些體系結構選擇。如2.3節所述，類型化插槽會在節點上的可替代資源供應與執行Hadoop MapReduce任務的語義之間造成人爲的不匹配，從而損害吞吐量。雖然第4.1節介紹了總體工作負載的收益，但我們看到即使調度單個作業也有好處。我們將此收益的大部分歸因於改進的心跳處理。在Hadoop-1中，由於JobTracker中的粗粒度鎖，每個節點在大型集羣中只能每30-40秒進行一次心跳。儘管有巧妙的解決方法來降低延遲，例如用於處理輕量級更新的短路路徑和用於加速重要通知的自適應延遲，但JobTracker中的協調狀態仍然是大型集羣中延遲的主要原因。相反，NodeManager會每1-3秒發送一次心跳。RM代碼具有更高的可擴展性，而且它也解決了每個請求的一系列限制。

5.3 搶佔的好處

在圖5中，我們展示了YARN中最近添加的功能：使用保留工作的搶佔來執行全局屬性的能力。我們在一個小型（10臺計算機）集羣上進行了實驗，以強調保留工作的搶佔的潛在影響。集羣運行CapacityScheduler，配置了兩個隊列A和B，分別擁有80％和20％的容量。一個MapReduce作業在較小的隊列B中提交，幾分鐘後另一個MapReduce作業在較大的隊列A中提交。在圖中，我們顯示了在三種配置下分配給每個隊列的容量：1）沒有給其超出保證提供容量（固定容量）的隊列；2）隊列可能消耗集羣容量的100％，但不執行搶佔；3）隊列可能消耗集羣容量的100％，但容器可能被搶佔。保留工作的搶佔使調度器可以過量使用隊列B的資源，而不必擔心隊列A中的應用程序處於飢餓狀態。當隊列A中的應用程序請求資源時，調度器會發出搶佔請求，這些請求由ApplicationMaster通過其任務的檢查點並生成容器來進行服務。與情況(2)容量重新平衡大約需要20分鐘的情況相反，這允許隊列A在幾秒鐘內獲得其所有保證的容量（集羣的80％）。最後，由於我們使用的搶佔是基於檢查點的，並且不會浪費工作，因此在B中運行的作業可以從中斷的位置重新啓動任務，這樣可以高效地進行工作。

5.4 Apache Tez的改進

當在運行於Apache Tez上的Apache Hive中運行決策支持查詢時，我們提供了一些基本的改進（在撰寫本文時，是在早期階段進行集成）。從TPC-DS基準測試[23]進行的查詢涉及的聯接、過濾器和分組彙總很少。即使經過積極的計劃級別優化，Hive在使用MapReduce時也會生成由多個作業組成的執行計劃。針對Tez執行時，相同的查詢會導致線性DAG，具有單個Map階段，然後是多個Reduce階段。在20個節點的集羣上使用MapReduce時，針對200比例因子數據的查詢執行時間爲54秒，而使用Tez時，查詢執行時間則縮短爲31秒。這種節省的大部分可歸因於多個MapReduce作業的調度和啓動開銷，並避免了將中間MapReduce作業的輸出持久保存到HDFS的不必要步驟。

5.5 REEF：會話的低延遲

YARN的關鍵方面之一是，它使建立在其上的框架能夠按需管理容器和通信。我們通過利用REEF提供的容器重用和基於推送的通信的概念來展示這一點。該實驗基於一個基於REEF的簡單分佈式外殼應用程序。提交一系列Unix命令（例如，date）時，我們會在完全空閒的集羣上測量客戶端的延遲。發出的第一個命令會招致調度應用程序和獲取容器的全部開銷，而隨後的命令會通過客戶端和ApplicationMaster快速轉發到已經運行的容器中以執行。基於推送的消息傳遞進一步減少了延遲。我們實驗中的加速非常可觀，接近三個數量級 - 從超過12秒到平均31ms。

6. 相關工作

其他人已經意識到傳統Hadoop架構中的相同侷限性，並同時開發了替代解決方案，可以與YARN進行比較。與YARN最相似的衆多努力包括：Mesos[17]、Omega[26]、Corona[14]和Cosmos[8]，分別由Twitter、Google、Facebook和Microsoft維護和使用。

這些系統具有共同的靈感，並且有改善可擴展性、延遲和編程模型靈活性的高級目標。許多架構差異反映了不同的設計優先級，有時甚至是不同歷史背景的影響。雖然無法提供真正的定量比較，但我們將嘗試強調一些體系結構差異以及我們對其基本原理的理解。

Omega的設計更傾向於分佈式多層次調度。這反映了對可擴展性的更多關注，但使執行諸如容量/公平性/截止期限之類的全局屬性變得更加困難。爲了實現這一目標，作者似乎依賴於各種框架的協調開發，以及這些框架在運行時會相互尊重。對於像Google這樣的封閉世界來說，這是明智的選擇，但對於像Hadoop這樣的開放平臺則不可行，在Hadoop中，來自不同獨立來源的任意框架共享同一集羣。

與YARN和其他框架中基於心跳的控制面板框架方法相反，Corona使用基於推送的通信。延遲/可擴展性的折衷是重大的，應該進行詳細的比較。

儘管Mesos和YARN都有兩個層級的調度器，但是有兩個非常重要的區別。首先，Mesos是基於供給的資源管理器，而YARN是基於請求的方法。YARN允許AM根據包括位置在內的各種標準來請求資源，允許請求者根據給出的內容和當前使用情況更改將來的請求。我們的方法對於支持基於位置的分配是必要的。其次，Mesos不是用每個作業的框架內調度器，而是利用了中央調度器池（例如，傳統的Hadoop或MPI）。YARN支持將容器後期綁定到任務，每個任務都可以執行本地優化，並且似乎更適合滾動升級（因爲每個任務都可以在框架的不同版本上運行）。另一方面，每個作業的ApplicationMaster可能比Mesos的方法導致更大的開銷。

Cosmos在存儲和計算層方面在架構上與Hadoop 2.0非常相似，主要區別在於沒有中央資源管理器。但是，它似乎只用於一種應用程序類型：Scope[8]。由於目標範圍更窄，Cosmos可以利用許多優化功能，例如本地壓縮，索引文件，數據集分區的協同定位，以加快Scope的速度。多個應用程序框架的行爲尚不清楚。

在這些最近的努力以前，在資源管理和調度方面有悠久的歷史 - Condor[29]、Torque[7]、Moab[13]和Maui[20]。我們早期的Hadoop集羣使用了其中一些系統，但是我們發現它們無法以最好的方式支持MapReduce模型。具體來說，既不能表示數據本地性，又不能表示map和reduce階段的彈性調度需求，因此被迫分配附帶第2.1節中討論的使用成本的“虛擬”Hadoop。其中的某些問題可能是由於以下事實造成的：許多此類分佈式調度器最初都是爲支持MPI樣式和HPC應用程序模型並運行粗粒度的非彈性工作負載而創建的。這些集羣調度器的確允許客戶端指定處理環境的類型，但不幸的是，本地化限制不是Hadoop的主要問題。

另一類相關技術來自雲基礎架構領域，例如EC2、Azure、Eucalyptus和VMWare的產品。這些主要針對集羣的基於VM的共享，並且通常是爲長時間運行的進程而設計的（因爲VM引導時間的開銷太高了）。

7. 結論

在本文中，我們總結了對Hadoop歷史的回顧，並討論了胡亂使用及新型應用程序如何使初始架構遠遠超出了其設計要實現的範圍。然後，我們描述了導致YARN的漸近但意義深遠的體系結構轉變。由於資源管理和編程框架之間的脫鉤，YARN提供了：1）更好的可擴展性，2）更高的效率，以及3）使大量不同的框架有效地共享集羣。這些要求在實驗上（通過基準測試）和通過展示Yahoo!的大規模生產經驗都得到了證實，而Yahoo!的集羣現已100％在YARN上運行。最後，我們通過提供社區活動的快照並簡要報告已移植到YARN的許多框架，試圖捕獲圍繞該平臺的大量令人興奮的事物。我們相信YARN既可以作爲堅實的生產框架，也可以作爲研究社區的寶貴運動場。

8. 致謝

我們通過承認YARN體系的血統開始了YARN的闡述。多年來，它對所有開發、操作、測試、支持、記錄、宣傳、資助、尤其是所有使用過的Apache Hadoop的人的債務都是無法估量的。最後，我們認識到一些。Ram Marti和Jitendranath Panday影響了其安全性設計。Dick King，Krishna Ramachandran，Luke Lu，Alejandro Abdelnur，Shenjiejie，Omkar Vinit Joshi，Jian He爲實現工作做出了或將繼續做出重大貢獻。Karam Singh，Ramya Sunil，Rajesh Balamohan和Srigurunath Chakravarthi一直在測試和性能基準測試方面提供很大幫助。Rajive Chittajallu和Koji Noguchi分別從運營和用戶支持的角度幫助引導需求和洞察力。我們感謝Yahoo!通過大量貢獻和大量使用來支持YARN，還共享其一些集羣的統計信息。我們感謝Dennis Fetterly和Sergiy Matusevych提供了有關Dryad和REEF的一些實驗結果，以及Mayank Bansal幫助提供了2.1.0 MapReduce基準測試。最後但並非最不重要的一點是，Apache Hadoop YARN仍然是一個社區驅動的開源項目，其成功很大程度上要歸功於Apache Hadoop YARN和MapReduce社區 - 在此感謝所有以各種方式幫助YARN的參與者和提交者。

附錄A. 傳統Hadoop

在YARN之前，Hadoop MapReduce集羣由一個稱爲JobTracker（JT）的主節點和運行TaskTracker（TT）的工作節點組成。用戶向JT提交了MapReduce作業，JT協調了各個TT中的任務執行。TT由操作者配置，具有固定數量的map插槽和reduce插槽。TT會定期向JT發送心跳，以報告該節點上正在運行的任務的狀態並確認其活躍性。在心跳中，JT會更新與該節點上運行的任務相對應的狀態，代表該作業執行操作（例如，調度失敗的任務以重新執行），將該節點上的空閒時隙與調度器不變量進行匹配，在可用資源上匹配符合條件的作業，偏向於在有本地數據的節點上執行任務。

作爲計算集羣的中央仲裁者，JT還負責准入控制、跟蹤TT的活動性（以重新執行正在運行的或輸出不可用的任務）、以推測執行方式啓動任務以繞過路由到的慢節點、通過Web服務器向用戶報告作業狀態、記錄審覈日誌和彙總統計信息、驗證用戶身份以及其他許多功能；這些都限制了它的可擴展性。

參考文獻

1. Apache hadoop. http://hadoop.apache.org.
2. Apache tez. http://incubator.apache.org/projects/tez.html.
3. Netty project. http://netty.io.
4. Storm. http://storm-project.net/.
5. H. Ballani, P. Costa, T. Karagiannis, and A. I. Rowstron. Towards predictable datacenter networks. In SIGCOMM, volume 11, pages 242–253, 2011.
6. F. P. Brooks, Jr. The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.
7. N. Capit, G. Da Costa, Y. Georgiou, G. Huard, C. Martin, G. Mounie, P. Neyron, and O. Richard. A batch scheduler with high level components. In Cluster Computing and the Grid, 2005. CCGrid 2005. IEEE International Symposium on, volume 2, pages 776–783 Vol. 2, 2005.
8. R. Chaiken, B. Jenkins, P.-A. Larson, B. Ramsey, D. Shakib, S.Weaver, and J. Zhou. Scope: easy and efficient parallel processing of massive data sets. Proc. VLDB Endow., 1(2):1265–1276, Aug. 2008.
9. M. Chowdhury, M. Zaharia, J. Ma, M. I. Jordan, and I. Stoica. Managing data transfers in computer clusters with orchestra. SIGCOMMComputer Communication Review, 41(4):98, 2011.
10. B.-G. Chun, T. Condie, C. Curino, R. Ramakrishnan, R. Sears, and M. Weimer. Reef: Retainable evaluator execution framework. In VLDB 2013, Demo, 2013.
11. B. F. Cooper, E. Baldeschwieler, R. Fonseca, J. J. Kistler, P. Narayan, C. Neerdaels, T. Negrin, R. Ramakrishnan, A. Silberstein, U. Srivastava, et al. Building a cloud for Yahoo! IEEE Data Eng. Bull., 32(1):36–43, 2009.
12. J. Dean and S. Ghemawat. MapReduce: simplified data processing on large clusters. Commun. ACM, 51(1):107–113, Jan. 2008.
13. W. Emeneker, D. Jackson, J. Butikofer, and D. Stanzione. Dynamic virtual clustering with xen and moab. In G. Min, B. Martino, L. Yang, M. Guo, and G. Rnger, editors, Frontiers of High Performance Computing and Networking, ISPA 2006 Workshops, volume 4331 of Lecture Notes in Computer Science, pages 440–451. Springer Berlin Heidelberg, 2006.
14. Facebook Engineering Team. Under the Hood: Scheduling MapReduce jobs more efficiently with Corona. http://on.fb.me/TxUsYN, 2012.
15. D. Gottfrid. Self-service prorated super-computing fun. http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun, 2007.
16. T. Graves. GraySort and MinuteSort at Yahoo on Hadoop 0.23. http://sortbenchmark.org/Yahoo2013Sort.pdf, 2013.
17. B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. D. Joseph, R. Katz, S. Shenker, and I. Stoica. Mesos: a platform for fine-grained resource sharing in the data center. In Proceedings of the 8th USENIX conference on Networked systems design and implementation, NSDI’11, pages 22–22, Berkeley, CA, USA, 2011. USENIX Association.
18. M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly. Dryad: distributed data-parallel programs from sequential building blocks. In Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007, EuroSys ’07, pages 59–72, New York, NY, USA, 2007. ACM.
19. M. Islam, A. K. Huang, M. Battisha, M. Chiang, S. Srinivasan, C. Peters, A. Neumann, and A. Abdelnur. Oozie: towards a scalable workflow management system for hadoop. In Proceedings of the 1st ACM SIGMOD Workshop on Scalable Workflow Execution Engines and Technologies, page 4. ACM, 2012.
20. D. B. Jackson, Q. Snell, and M. J. Clement. Core algorithms of the maui scheduler. In Revised Papers from the 7th International Workshop on Job Scheduling Strategies for Parallel Processing, JSSPP ’01, pages 87–102, London, UK, UK, 2001. Springer-Verlag.
21. S. Loughran, D. Das, and E. Baldeschwieler. Introducing Hoya – HBase on YARN. http://hortonworks.com/blog/introducing-hoya-hbase-on-yarn/, 2013.
22. G. Malewicz, M. H. Austern, A. J. Bik, J. C. Dehnert, I. Horn, N. Leiser, and G. Czajkowski. Pregel: a system for large-scale graph processing. In Proceedings of the 2010 ACM SIGMOD International Conference on Management of data, SIGMOD’10, pages 135–146, New York, NY, USA, 2010. ACM.
23. R. O. Nambiar and M. Poess. The making of tpcds. In Proceedings of the 32nd international conference on Very large data bases, VLDB ’06, pages 1049–1058. VLDB Endowment, 2006.
24. C. Olston, B. Reed, U. Srivastava, R. Kumar, and A. Tomkins. Pig Latin: a not-so-foreign language for data processing. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data, SIGMOD ’08, pages 1099–1110, New York, NY, USA, 2008. ACM.
25. O. O’Malley. Hadoop: The Definitive Guide, chapter Hadoop at Yahoo!, pages 11–12. O’Reilly Media, 2012.
26. M. Schwarzkopf, A. Konwinski, M. Abd-El-Malek, and J. Wilkes. Omega: flexible, scalable schedulers for large compute clusters. In Proceedings of the 8th ACM European Conference on Computer Systems, EuroSys ’13, pages 351–364, New York, NY, USA, 2013. ACM.
27. K. Shvachko, H. Kuang, S. Radia, and R. Chansler. The Hadoop Distributed File System. In Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), MSST’10, pages 1–10, Washington, DC, USA, 2010. IEEE Computer Society.
28. T.-W. N. Sze. The two quadrillionth bit of p is 0! http://developer.yahoo.com/blogs/hadoop/twoquadrillionth-bit-0-467.html.
29. D. Thain, T. Tannenbaum, and M. Livny. Distributed computing in practice: the Condor experience. Concurrency and Computation: Practice and Experience, 17(2-4):323–356, 2005.
30. A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka, N. Z. 0002, S. Anthony, H. Liu, and R. Murthy. Hive - a petabyte scale data warehouse using Hadoop. In F. Li, M. M. Moro, S. Ghandeharizadeh, J. R. Haritsa, G. Weikum, M. J. Carey, F. Casati, E. Y. Chang, I. Manolescu, S. Mehrotra, U. Dayal, and V. J. Tsotras, editors, Proceedings of the 26th International Conference on Data Engineering, ICDE 2010, March 1-6, 2010, Long Beach, California, USA, pages 996–1005. IEEE, 2010.
31. Y. Yu, M. Isard, D. Fetterly, M. Budiu, U. Erlingsson, P. K. Gunda, and J. Currey. DryadLINQ: a system for general-purpose distributed data-parallel computing using a high-level language. In Proceedings of the 8th USENIX conference on Operating systems design and implementation, OSDI’08, pages 1–14, Berkeley, CA, USA, 2008. USENIX Association.
32. M. Zaharia, M. Chowdhury, M. J. Franklin, S. Shenker, and I. Stoica. Spark: cluster computing with working sets. In Proceedings of the 2nd USENIX conference on Hot topics in cloud computing, HotCloud’10, pages 10–10, Berkeley, CA, USA, 2010. USENIX Association.