Spark on Yarn ｜ Spark，從入門到精通

 

?/ 爲何須要 Yarn？ /?

 

Yarn?的全稱是?Yet Anther Resource Negotiator（另外一種資源協商者）。它做爲 Hadoop?的一個組件，官方對它的定義是一個工做調度和集羣資源管理的框架。

 

Yarn?最先出現於?Hadoop 0.23?分支中，0.23?分支是一個實驗性分支，以後通過了幾回迭代，最後發佈於?2014?年?6?月的?0.23.11?版本(該分支的最後一個版本)。在?0.23.0?發佈後不久的?2011?年?12?月，Hadoop?的 0.20?分支發展成了?Hadoop1.0，一直到?1.0?的最後一個版本?1.2.1-stable?都沒有出現?Yarn?的身影，而在?Hadoop2.0?的第一個版本?2.0.0-alpha，Yarn?已經做爲一個正式組件加入。在?2.0.2-alpha?版本，它已經支持了?2k?臺機器的集羣，接着在?2.0.3-alpha?版本中已經能夠支持?30k?臺機器的集羣。在?2.0.3-alpha?版本中同時還支持了多種資源，如?cpu&memory?的調度和?ResourceManager restart。

 

圖 1，via?https://blog.csdn.net/suifeng3051/article/details/49364677

 

如圖 1 所示，?Hadoop1.0?的運做流程以下：

1.客戶端提交任務給集羣；

2.JobTracker?接收?Job?請求；

3.JobTracker?根據?Job?的輸入參數向?NameNode?請求包含這些文件數據塊的?DataNode?節點列表；

4.JobTracker?肯定?Job?的執行計劃：確認?Map、Reduce?的?Task?數量，並分配?Task?到離數據塊最近的節點上執行。

 

最初，Hadoop1.0 可以很好地支撐大數據計算，可是隨着計算規模的擴大和計算模型的多樣化，它逐漸力不從心。衆所周知當集羣性能不足的時候能夠簡單粗暴地加機器，但?JobTracker?同時部署多個時只有一個是處於?active 狀態，所以受限於這個?active JobTracker?的負載上限，整個集羣可以容納的機器也有限，有數據顯示整個集羣的管理上限約爲?4k?臺機器。同時應用程序相關和資源管理相關的邏輯所有放在?JobTracker中，當集羣規模擴大的時候，會存在一個瓶頸。除此以外，Map-Reduce?計算模型與?JobTracker?的耦合太高，其餘計算模型難以在?Hadoop1.0?上運行。

 

Yarn 是 Hadoop 基於這些問題的一個解決方案，接下來經過了解 Yarn 的組件、架構以及運做機制來分析 Yarn 是如何解決這些問題的。

 

?/ Yarn 是什麼？ /?

 

Yarn 的組件&基本架構

 

如圖 2 所示 Yarn?採用?Master/Slave?結構，總體採用雙層調度架構。在第一層的調度是?ResourceManager?和?NodeManager：ResourceManager?是?Master?節點，至關於?JobTracker，包含?Scheduler?和App Manager?兩個組件，分管資源調度和應用管理；NodeManager?是?Slave?節點，能夠部署在獨立的機器上，用於管理機器上的資源。NodeManager?會向?ResourceManager?報告它的資源數量、使用狀況，並接受?ResourceManager?的資源調度。

*ResourceManager?同?JobTracker?同樣能夠多機部署，而且只有一臺處於?active?狀態。可是在?ResourceManager?中將調度管理和應用管理做了拆分，兩個組件的功能更專注。

 

圖 2

 

第二層的調度指的是?NodeManager?和?Container。NodeManager?會將?Cpu&內存等資源抽象成一個個的?Container，並管理它們的生命週期。

 

經過採用雙層調度結構將?Scheduler?管理的資源由細粒度的?Cpu&內存變成了粗粒度的?Container，下降了負載。在?App Manager?組件中也只須要管理?App Master，不須要管理任務調度執行的完整信息，一樣下降了負載。經過下降?ResourceManager?的負載，變相地提升了集羣的擴展性。

 

Yarn 運做流程

 

圖 3，via?https://blog.csdn.net/suifeng3051/article/details/49486927

 

如圖 3 所示 Yarn 的運做流程以下：

1.客戶端向?ResourceManager?的?App Manager?提交應用並請求一個?AppMaster?實例；

2.ResourceManager 找到能夠運行一個 Container 的 NodeManager，並在這個 Container 中啓動 AppMaster 實例；

3.App Master 向 ResourceManager 註冊，註冊以後，客戶端就能夠查詢 ResourceManager 得到本身 App Master 的詳情以及直接和 App Master 交互；

4.接着 App Master 向 Resource Manager 請求資源，即 Container；

5.得到 Container 後，App Master 啓動 Container，並執行 Task；

6.Container 執行過程當中會把運行進度和狀態等信息發送給 AppMaster；

7.客戶端主動和 App Master 交流應用的運行狀態、進度更新等信息；

8.全部工做完成 App Master 向 RM 取消註冊而後關閉，同時全部的 Container 也歸還給系統。

 

經過這個?Job?的處理過程能夠看到?App Master?是做爲?Job?的驅動角色，它驅動了?Job?任務的調度執行。在這個運做流程中，App Manager?只須要管理?App Master?的生命週期以及保存它的內部狀態，而?App Master?這個角色的抽象使得每種類型的應用均可以定製本身的?App Master，這樣其餘的計算模型就能夠相對容易地運行在?Yarn?集羣上。

 

Yarn HA（容災備援）

 

接下來介紹的是 Yarn 集羣高可用中關於容錯備援的設計。根據圖 3 所示的 Yarn 架構圖，假如 Container 故障 Resource Manager 能夠分配其餘的 Container 繼續執行，當運行 App Master 的 Container 故障後也將分配新的 Container，App Master 能夠從 App Manager 獲取信息恢復。當 NodeManager 故障的時候系統能夠先把這個節點移除，在其餘 NodeManager 重啓再繼續任務。

 

圖 4，via?https://www.cnblogs.com/sodawoods-blogs/p/8715231.html

 

那麼當?ResourceManager?故障的時候呢？如上文所說的在 Yarn 集羣中，ResourceManager 能夠啓動多臺，只有其中一臺是 active 狀態的，其餘都處於待命狀態。這臺 active 狀態的?ResourceManager 執行的時候會向 ZooKeeper 集羣寫入它的狀態，當它故障的時候這些 RM 首先選舉出另一臺 leader 變爲 active 狀態，而後從 ZooKeeper?集羣加載 ResourceManager 的狀態。在轉移的過程當中它不接收新的 Job，轉移完成後才接收新 Job。

 

?/ Spark on Yarn /?

 

首先介紹?Spark?的資源管理架構。Spark?集羣考慮到了將來對接一些更強大的資源管理系統（如?Yarn、Mesos?等）沒有在資源管理的設計上對外封閉，因此Spark?架構設計時將資源管理抽象出了一層，經過這種抽象可以構建一種插件式的資源管理模塊。

 

圖 5，via?http://shiyanjun.cn/archives/1545.html

 

如圖 5 所示是 Spark?的資源管理架構圖。Master?是?Spark?的 主控節點，在實際的生產環境中會有多個?Master，只有一個?Master?處於?active?狀態。Worker?是?Spark?的工做節點，向?Master?彙報自身的資源、Executeor?執行狀態的改變，並接受?Master?的命令啓動?Executor?或?Driver。Driver?是應用程序的驅動程序，每一個應用包括許多小任務，Driver?負責推進這些小任務的有序執行。Executor?是?Spark?的工做進程，由?Worker 監管，負責具體任務的執行。

 

以上就是?Spark?在資源管理上的抽象出來的架構，這個架構跟?Yarn?的架構十分類似，所以 Spark 很容易地構建於?Yarn?之上。在?Spark?和?Yarn?兩邊的角色對比中：Master?和?ResourceManager?對應，Worker?和?NodeManager?對應，Driver?和?App Master?對應，Executor?和?Container?對應。

 

根據?Spark?部署模式的不一樣資源管理架構也會有不一樣的形態。Spark 大體包括四種部署模式：

 

接着看看?Spark on Yarn?對?Job?的處理過程。客戶端提交一個任務給?Yarn ResourceManager?後，App Manager?接受任務並找到一個?Container?建立App Master，此時?App Master?上運行的是?Spark Driver。以後?App Master?申請?Container?並啓動，Spark Driver?在?Container?上啓動?Spark Executor，並調度?Spark Task?在?Spark Executor?上運行，等到全部的任務執行完畢後，向?App Manager?取消註冊並釋放資源。

 

圖 6，via https://www.iteblog.com/archives/1223.html

 

能夠看出這個執行流程和?Yarn?對一個任務的處理過程幾乎一致，不一樣的是在?Spark on Yarn?的?Job?處理過程當中?App Master、Container?是交由?Spark?相對應的角色去處理的。

 

圖 7，via https://www.iteblog.com/archives/1223.html

 

Spark on?Yarn?還有另一種運行模式：Spark on Yarn-Client。不一樣於上述的?Spark on Yarn-Cluster，Spark on Yarn-Client?的客戶端在提交完任務以後不會將?Spark Driver?託管給?Yarn，而是在客戶端運行。App Master?申請完?Container?以後一樣也是由?Spark Driver?去啓動?Spark Executor，執行任務。

 

那爲何使用?Yarn?做爲?Spark?的資源管理呢？咱們來對比?Spark?集羣模式?Standalone?和?Spark on Yarn?在資源調度能力上的區別：Spark?的?Standalone?模式只支持?FIFO?調度器，單用戶串行，默認全部節點的全部資源對應用都是可用的；而?Yarn?不止支持?FIFO?的資源調度，還提供了彈性和公平的資源分配方式。

 

Yarn 是經過將資源分配給?queue?來進行資源分配的，每一個?queue?能夠設置它的資源分配方式，接着展開介紹?Yarn?的三種資源分配方式。

 

FIFO Scheduler

 

若是沒有配置策略的話，全部的任務都提交到一個 default 隊列，根據它們的提交順序執行。富裕資源就執行任務，若資源不富裕就等待前面的任務執行完畢後釋放資源，這就是?FIFO Scheduler 先入先出的分配方式。

 

圖 8，via https://blog.csdn.net/suifeng3051/article/details/49508261

 

如圖 8 所示，在 Job1 提交時佔用了全部的資源，不久後 Job2提交了，可是此時系統中已經沒有資源能夠分配給它了。加入 Job1 是一個大任務，那麼 Job2 就只能等待一段很長的時間才能得到執行的資源。因此先入先出的分配方式存在一個問題就是大任務會佔用不少資源，形成後面的小任務等待時間太長而餓死，所以通常不使用這個默認配置。

 

Capacity Scheduler

 

Capacity Scheduler 是一種多租戶、彈性的分配方式。每一個租戶一個隊列，每一個隊列能夠配置能使用的資源上限與下限（譬如 50%，達到這個上限後即便其餘的資源空置着，也不可以使用），經過配置能夠令隊列至少有資源下限配置的資源可以使用。

 

圖 9，via https://blog.csdn.net/suifeng3051/article/details/49508261

 

圖 9 中隊列 A 和隊列 B 分配了相互獨立的資源。Job1 提交給隊列 A 執行，它只能使用隊列 A 的資源。接着 Job2 提交給了隊列B 就沒必要等待 Job1 釋放資源了。這樣就能夠將大任務和小任務分配在兩個隊列中，a-level這兩個隊列的資源相互獨立，就不會形成小任務餓死的狀況了。

 

Fair Scheduler

 

Fair Scheduler 是一種公平的分配方式，所謂的公平就是集羣會儘量地按配置的比例分配資源給隊列。

 

圖 10，via https://blog.csdn.net/suifeng3051/article/details/49508261

 

圖 10 中?Job1 提交給隊列 A，它佔用了集羣的全部資源。接着 Job2 提交給了隊列 B，這時 Job1 就須要釋放它的一半的資源給隊列 A 中的 Job2 使用。接着 Job3 也提交給了隊列 B，這個時候 Job2 若是還未執行完畢的話也必須釋放一半的資源給 Job3。這就是公平的分配方式，在隊列範圍內全部任務享用到的資源都是均分的。

 

Mesos 的資源調度和 Yarn 相似，可是它提供了粗粒度和細粒度的兩種模式。所謂的粗粒度和細粒度的差異在於：Executor 申請的資源是在執行前申請，仍是在執行過程當中按需申請。集羣資源緊張時可能有一個 Executor 申請的資源在當時處於閒置狀態，若是處於粗粒度模式下，這些資源在當時就浪費了。可是在細粒度模式下，Executor 執行時所需的資源是按照它的需求分配的，這樣就不存在資源閒置的狀況了。

 

由於 Mesos 的 Executor 是能夠動態調整，而 Yarn 使用的 Container 是不能夠動態調整的，因此目前 Yarn 是不支持細粒度的調度模式的，但 Yarn 已經有計劃支持細粒度的資源管理方式。

 

除此以外在 Hadoop3.1.0 中 Yarn 提供了對 gpu 資源的支持，目前只支持 Nvidia gpu。期待 Spark 在其餘方面的更多探索，下一篇咱們將具體介紹 RDD，歡迎持續關注。

轉載聲明：本文轉載自「美圖數據技術團隊」，搜索「美圖數據技術團隊」便可關注。

---

文章來源：https://blog.csdn.net/rlnLo2pNEfx9c/article/details/82599224