一、yarn的基本概念
最近一段時間，經常看到有人在微博上說，“很多公司暫時用不到YARN，因爲一般公司的集羣規模並未像Yahoo、Facebook那樣達到幾千臺，甚至將來幾萬臺”。這完全是一種錯誤的觀念，在Hadoop高速發展的時代，必須更正。
實際上，上述觀念只看到了YARN的擴展性（Scalability），擴展性是可用可不用的特性，中小型公司將YARN部署到小集羣（按照IBM觀點，集羣規模小於200臺的稱爲中小規模集羣，這樣的公司找到90%以上）上，可能享受不到擴展性帶來的優勢，但至少可以獲取以下幾個收益：
（1） 更快地MapReduce計算
MapReduce仍是當前使用最廣泛的計算框架。YARN利用異步模型對MapReduce框架的一些關鍵邏輯結構（如JobInprogress、TaskInProgress等）進行了重寫，相比於MRv1，具有更快地計算速度。當然，YARN具有向後兼容性，用戶在MRv1上運行的作業，無需任何修改即可運行在YARN之上。
（2） 對多框架支持
與MRv1相比，YARN不再是一個單純的計算框架，而是一個框架管理器，用戶可以將各種各樣的計算框架移植到YARN之上，由YARN進行統一管理和資源分配，由於將現有框架移植到YARN之上需要一定的工作量，當前YARN僅可運行MapReduce這種離線計算框架。
我們知道，不存在一種統一的計算框架適合所有應用場景，也就是說，如果你想設計一種計算框架，可以高效地進行離線計算、在線計算、流式計算、內存計算等，是不可能的。既然沒有全能的計算框架，爲什麼不開發一個容納和管理各種計算框架的框架管理平臺（實際上是資源管理平臺）呢，而YARN正是幹這件事情的東西。
YANR本質上是一個資源統一管理系統，這一點與幾年前的mesos（http://www.mesosproject.org/），更早的Torque（http://www.adaptivecomputing.com/products/open-source/torque/）基本一致。將各種框架運行在YARN之上，可以實現框架的資源統一管理和分配，使他們共享一個集羣，而不是“一個框架一個集羣”，這可大大降低運維成本和硬件成本。
如果你還沒有意識到當前已經進入多計算框架縱橫捭闔的新時代，那讓我來給你細數一下當前出現的，已小有名氣的計算框架吧：
1） MapReduce: 這個框架人人皆知，它是一種離線計算框架，將一個算法抽象成Map和Reduce兩個階段進行處理，非常適合數據密集型計算。
2） Spark: 我們知道，MapReduce計算框架不適合（不是不能做，是不適合，效率太低）迭代計算（常見於machine learning領域，比如PageRank）和交互式計算（data mining領域，比如SQL查詢），MapReduce是一種磁盤計算框架，而Spark則是一種內存計算框架，它將數據儘可能放到內存中以提高迭代應用和交互式應用的計算效率。官方首頁：http://spark-project.org/
3） Storm: MapReduce也不適合進行流式計算、實時分析，比如廣告點擊計算等，而Storm則更擅長這種計算、它在實時性要遠遠好於MapReduce計算框架。官方首頁：http://storm-project.net/
4） S4: Yahoo開發的流式計算框架，與Storm較爲類似。官方首頁：http://incubator.apache.org/s4/
5） Open MPI: 非常經典的消息處理框架，非常適合高性能計算，現在仍被廣泛使用。
6） HAMA: 基於BSP（bulk-synchronous parallel model）模型的分佈式計算框架，與Google的Pregel類似，可用於大規模科學計算，如矩陣，圖算法，網絡算法等，官方首頁：http://hama.apache.org/。
7） Cloudera Impala/ Apache Drill: 基於Hadoop的更快的SQL查詢引擎（比Hive快得多），Google Dremel的模仿者。Cloudera Impala官方首頁：https://github.com/cloudera/impala，Apache Drill官方首頁：http://incubator.apache.org/drill/
8） Giraph：圖算法處理框架，採用BSP模型，可用於計算pagerank，shared connections, personalization-based popularity等迭代類算法。官方首頁：http://giraph.apache.org/
上面很多框架正在或正準備往YARN上遷移，具體見：http://wiki.apache.org/hadoop/PoweredByYarn/
（3） 框架升級更容易
在YARN中，各種計算框架不再是作爲一個服務部署到集羣的各個節點上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服務），而是被封裝成一個用戶程序庫（lib）存放在客戶端，當需要對計算框架進行升級時，只需升級用戶程序庫即可，多麼容易！
總結
YARN是在Hadoop 1.0基礎上衍化而來的，它具有比Hadoop 1.0更爲先進的理念和思想，它充分吸取了Hadoop 1.0的優勢，但同時增加了很多新的特性和改進點。即使你不使用YARN，研究YARN對於改進你們當前Hadoop版本仍有巨大的幫助。
需要說明的是，YARN是一個嶄新的系統，它完全不同於Hadoop 1.0。對於一般公司而言，將舊Hadoop系統往YARN上移植將是一件十分困難的事情，因爲不同公司對內部Hadoop進行了或多或少的改造，這些改造或許已經不再兼容於主流的Hadoop版本。當向YARN升級時，你需要對兼容性進行充分的測試，以確保當前運行的作業仍可以正常地運行在移植後的系統上。 另外，需要引起注意的是，YARN會給運維人員帶來巨大的麻煩，畢竟它是一個新系統。
當然，當前YARN還不成熟，仍處於高速醞釀階段，討論如何在線上使用它仍爲時過早。不過，開始研究和學習它，作爲一名有進取心和前瞻眼光的hadoopor，仍是十分必要的。
轉自：http://dongxicheng.org/mapreduce-nextgen/what-can-we-benifit-from-yarn/
二、Yet Another Resource Negotiator 簡介
大數據不斷在演變，因而它的處理框架也在不斷演變。Apache Hadoop 於 2005 年推出，提供了核心的 MapReduce 處理引擎來支持大規模數據工作負載的分佈式處理。7 年後的今天，Hadoop 正在經歷着一次徹底檢查。通過這次檢查，得到了一個更加通用的 Hadoop 框架，不僅支持 MapReduce，還支持其他分佈式處理模型。本文介紹全新的 Hadoop 架構，並確定您在切換到該架構之前需要知道的信息。
帶有 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 架構。
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，後者確定所有任務何時完成並最終告知客戶作業已完成。
InfoSphere BigInsights Quick Start Edition
InfoSphere BigInsights Quick Start Edition 是 IBM 基於 Hadoop 的產品 InfoSphere BigInsights 的一個免費可下載版本。使用 Quick Start Edition，您可嘗試 IBM 開發的特性來擴大開源 Hadoop 的價值，比如 Big SQL、文本分析和 BigSheets。引導式學習可讓您的體驗儘可能順暢，包括按部就班、自定進度的教程和視頻，可以幫助開始讓 Hadoop 爲您所用。沒有時間或數據限制，您可自行安排時間在大量數據上進行試驗。請
觀看視頻、學習教程 (PDF) 和 下載 BigInsights Quick Start Edition。
從 圖 1 中可以看到，MRv1 實現了一個相對簡單的集羣管理器來執行 MapReduce 處理。MRv1 提供了一種分層的集羣管理模式，其中大數據作業以單個 Map 和 Reduce 任務的形式滲入一個集羣，並最後聚合成作業來報告給用戶。但這種簡單性有一些隱祕，不過也不是很隱祕的問題。
MRv1 的缺陷
MapReduce 的第一個版本既有優點也有缺點。MRv1 是目前使用的標準的大數據處理系統。但是，這種架構存在不足，主要表現在大型集羣上。當集羣包含的節點超過 4,000 個時（其中每個節點可能是多核的），就會表現出一定的不可預測性。其中一個最大的問題是級聯故障，由於要嘗試複製數據和重載活動的節點，所以一個故障會通過網絡泛洪形式導致整個集羣嚴重惡化。
但 MRv1 的最大問題是多租戶。隨着集羣規模的增加，一種可取的方式是爲這些集羣採用各種不同的模型。MRv1 的節點專用於 Hadoop，所以可以改變它們的用途以用於其他應用程序和工作負載。當大數據和 Hadoop 成爲雲部署中一個更重要的使用模型時，這種能力也會增強，因爲它允許在服務器上對 Hadoop 進行物理化，而無需虛擬化且不會增加管理、計算和輸入/輸出開銷。
我們現在看看 YARN 的新架構，看看它如何支持 MRv2 和其他使用不同處理模型的應用程序。
YARN (MRv2) 簡介
爲了實現一個 Hadoop 集羣的集羣共享、可伸縮性和可靠性。設計人員採用了一種分層的集羣框架方法。具體來講，特定於 MapReduce 的功能已替換爲一組新的守護程序，將該框架向新的處理模型開放。
可在何處找到 YARN？
YARN 是在 hadoop-0.23 版本時引入 Hadoop 中的。隨着徹底檢查的不斷完善，您將會發現此框架也在不斷更新。
回想一下，由於限制了擴展以及網絡開銷所導致的某些故障模式，MRv1 JobTracker 和 TaskTracker 方法曾是一個重要的缺陷。這些守護程序也是 MapReduce 處理模型所獨有的。爲了消除這一限制，JobTracker 和 TaskTracker 已從 YARN 中刪除，取而代之的是一組對應用程序不可知的新守護程序。
圖 2. YARN 的新架構
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 集羣中，帶來它的全新功能和新複雜性。
轉自：http://www.ibm.com/developerworks/cn/data/library/bd-hadoopyarn/