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