YARN 原理簡介

YARN 組件

參考：Spark on Yarn | Spark，從入門到精通

YARN 採用 Master/Slave結構 ，包含ResourceManager 和 NodeManager
ResourceManager 是 Master;
NodeManager 是 Slave。

YARN的基本思想是將資源管理和做業調度/監視功能劃分爲單獨的守護進程。
其實現爲擁有一個全局ResourceManager (RM)和每一個應用程序的ApplicationMaster (AM)。
應用程序能夠是單個做業，也能夠是一組做業。
從大致看，YARN的調度架構能夠分爲兩層
第一層調度是ResourceManager 和 NodeManager；

第二層調度是 NodeManager 和 Container

經過採用雙層調度結構將 Scheduler 管理的資源由細粒度的 (cpu、內存、磁盤、網絡)變成了粗粒度的 Container，下降了負載。
在 App Manager 組件中也只須要管理 App Master，不須要管理任務調度執行的完整信息，一樣下降了負載。經過下降 ResourceManager 的負載，變相地提升了集羣的擴展性。
ResourceManager和NodeManager構成數據計算框架。ResourceManager是在系統中的全部應用程序之間仲裁資源的最終權威。NodeManager是每臺機器的框架代理，負責監視containers的資源使用狀況(cpu、內存、磁盤、網絡)，並向ResourceManager/Scheduler報告相同的狀況。
每一個應用程序ApplicationMaster其實是一個特定於框架的庫，它的任務是與ResourceManager協商資源，並與NodeManager一塊兒執行和監視任務。
ResourceManager有兩個主要組件:Scheduler和ApplicationsManager。

• Scheduler
  Scheduler負責根據密集的容量、隊列等約束將資源分配給各類正在運行的應用程序。
  Scheduler是純粹調度器，由於它不執行對應用程序狀態的監視或跟蹤。
  此外，它也不能保證因爲應用程序故障或硬件故障而從新啓動失敗的任務。
  Scheduler根據應用程序的資源需求執行調度功能;
  它是基於資源containers的抽象概念實現的，資源containers包含內存、cpu、磁盤、網絡等元素。
• ApplicationsManager
  ApplicationsManager負責接受做業提交，協商執行特定於應用程序的ApplicationMaster的第一個容器，並提供在出現故障時從新啓動ApplicationMaster容器的服務。
  每一個應用程序ApplicationMaster負責與調度程序協商適當的資源容器，跟蹤它們的狀態並監視進度。

---

Yarn 的運做流程

1. Client 向 ResourceManager 的 App Manager 提交應用並請求一個 AppMaster 實例；
2. App Manager 向 Scheduler 獲取能夠運行一個 Container 的 NodeManager
3. Scheduler 返回一個能夠運行一個 Container 的 NodeManager 給 App Manager
4. App Manager 在返回對 NodeManager 上啓動一個Container，並在這個Container上啓動 App Master 實例
5. App Master 向 App Manager註冊
6. 完成註冊客戶端就能夠查詢 ResourceManager 得到本身 App Master 的詳情以及直接和 App Master 交互
7. 根據交互狀況 App Master 向 向App Manager 請求資源，即 Container
8. App Manager 收到請求後從 Scheduler 獲取到分配資源的信息 返回給 App Master 。
9. App Master在對應的 NodeManager 上啓動 Container 並執行 Task
10. Container 執行過程當中會把運行進度和狀態等信息發送給 AppMaster
11. Client 和 App Master 交流應用的運行狀態、進度更新等信息
12. 全部任務完後成 App Master 向 App Manager 取消註冊而後關閉，同時全部的 Container 也歸還給系統。

---

Scheduler 策略

Scheduler 策略 有下列幾種：FIFO Scheduler、Capacity Scheduler、Fair Scheduler

• FIFO Scheduler
  若是沒有配置Scheduler 策略的話，全部的任務都提交到一個 default 隊列，根據它們的提交順序執行。
  若是資源充足執行任務，若資源緊張就等待前面的任務執行完畢後釋放資源，這就是 FIFO Scheduler 先入先出的分配方式。
  
• Capacity Scheduler
  Capacity Scheduler 是一種多租戶、彈性的分配方式。
  支持多個隊列，每一個隊列可配置必定量的資源，每一個採用FIFO的方式調度。
  每一個租戶一個隊列，每一個隊列能夠配置能使用的資源上限與下限（如 50%，達到這個上限後即便其餘的資源空置着，也不可以使用），經過配置能夠令隊列至少有資源下限配置的資源可以使用。
  
• Fair Scheduler
  Fair Scheduler 是一種公平的分配方式，所謂的公平就是集羣會盡量地按配置的比例分配資源給隊列。
  Job1 提交給隊列 A，它佔用了集羣的全部資源。
  接着 Job2 提交給了隊列 B，這時 Job1 就須要釋放它的一半的資源給隊列 A 中的 Job2 使用。
  接着 Job3 也提交給了隊列 B，這個時候 Job2 若是還未執行完畢的話也必須釋放一半的資源給 Job3。
  這就是公平的分配方式，在隊列範圍內全部任務享用到的資源都是均分的。
  

---

Yarn HA（容災備援）

1. Container 故障：Resource Manager 能夠分配其餘的 Container 繼續執行
   
2. App Master 故障：分配新的 Container，啓動 App Master，新的 App Master 從 App Manager 獲取相關恢復信息
3. NodeManager 故障：移除這個節點，在其餘的 NodeManager 重啓繼續任務。
4. ResourceManager 故障：在 Yarn 集羣中，ResourceManager 能夠啓動多臺，只有其中一臺是 active 狀態的，其餘都處於待命狀態。
   這臺 active 狀態的 ResourceManager 執行的時候會向 ZooKeeper 集羣寫入它的狀態；
   當它故障的時候這些 RM 首先選舉出另一臺 leader 變爲 active 狀態，而後從 ZooKeeper 集羣加載 ResourceManager 的狀態；
   在轉移的過程當中它不接收新的 Job，轉移完成後才接收新 Job。