【編者按】成熟、通用讓Hadoop深得大數據玩家喜愛(ài)，即使是在YARN出現之前，在流處理框架林立下，Hadoop仍然被眾多機構廣泛運用在離線(xiàn)處理之上。借鑒于Mesos，MapReduce獲得新生，YARN提供了更加優(yōu)秀的資源管理器，讓Storm等流處理框架同樣可以運行在Hadoop集群之上；但是別忘記，Hadoop有著(zhù)遠比Mesos成熟的社區。從興起到唱衰再到興起，這頭搬運大數據的大象已更加成熟、穩重，同時(shí)我們也相信，在未來(lái)container等屬性加入后，Hadoop生態(tài)系統必將發(fā)揚光大。以下為文章內容
帶有 MapReduce 的 Apache Hadoop 是分布式數據處理的骨干力量。借助其獨特的橫向擴展物理集群架構和由 Google 最初開(kāi)發(fā)的精細處理框架，Hadoop 在大數據處理的全新領(lǐng)域迎來(lái)了爆炸式增長(cháng)。Hadoop 還開(kāi)發(fā)了一個(gè)豐富多樣的應用程序生態(tài)系統，包括 Apache Pig（一種強大的腳本語(yǔ)言）和 Apache Hive（一個(gè)具有類(lèi)似 SQL 界面的數據倉庫解決方案）。
不幸的是，這個(gè)生態(tài)系統構建于一種編程模式之上，無(wú)法解決大數據中的所有問(wèn)題。MapReduce 提供了一種特定的編程模型，盡管已通過(guò) Pig 和 Hive 等工具得到了簡(jiǎn)化，但它不是大數據的靈丹妙藥。我們首先介紹一下 MapReduce 2.0 (MRv2) — 或 Yet Another Resource Negotiator (YARN) — 并快速回顧一下 YARN 之前的 Hadoop 架構。
Hadoop 和 MRv1 簡(jiǎn)單介紹
Hadoop 集群可從單一節點(diǎn)（其中所有 Hadoop 實(shí)體都在同一個(gè)節點(diǎn)上運行）擴展到數千個(gè)節點(diǎn)（其中的功能分散在各個(gè)節點(diǎn)之間，以增加并行處理活動(dòng)）。下圖演示了一個(gè) Hadoop 集群的高級組件。
一個(gè) Hadoop 集群可分解為兩個(gè)抽象實(shí)體：MapReduce 引擎和分布式文件系統。MapReduce 引擎能夠在整個(gè)集群上執行 Map 和 Reduce 任務(wù)并報告結果，其中分布式文件系統提供了一種存儲模式，可跨節點(diǎn)復制數據以進(jìn)行處理。Hadoop 分布式文件系統 (HDFS) 通過(guò)定義來(lái)支持大型文件（其中每個(gè)文件通常為 64 MB 的倍數）。
當一個(gè)客戶(hù)端向一個(gè) Hadoop 集群發(fā)出一個(gè)請求時(shí)，此請求由 JobTracker 管理。JobTracker 與 NameNode 聯(lián)合將工作分發(fā)到離它所處理的數據盡可能近的位置。NameNode 是文件系統的主系統，提供元數據服務(wù)來(lái)執行數據分發(fā)和復制。JobTracker 將 Map 和 Reduce 任務(wù)安排到一個(gè)或多個(gè) TaskTracker 上的可用插槽中。TaskTracker 與 DataNode（分布式文件系統）一起對來(lái)自 DataNode 的數據執行 Map 和 Reduce 任務(wù)。當 Map 和 Reduce 任務(wù)完成時(shí)，TaskTracker 會(huì )告知 JobTracker，后者確定所有任務(wù)何時(shí)完成并最終告知客戶(hù)作業(yè)已完成。
從上圖中可以看到，MRv1 實(shí)現了一個(gè)相對簡(jiǎn)單的集群管理器來(lái)執行 MapReduce 處理。MRv1 提供了一種分層的集群管理模式，其中大數據作業(yè)以單個(gè) Map 和 Reduce 任務(wù)的形式滲入一個(gè)集群，并最后聚合成作業(yè)來(lái)報告給用戶(hù)。但這種簡(jiǎn)單性有一些隱秘，不過(guò)也不是很隱秘的問(wèn)題。
MRv1 的缺陷
apReduce 的第一個(gè)版本既有優(yōu)點(diǎn)也有缺點(diǎn)。MRv1 是目前使用的標準的大數據處理系統。但是，這種架構存在不足，主要表現在大型集群上。當集群包含的節點(diǎn)超過(guò) 4,000 個(gè)時(shí)（其中每個(gè)節點(diǎn)可能是多核的），就會(huì )表現出一定的不可預測性。其中一個(gè)最大的問(wèn)題是級聯(lián)故障，由于要嘗試復制數據和重載活動(dòng)的節點(diǎn)，所以一個(gè)故障會(huì )通過(guò)網(wǎng)絡(luò )泛洪形式導致整個(gè)集群嚴重惡化。
但 MRv1 的最大問(wèn)題是多租戶(hù)。隨著(zhù)集群規模的增加，一種可取的方式是為這些集群采用各種不同的模型。MRv1 的節點(diǎn)專(zhuān)用于 Hadoop，所以可以改變它們的用途以用于其他應用程序和工作負載。當大數據和 Hadoop 成為云部署中一個(gè)更重要的使用模型時(shí)，這種能力也會(huì )增強，因為它允許在服務(wù)器上對 Hadoop 進(jìn)行物理化，而無(wú)需虛擬化且不會(huì )增加管理、計算和輸入/輸出開(kāi)銷(xiāo)。
我們現在看看 YARN 的新架構，看看它如何支持 MRv2 和其他使用不同處理模型的應用程序。
YARN (MRv2) 簡(jiǎn)介
為了實(shí)現一個(gè) Hadoop 集群的集群共享、可伸縮性和可靠性。設計人員采用了一種分層的集群框架方法。具體來(lái)講，特定于 MapReduce 的功能已替換為一組新的守護程序，將該框架向新的處理模型開(kāi)放。
回想一下，由于限制了擴展以及網(wǎng)絡(luò )開(kāi)銷(xiāo)所導致的某些故障模式，MRv1 JobTracker 和 TaskTracker 方法曾是一個(gè)重要的缺陷。這些守護程序也是 MapReduce 處理模型所獨有的。為了消除這一限制，JobTracker 和 TaskTracker 已從 YARN 中刪除，取而代之的是一組對應用程序不可知的新守護程序。
YARN 分層結構的本質(zhì)是 ResourceManager。這個(gè)實(shí)體控制整個(gè)集群并管理應用程序向基礎計算資源的分配。ResourceManager 將各個(gè)資源部分（計算、內存、帶寬等）精心安排給基礎 NodeManager（YARN 的每節點(diǎn)代理）。ResourceManager 還與 ApplicationMaster 一起分配資源，與 NodeManager 一起啟動(dòng)和監視它們的基礎應用程序。在此上下文中，ApplicationMaster 承擔了以前的 TaskTracker 的一些角色，ResourceManager 承擔了 JobTracker 的角色。
ApplicationMaster 管理一個(gè)在 YARN 內運行的應用程序的每個(gè)實(shí)例。ApplicationMaster 負責協(xié)調來(lái)自 ResourceManager 的資源，并通過(guò) NodeManager 監視容器的執行和資源使用（CPU、內存等的資源分配）。請注意，盡管目前的資源更加傳統（CPU 核心、內存），但未來(lái)會(huì )帶來(lái)基于手頭任務(wù)的新資源類(lèi)型（比如圖形處理單元或專(zhuān)用處理設備）。從 YARN 角度講，ApplicationMaster 是用戶(hù)代碼，因此存在潛在的安全問(wèn)題。YARN 假設 ApplicationMaster 存在錯誤或者甚至是惡意的，因此將它們當作無(wú)特權的代碼對待。
NodeManager 管理一個(gè) YARN 集群中的每個(gè)節點(diǎn)。NodeManager 提供針對集群中每個(gè)節點(diǎn)的服務(wù)，從監督對一個(gè)容器的終生管理到監視資源和跟蹤節點(diǎn)健康。MRv1 通過(guò)插槽管理 Map 和 Reduce 任務(wù)的執行，而 NodeManager 管理抽象容器，這些容器代表著(zhù)可供一個(gè)特定應用程序使用的針對每個(gè)節點(diǎn)的資源。YARN 繼續使用 HDFS 層。它的主要 NameNode 用于元數據服務(wù)，而 DataNode 用于分散在一個(gè)集群中的復制存儲服務(wù)。
要使用一個(gè) YARN 集群，首先需要來(lái)自包含一個(gè)應用程序的客戶(hù)的請求。ResourceManager 協(xié)商一個(gè)容器的必要資源，啟動(dòng)一個(gè) ApplicationMaster 來(lái)表示已提交的應用程序。通過(guò)使用一個(gè)資源請求協(xié)議，ApplicationMaster 協(xié)商每個(gè)節點(diǎn)上供應用程序使用的資源容器。執行應用程序時(shí)，ApplicationMaster 監視容器直到完成。當應用程序完成時(shí)，ApplicationMaster 從 ResourceManager 注銷(xiāo)其容器，執行周期就完成了。
通過(guò)這些討論，應該明確的一點(diǎn)是，舊的 Hadoop 架構受到了 JobTracker 的高度約束，JobTracker 負責整個(gè)集群的資源管理和作業(yè)調度。新的 YARN 架構打破了這種模型，允許一個(gè)新 ResourceManager 管理跨應用程序的資源使用，ApplicationMaster 負責管理作業(yè)的執行。這一更改消除了一處瓶頸，還改善了將 Hadoop 集群擴展到比以前大得多的配置的能力。此外，不同于傳統的 MapReduce，YARN 允許使用 Message Passing Interface 等標準通信模式，同時(shí)執行各種不同的編程模型，包括圖形處理、迭代式處理、機器學(xué)習和一般集群計算。
您需要知道的事
隨著(zhù) YARN 的出現，您不再受到更簡(jiǎn)單的 MapReduce 開(kāi)發(fā)模式約束，而是可以創(chuàng )建更復雜的分布式應用程序。實(shí)際上，您可以將 MapReduce 模型視為 YARN 架構可運行的一些應用程序中的其中一個(gè)，只是為自定義開(kāi)發(fā)公開(kāi)了基礎框架的更多功能。這種能力非常強大，因為 YARN 的使用模型幾乎沒(méi)有限制，不再需要與一個(gè)集群上可能存在的其他更復雜的分布式應用程序框架相隔離，就像 MRv1 一樣。甚至可以說(shuō)，隨著(zhù) YARN 變得更加健全，它有能力取代其他一些分布式處理框架，從而完全消除了專(zhuān)用于其他框架的資源開(kāi)銷(xiāo)，同時(shí)還簡(jiǎn)化了整個(gè)系統。
為了演示 YARN 相對于 MRv1 的效率提升，可考慮蠻力測試舊版本的 LAN Manager Hash 的并行問(wèn)題，這是舊版 Windows? 用于密碼散列運算的典型方法。在此場(chǎng)景中，MapReduce 方法沒(méi)有多大意義，因為 Mapping/Reducing 階段涉及到太多開(kāi)銷(xiāo)。相反，更合理的方法是抽象化作業(yè)分配，以便每個(gè)容器擁有密碼搜索空間的一部分，在其之上進(jìn)行枚舉，并通知您是否找到了正確的密碼。這里的重點(diǎn)是，密碼將通過(guò)一個(gè)函數來(lái)動(dòng)態(tài)確定（這確實(shí)有點(diǎn)棘手），而不需要將所有可能性映射到一個(gè)數據結構中，這就使得 MapReduce 風(fēng)格顯得不必要且不實(shí)用。
歸結而言，MRv1 框架下的問(wèn)題僅是需要一個(gè)關(guān)聯(lián)數組，而且這些問(wèn)題有專(zhuān)門(mén)朝大數據操作方向演變的傾向。但是，問(wèn)題一定不會(huì )永遠僅局限于此范式中，因為您現在可以更為簡(jiǎn)單地將它們抽象化，編寫(xiě)自定義客戶(hù)端、應用程序主程序，以及符合任何您想要的設計的應用程序。
開(kāi)發(fā) YARN 應用程序
使用 YARN 提供的強大的新功能和在 Hadoop 之上構建自定義應用程序框架的能力，您還會(huì )面臨新的復雜性。為 YARN 構建應用程序，比在 YARN 之前的 Hadoop 之上構建傳統 MapReduce 應用程序要復雜得多，因為您需要開(kāi)發(fā)一個(gè) ApplicationMaster，這就是在客戶(hù)端請求到達時(shí)啟動(dòng)的 ResourceManager。ApplicationMaster 有多種需求，包括實(shí)現一些需要的協(xié)議來(lái)與 ResourceManager 通信（用于請求資源）和 NodeManager（用于分配容器）。對于現有的 MapReduce 用戶(hù)，MapReduce ApplicationMaster 可最大限度地減少所需的任何新工作，從而使部署 MapReduce 作業(yè)所需的工作量與 YARN 之前的 Hadoop 類(lèi)似。
在許多情況下，YARN 中一個(gè)應用程序的生命周期類(lèi)似于 MRv1 應用程序。YARN 在一個(gè)集群中分配許多資源，執行處理，公開(kāi)用于監視應用程序進(jìn)度的接觸點(diǎn)，且最終在應用程序完成時(shí)釋放資源并執行一般清理。這個(gè)生命周期的一種樣板實(shí)現可在一個(gè)名為 Kitten 的項目中獲得（參見(jiàn) 參考資料）。Kitten 是一組工具和代碼，可簡(jiǎn)化 YARN 中的應用程序開(kāi)發(fā)，從而使您能夠將精力集中在應用程序的邏輯上，并在最初忽略協(xié)商和處理 YARN 集群中各種實(shí)體的局限性的細節。但是，如果希望更深入地研究，Kitten 提供了一組服務(wù)，可用于處理與其他集群實(shí)體（比如 ResourceManager）的交互。Kitten 提供了自己的 ApplicationMaster，很適用，但僅作為一個(gè)示例提供。Kitten 大量使用了 Lua 腳本作為其配置服務(wù)。
下一步計劃
盡管 Hadoop 繼續在大數據市場(chǎng)中發(fā)展，但它已開(kāi)始了一場(chǎng)演變，以解決有待定義的大規模數據工作負載。YARN 仍然在積極發(fā)展且可能不適合生產(chǎn)環(huán)境，但 YARN 相對傳統的 MapReduce 而言提供了重要優(yōu)勢。它允許開(kāi)發(fā) MapReduce 之外的新分布式應用程序，允許它們彼此同時(shí)共存于同一個(gè)集群中。YARN 構建于當前 Hadoop 集群的現有元素之上，但也改進(jìn)了 JobTracker 等元素，可以提高可伸縮性和增強許多不同應用程序共享集群的能力。YARN 很快會(huì )來(lái)到您近旁的 Hadoop 集群中，帶來(lái)它的全新功能和新復雜性。
本文由CSDN轉載，點(diǎn)擊“閱讀原文”可查看原文并參與討論。
如果您喜歡這篇文章，請點(diǎn)擊右上角“…”將本文分享給你的朋友。
聯(lián)系客服
