hadoop yarn 易理解

Hadoop 和 MRv1 簡單介紹

Hadoop 集羣可從單一節點（其中全部 Hadoop 實體都在同一個節點上運行）擴展到數千個節點（其中的功能分散在各個節點之間，以增長並行處理活動）。圖 1 演示了一個 Hadoop 集羣的高級組件。

 

圖 1. 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，後者肯定全部任務什麼時候完成並最終告知客戶做業已完成。

從 圖 1 中能夠看到，MRv1 實現了一個相對簡單的集羣管理器來執行 MapReduce 處理。MRv1 提供了一種分層的集羣管理模式，其中大數據做業以單個 Map 和 Reduce 任務的形式滲入一個集羣，並最後聚合成做業來報告給用戶。但這種簡單性有一些隱祕，不過也不是很隱祕的問題。 

MRv1 的缺陷

MapReduce 的第一個版本既有優勢也有缺點。MRv1 是目前使用的標準的大數據處理系統。可是，這種架構存在不足，主要表如今大型集羣上。當集羣包含的節點超過 4,000 個時（其中每一個節點多是多核的），就會表現出必定的不可預測性。其中一個最大的問題是級聯故障，因爲要嘗試複製數據和重載活動的節點，因此一個故障會經過網絡泛洪形式致使整個集羣嚴重惡化。

但 MRv1 的最大問題是多租戶。隨着集羣規模的增長，一種可取的方式是爲這些集羣採用各類不一樣的模型。MRv1 的節點專用於 Hadoop，因此能夠改變它們的用途以用於其餘應用程序和工做負載。當大數據和 Hadoop 成爲雲部署中一個更重要的使用模型時，這種能力也會加強，由於它容許在服務器上對 Hadoop 進行物理化，而無需虛擬化且不會增長管理、計算和輸入/輸出開銷。

咱們如今看看 YARN 的新架構，看看它如何支持 MRv2 和其餘使用不一樣處理模型的應用程序。

---

YARN (MRv2) 簡介

爲了實現一個 Hadoop 集羣的集羣共享、可伸縮性和可靠性。設計人員採用了一種分層的集羣框架方法。具體來說，特定於 MapReduce 的功能已替換爲一組新的守護程序，將該框架向新的處理模型開放。 

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

 

圖 2. 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 等標準通訊模式，同時執行各類不一樣的編程模型，包括圖形處理、迭代式處理、機器學習和通常集羣計算。

---

您須要知道的事 

隨着 YARN 的出現，您再也不受到更簡單的 MapReduce 開發模式約束，而是能夠建立更復雜的分佈式應用程序。實際上，您能夠將 MapReduce 模型視爲 YARN 架構可運行的一些應用程序中的其中一個，只是爲自定義開發公開了基礎框架的更多功能。這種能力很是強大，由於 YARN 的使用模型幾乎沒有限制，再也不須要與一個集羣上可能存在的其餘更復雜的分佈式應用程序框架相隔離，就像 MRv1 同樣。甚至能夠說，隨着 YARN 變得更加健全，它有能力取代其餘一些分佈式處理框架，從而徹底消除了專用於其餘框架的資源開銷，同時還簡化了整個系統。

爲了演示 YARN 相對於 MRv1 的效率提高，可考慮蠻力測試舊版本的 LAN Manager Hash 的並行問題，這是舊版 Windows® 用於密碼散列運算的典型方法。在此場景中，MapReduce 方法沒有多大意義，由於 Mapping/Reducing 階段涉及到太多開銷。相反，更合理的方法是抽象化做業分配，以便每一個容器擁有密碼搜索空間的一部分，在其之上進行枚舉，並通知您是否找到了正確的密碼。這裏的重點是，密碼將經過一個函數來動態肯定（這確實有點棘手），而不須要將全部可能性映射到一個數據結構中，這就使得 MapReduce 風格顯得沒必要要且不實用。

歸結而言，MRv1 框架下的問題僅是須要一個關聯數組，並且這些問題有專門朝大數據操做方向演變的傾向。可是，問題必定不會永遠僅侷限於此範式中，由於您如今能夠更爲簡單地將它們抽象化，編寫自定義客戶端、應用程序主程序，以及符合任何您想要的設計的應用程序。

---

開發 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 腳本做爲其配置服務。

---

下一步計劃

儘管 Hadoop 繼續在大數據市場中發展，但它已開始了一場演變，以解決有待定義的大規模數據工做負載。YARN 仍然在積極發展且可能不適合生產環境，但 YARN 相對傳統的 MapReduce 而言提供了重要優點。它容許開發 MapReduce 以外的新分佈式應用程序，容許它們彼此同時共存於同一個集羣中。YARN 構建於當前 Hadoop 集羣的現有元素之上，但也改進了 JobTracker 等元素，能夠提升可伸縮性和加強許多不一樣應用程序共享集羣的能力。YARN 很快會來到您近旁的 Hadoop 集羣中，帶來它的全新功能和新複雜性。 

---

參考資料

學習

 

• 有關 Hadoop 及其生態系統中其餘元素的最新新聞，請查閱  Apache Hadoop 項目站點。除了 Hadoop，您還將瞭解到 Hadoop 是如何（藉助 YARN 等新技術）橫向擴展以及（藉助 Pig、Hive 等衆多新技術）縱向升級的。
• 隨着 YARN 不斷成熟，您會了解到使用 YARN 模型編寫應用程序的早期方法。一個有用的參考資料是  編寫 YARN 應用程序。您將在這篇參考資料中發現 YARN 引入的一些新複雜性，以及對於在一種 YARN 部署中用於實體間通訊的各類協議的討論。
• 使用 Apache 的  Distributed Shell Source。
• 查看來自  Big Data University 的關於衆多主題的免費課程，包括 Hadoop 基礎和文本分析精要，以及 SQL Access for Hadoop 和實時流計算。
• Apache Hadoop 0.23 中的 MRv2，這是對一個 JARN 集羣的重要技術細節的不錯介紹。
• Kitten: For Developers Who Like Playing with YARN 提供了對 YARN 應用程序開發的 Hitten 抽象的有用介紹。
• 在  developerWorks 大數據內容專區 中瞭解有關大數據的更多信息。查找技術文檔、指南文章、教育、下載、產品信息等。