[Hadoop]Hadoop YARN的發展史與詳細解析

帶有 MapReduce 的 Apache Hadoop 是分布式資料處理的骨幹力量。借助其獨特的橫向擴充實體叢集架構和由 Google 最初開發的精細處理架構，Hadoop 在大資料處理的全新領域迎來了爆炸式增長。Hadoop 還開發了一個豐富多樣的應用程式生态系統，包括 Apache Pig（一種強大的腳本語言）和 Apache Hive（一個具有類似 SQL 界面的資料倉庫解決方案）。

不幸的是，這個生态系統建構于一種程式設計模式之上，無法解決大資料中的所有問題。MapReduce 提供了一種特定的程式設計模型，盡管已認證 Pig 和 Hive 等工具得到了簡化，但它不是大資料的靈丹妙藥。我們首先介紹一下 MapReduce 2.0 (MRv2) — 或 Yet Another Resource Negotiator (YARN) — 并快速回顧一下 YARN 之前的 Hadoop 架構。

1. Hadoop 和 MRv1 簡單介紹

Hadoop 叢集可從單一節點（其中所有 Hadoop 實體都在同一個節點上運作）擴充到數千個節點（其中的功能分散在各個節點之間，以增加并行處理活動）。下圖示範了一個 Hadoop 叢集的進階元件。

一個 Hadoop 叢集可分解為兩個抽象實體：MapReduce 引擎和分布式檔案系統。MapReduce 引擎能夠在整個叢集上執行 Map 和 Reduce 任務并報告結果，其中分布式檔案系統提供了一種存儲模式，可跨節點複制資料以進行處理。Hadoop 分布式檔案系統 (HDFS) 通過定義來支援大型檔案（其中每個檔案通常為 64 MB 的倍數）。

當一個用戶端向一個 Hadoop 叢集發出一個請求時，此請求由 JobTracker 管理。JobTracker 與 NameNode 聯合将工作分發到離它所處理的資料盡可能近的位置。NameNode 是檔案系統的主系統，提供中繼資料服務來執行資料分發和複制。JobTracker 将 Map 和 Reduce 任務安排到一個或多個 TaskTracker 上的可用插槽中。TaskTracker 與 DataNode（分布式檔案系統）一起對來自 DataNode 的資料執行 Map 和 Reduce 任務。當 Map 和 Reduce 任務完成時，TaskTracker 會告知 JobTracker，後者确定所有任務何時完成并最終告知客戶作業已完成。

從 上圖 中可以看到，MRv1 實作了一個相對簡單的叢集管理器來執行 MapReduce 處理。MRv1 提供了一種分層的叢集管理模式，其中大資料作業以單個 Map 和 Reduce 任務的形式滲入一個叢集，并最後聚合成作業來報告給使用者。但這種簡單性有一些隐秘，不過也不是很隐秘的問題。

2. MRv1 的缺陷

MapReduce 的第一個版本既有優點也有缺點。MRv1 是目前使用的标準的大資料處理系統。但是，這種架構存在不足，主要表現在大型叢集上。當叢集包含的節點超過 4,000 個時（其中每個節點可能是多核的），就會表現出一定的不可預測性。其中一個最大的問題是級聯故障，由于要嘗試複制資料和重載活動的節點，是以一個故障會通過網絡泛洪形式導緻整個叢集嚴重惡化。

但 MRv1 的最大問題是多租戶。随着叢集規模的增加，一種可取的方式是為這些叢集采用各種不同的模型。MRv1 的節點專用于 Hadoop，是以可以改變它們的用途以用于其他應用程式和工作負載。當大資料和 Hadoop 成為雲部署中一個更重要的使用模型時，這種能力也會增強，因為它允許在伺服器上對 Hadoop 進行實體化，而無需虛拟化且不會增加管理、計算和輸入/輸出開銷。

我們現在看看 YARN 的新架構，看看它如何支援 MRv2 和其他使用不同處理模型的應用程式。

3. YARN (MRv2) 簡介

為了實作一個 Hadoop 叢集的叢集共享、可伸縮性和可靠性。設計人員采用了一種分層的叢集架構方法。具體來講，特定于 MapReduce 的功能已替換為一組新的守護程式，将該架構向新的處理模型開放。 

回想一下，由于限制了擴充以及網絡開銷所導緻的某些故障模式，MRv1 JobTracker 和 TaskTracker 方法曾是一個重要的缺陷。這些守護程式也是 MapReduce 處理模型所獨有的。為了消除這一限制，JobTracker 和 TaskTracker 已從 YARN 中删除，取而代之的是一組對應用程式不可知的新守護程式。

YARN 分層結構的本質是 ResourceManager。這個實體控制整個叢集并管理應用程式向基礎計算資源的配置設定。ResourceManager 将各個資源部分（計算、記憶體、帶寬等）精心安排給基礎 NodeManager（YARN 的每節點代理）。ResourceManager 還與 ApplicationMaster 一起配置設定資源，與 NodeManager 一起啟動和監視它們的基礎應用程式。在此上下文中，ApplicationMaster 承擔了以前的 TaskTracker 的一些角色，ResourceManager 承擔了 JobTracker 的角色。

ApplicationMaster 管理一個在 YARN 内運作的應用程式的每個執行個體。ApplicationMaster 負責協調來自 ResourceManager 的資源，并通過 NodeManager 監視容器的執行和資源使用（CPU、記憶體等的資源配置設定）。請注意，盡管目前的資源更加傳統（CPU 核心、記憶體），但未來會帶來基于手頭任務的新資源類型（比如圖形處理單元或專用處理裝置）。從 YARN 角度講，ApplicationMaster 是使用者代碼，是以存在潛在的安全問題。YARN 假設 ApplicationMaster 存在錯誤或者甚至是惡意的，是以将它們當作無特權的代碼對待。

NodeManager 管理一個 YARN 叢集中的每個節點。NodeManager 提供針對叢集中每個節點的服務，從監督對一個容器的終生管理到監視資源和跟蹤節點健康。MRv1 通過插槽管理 Map 和 Reduce 任務的執行，而 NodeManager 管理抽象容器，這些容器代表着可供一個特定應用程式使用的針對每個節點的資源。YARN 繼續使用 HDFS 層。它的主要 NameNode 用于中繼資料服務，而 DataNode 用于分散在一個叢集中的複制存儲服務。

要使用一個 YARN 叢集，首先需要來自包含一個應用程式的客戶的請求。ResourceManager 協商一個容器的必要資源，啟動一個 ApplicationMaster 來表示已送出的應用程式。通過使用一個資源請求協定，ApplicationMaster 協商每個節點上供應用程式使用的資源容器。執行應用程式時，ApplicationMaster 監視容器直到完成。當應用程式完成時，ApplicationMaster 從 ResourceManager 登出其容器，執行周期就完成了。

通過這些讨論，應該明确的一點是，舊的 Hadoop 架構受到了 JobTracker 的高度限制，JobTracker 負責整個叢集的資源管理和作業排程。新的 YARN 架構打破了這種模型，允許一個新 ResourceManager 管理跨應用程式的資源使用，ApplicationMaster 負責管理作業的執行。這一更改消除了一處瓶頸，還改善了将 Hadoop 叢集擴充到比以前大得多的配置的能力。此外，不同于傳統的 MapReduce，YARN 允許使用 Message Passing Interface 等标準通信模式，同時執行各種不同的程式設計模型，包括圖形處理、疊代式處理、機器學習和一般叢集計算。

4. 您需要知道的事 

随着 YARN 的出現，您不再受到更簡單的 MapReduce 開發模式限制，而是可以建立更複雜的分布式應用程式。實際上，您可以将 MapReduce 模型視為 YARN 架構可運作的一些應用程式中的其中一個，隻是為自定義開發公開了基礎架構的更多功能。這種能力非常強大，因為 YARN 的使用模型幾乎沒有限制，不再需要與一個叢集上可能存在的其他更複雜的分布式應用程式架構相隔離，就像 MRv1 一樣。甚至可以說，随着 YARN 變得更加健全，它有能力取代其他一些分布式處理架構，進而完全消除了專用于其他架構的資源開銷，同時還簡化了整個系統。

為了示範 YARN 相對于 MRv1 的效率提升，可考慮蠻力測試舊版本的 LAN Manager Hash 的并行問題，這是舊版 Windows® 用于密碼散列運算的典型方法。在此場景中，MapReduce 方法沒有多大意義，因為 Mapping/Reducing 階段涉及到太多開銷。相反，更合理的方法是抽象化作業配置設定，以便每個容器擁有密碼搜尋空間的一部分，在其之上進行枚舉，并通知您是否找到了正确的密碼。這裡的重點是，密碼将通過一個函數來動态确定（這确實有點棘手），而不需要将所有可能性映射到一個資料結構中，這就使得 MapReduce 風格顯得不必要且不實用。

歸結而言，MRv1 架構下的問題僅是需要一個關聯數組，而且這些問題有專門朝大資料操作方向演變的傾向。但是，問題一定不會永遠僅局限于此範式中，因為您現在可以更為簡單地将它們抽象化，編寫自定義用戶端、應用程式主程式，以及符合任何您想要的設計的應用程式。

5. 開發 YARN 應用程式

使用 YARN 提供的強大的新功能和在 Hadoop 之上建構自定義應用程式架構的能力，您還會面臨新的複雜性。為 YARN 建構應用程式，比在 YARN 之前的 Hadoop 之上建構傳統 MapReduce 應用程式要複雜得多，因為您需要開發一個 ApplicationMaster，這就是在用戶端請求到達時啟動的 ResourceManager。ApplicationMaster 有多種需求，包括實作一些需要的協定來與 ResourceManager 通信（用于請求資源）和 NodeManager（用于配置設定容器）。對于現有的 MapReduce 使用者，MapReduce ApplicationMaster 可最大限度地減少所需的任何新工作，進而使部署 MapReduce 作業所需的工作量與 YARN 之前的 Hadoop 類似。

在許多情況下，YARN 中一個應用程式的生命周期類似于 MRv1 應用程式。YARN 在一個叢集中配置設定許多資源，執行處理，公開用于監視應用程式進度的接觸點，且最終在應用程式完成時釋放資源并執行一般清理。這個生命周期的一種樣闆實作可在一個名為 Kitten 的項目中獲得（參見 參考資料）。Kitten 是一組工具和代碼，可簡化 YARN 中的應用程式開發，進而使您能夠将精力集中在應用程式的邏輯上，并在最初忽略協商和處理 YARN 叢集中各種實體的局限性的細節。但是，如果希望更深入地研究，Kitten 提供了一組服務，可用于處理與其他叢集實體（比如 ResourceManager）的互動。Kitten 提供了自己的 ApplicationMaster，很适用，但僅作為一個示例提供。Kitten 大量使用了 Lua 腳本作為其配置服務。

6. 下一步計劃

盡管 Hadoop 繼續在大資料市場中發展，但它已開始了一場演變，以解決有待定義的大規模資料工作負載。YARN 仍然在積極發展且可能不适合生産環境，但 YARN 相對傳統的 MapReduce 而言提供了重要優勢。它允許開發 MapReduce 之外的新分布式應用程式，允許它們彼此同時共存于同一個叢集中。YARN 建構于目前 Hadoop 叢集的現有元素之上，但也改進了 JobTracker 等元素，可以提高可伸縮性和增強許多不同應用程式共享叢集的能力。YARN 很快會來到您近旁的 Hadoop 叢集中，帶來它的全新功能和新複雜性。