一、Hadoop Yarn解析

1，Yarn是Hadoop推出整個分散式（大資料）叢集的資源管理器，負責資源的管理和分配，基於Yarn我們可以在同一個大資料叢集上同時執行多個計算框架，例如Spark、MapReduce、Storm等；
2，Yarn基本工作流程如下圖所示：

注意：Container要向NodeManager彙報資源資訊，Container（程式設計師）要向App Mstr（專案經理）彙報計算資訊；

3，客戶端Client向ResourceManager（老總，管理整個叢集的資源）提交Application，ResourceManager接受應用並根據叢集資源狀況決定在某個具體Node上來啟動當前提交的應用程式的任務排程器Driver（ApplicationMaster），決定後ResourceManager會命令具體的某個Node上的資源管理器NodeManager（管理當前機器的記憶體，cpu等資源的）來啟動一個新的JVM程序執行程式的Driver部分，當ApplicationMaster啟動的時候（會首先向ResourceManager註冊來說明自己負責當前程式的執行）會下載當前Application相關的Jar等各種資源並基於此決定具體向ResourceManager申請資源的具體內容，ResourceManager接受到ApplicationMaster的資源分配的請求之後會最大化的滿足資源分配的請求併發送資源的元資料資訊給ApplicationMaster，ApplicationMaster收到資源的元資料資訊後會根據元資料資訊發指令給具體機器上的NodeManager讓NodeManager來啟動具體的Container，Container在啟動後必須向AppplicationMaster註冊，當ApplicationMaster獲得了用於計算的Containers後，開始進行任務的排程和計算，直到作業的完成。需要補充說的是，如果ResourceManager第一次沒有能夠完全完成ApplicationMaster分配的資源的請求，後續ResourceManager發現叢集中有新的可用資源時候，會主動向ApplicationMaster傳送新的可用資源的元資料資訊以提供更多的資源用於當前程式的執行！
補充說明：
1、container如果是Hadoop的MapReduce，不可複用，Spark on Yarn 可以複用
2.Container的銷燬由具體的ApplicationManager銷燬，ApplicationManager發指令給NodeManager來銷燬Container

擴充套件：新舊 Hadoop MapReduce 框架比對

讓我們來對新舊 MapReduce 框架做詳細的分析和對比，可以看到有以下幾點顯著變化：

首先客戶端不變，其呼叫 API 及介面大部分保持相容，這也是為了對開發使用者透明化，使其不必對原有程式碼做大的改變 ，但是原框架中核心的 JobTracker 和 TaskTracker 不見了，取而代之的是 ResourceManager, ApplicationMaster 與 NodeManager 三個部分。

我們來詳細解釋這三個部分，首先 ResourceManager 是一箇中心的服務，它做的事情是排程、啟動每一個 Job 所屬的 ApplicationMaster、另外監控 ApplicationMaster 的存在情況。細心的讀者會發現：Job 裡面所在的 task 的監控、重啟等等內容不見了。這就是 AppMst 存在的原因。ResourceManager 負責作業與資源的排程。接收 JobSubmitter 提交的作業，按照作業的上下文 (Context) 資訊，以及從 NodeManager 收集來的狀態資訊，啟動排程過程，分配一個 Container 作為 App Mstr

NodeManager 功能比較專一，就是負責 Container 狀態的維護，並向 RM 保持心跳。

ApplicationMaster 負責一個 Job 生命週期內的所有工作，類似老的框架中 JobTracker。但注意每一個 Job（不是每一種）都有一個 ApplicationMaster，它可以執行在 ResourceManager 以外的機器上。

Yarn 框架相對於老的 MapReduce 框架什麼優勢呢？我們可以看到：

這個設計大大減小了 JobTracker（也就是現在的 ResourceManager）的資源消耗，並且讓監測每一個 Job 子任務 (tasks) 狀態的程式分散式化了，更安全、更優美。

在新的 Yarn 中，ApplicationMaster 是一個可變更的部分，使用者可以對不同的程式設計模型寫自己的 AppMst，讓更多型別的程式設計模型能夠跑在 Hadoop 叢集中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。

對於資源的表示以記憶體為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的佔用 )，比之前以剩餘 slot 數目更合理。

老的框架中，JobTracker 一個很大的負擔就是監控 job 下的 tasks 的執行狀況，現在，這個部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個模組叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是監測 ApplicationMaster 的執行狀況，如果出問題，會將其在其他機器上重啟。

Container 是 Yarn 為了將來作資源隔離而提出的一個框架。這一點應該借鑑了 Mesos 的工作，目前是一個框架，僅僅提供 Java 虛擬機器記憶體的隔離 ,hadoop 團隊的設計思路應該後續能支援更多的資源排程和控制 , 既然資源表示成記憶體量，那就沒有

二、Spark on Yarn 兩種執行模式
Spark on yarn的兩種執行模式實戰：此時不需要啟動spark叢集，只需啟動yarn即可！yarn的ResourceManager相當於spark standalone模式下的master！

1.spark on yarn的兩種執行模式：唯一的決定因素是當前application從任務排程器driver執行在什麼地方！

a) Cluster:driver執行的yarn叢集下的某臺機器上的jvm程序中！！！

b) Client：driver執行在當前提交程式的客戶機器上，需要說明的是：無論是什麼模式，只要當前機器運行了spark程式碼，就必須安裝spark！

2.Spark on yarn的執行實戰：

a) client模式：方便在命令終端直接看到執行的過程資訊，尤其方便做測試使用，

例如：

./spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode client ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 50000

並行度變成50000，相當於50000臺機器（1000-》50000）

Spark天機解密：Standalone模式下啟動Spark叢集（也就是啟動Master和Worker）其實啟動的是資源管理器，真正作業計算的時候和叢集資源管理器沒有任何關係，所以Spark的Job真正執行作業的時候不是執行在你啟動的Spark叢集中的，而是執行在一個個JVM中的，只要在JVM所在的機器上安裝配置了Spark即可！！！

3.Spark on yarn 模式下Driver和application的關係：

a) cluster:driver位於ApplicationMaster程序中，我們需要通過hadoop預設指定的8088埠來通過web控制檯檢視當前的spark程式執行的資訊，例如進度，資源的使用；

b) client：driver為提交程式碼的機器上，此時applicationmaster依舊位於叢集中且只負責資源的申請和launchExecutor，此時啟動後的executor並不會向applicationmaster程序註冊，而是向driver註冊！

三 最佳實踐

1． Spark on yarn 模式下hadoop yarn的配置yarn.nodemanager.local-dir會覆蓋spark.local.dir!!!

2． 在實際生產環境下一版是採用cluster，我們會通過history server來獲取最終全部的執行資訊；

3． 如果想直接看執行的日誌資訊，可以使用一下命令：

Yarn  logs –applicationId <app ID>