共計 2542 個字符，預(yù)計需要花費 7 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“Spark on yarn 執(zhí)行流程是怎樣的”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

很多公司都是通過 Yarn 來進行調(diào)度，mapreduce on yarn、spark on yarn、甚至 storm on yarn。

Yarn 集群分成兩種節(jié)點：

ResourceManager 負責(zé)資源的調(diào)度；

NodeManager 負責(zé)資源的分配、應(yīng)用程序執(zhí)行這些東西。

通過 Spark-submit 腳本來提交，用 yarn-client 提交模式，這種模式其實會在本地啟動起來 driver 程序

Spark on yarn 執(zhí)行流程

  我們寫的 spark 程序，打成 jar 包，用 spark-submit 來提交。jar 包中的一個 main 類，通過 jvm 的命令啟動起來。JVM 進程，這個進程，其實就是咱們的 Driver 進程。Driver 進程啟動起來以后，執(zhí)行我們自己寫的 main 函數(shù)，從 new SparkContext()。。。

在客戶端給我們啟動一個 driver

去 ResourceManager 申請啟動 container(資源)

通知一個 NodeManager 在 container 里面啟動 ApplicationMaster

ApplicationMaster 去找 ResourceManager 申請 Executor

ResourceManager 返回可以啟動的 NodeManager 的地址

ApplicationMaster 去找 NodeManager 啟動 Executor

Executor 進程會反過來去向 Driver 注冊上去

最后 Driver 接收到了 Executor 資源之后就可以去進行我們 spark 代碼的執(zhí)行了

執(zhí)行到某個 action 就觸發(fā)一個 JOB

DAGScheduler 會劃分 JOB 為一個個 Stage

TaskScheduler 會劃分 Stage 為一個個 Task

Task 發(fā)送到 Executor 執(zhí)行

Driver 就來進行 Task 的調(diào)度

Application-Master？？？

yarn 中的核心概念，任何要在 yarn 上啟動的作業(yè)類型（mr、spark），都必須有一個。每種計算框架（mr、spark），如果想要在 yarn 上執(zhí)行自己的計算應(yīng)用，那么就必須自己實現(xiàn)和提供一個 ApplicationMaster 相當(dāng)于是實現(xiàn)了 yarn 提供的接口，spark 自己開發(fā)的一個類

spark 在 yarn-client 模式下，application 的注冊（executor 的申請）和計算 task 的調(diào)度，是分離開來的。standalone 模式下，這兩個操作都是 driver 負責(zé)的。

ApplicationMaster(ExecutorLauncher) 負責(zé) executor 的申請；driver 負責(zé) job 和 stage 的劃分，以及 task 的創(chuàng)建、分配和調(diào)度

yarn-client 模式下，會產(chǎn)生什么樣的問題呢？

由于咱們的 driver 是啟動在本地機器的，而且 driver 是全權(quán)負責(zé)所有的任務(wù)的調(diào)度的，也就是說要跟 yarn 集群上運行的多個 executor 進行頻繁的通信（中間有 task 的啟動消息、task 的執(zhí)行統(tǒng)計消息、task 的運行狀態(tài)、shuffle 的輸出結(jié)果）。

咱們來想象一下。比如你的 executor 有 100 個，stage 有 10 個，task 有 1000 個。每個 stage 運行的時候，都有 1000 個 task 提交到 executor 上面去運行，平均每個 executor 有 10 個 task。接下來問題來了，driver 要頻繁地跟 executor 上運行的 1000 個 task 進行通信。通信消息特別多，通信的頻率特別高。運行完一個 stage，接著運行下一個 stage，又是頻繁的通信。

在整個 spark 運行的生命周期內(nèi)，都會頻繁的去進行通信和調(diào)度。所有這一切通信和調(diào)度都是從你的本地機器上發(fā)出去的，和接收到的。這是最要人命的地方。你的本地機器，很可能在 30 分鐘內(nèi)（spark 作業(yè)運行的周期內(nèi)），進行頻繁大量的網(wǎng)絡(luò)通信。那么此時，你的本地機器的網(wǎng)絡(luò)通信負載是非常非常高的。會導(dǎo)致你的本地機器的網(wǎng)卡流量會激增！！！

你的本地機器的網(wǎng)卡流量激增，當(dāng)然不是一件好事了。因為在一些大的公司里面，對每臺機器的使用情況，都是有監(jiān)控的。不會允許單個機器出現(xiàn)耗費大量網(wǎng)絡(luò)帶寬等等這種資源的情況。運維人員不會允許。可能對公司的網(wǎng)絡(luò)，或者其他（你的機器還是一臺虛擬機），如果你是一臺虛擬機的話，和其他機器共享網(wǎng)卡的話，可能對其他機器，公司整個網(wǎng)絡(luò)環(huán)境，都會有負面和惡劣的影響。

解決的方法：

實際上解決的方法很簡單，就是心里要清楚，yarn-client 模式是什么情況下，可以使用的？

yarn-client 模式，通常咱們就只會使用在測試環(huán)境中，你寫好了某個 spark 作業(yè)，打了一個 jar 包，在某臺測試機器上，用 yarn-client 模式去提交一下。因為測試的行為是偶爾為之的，不會長時間連續(xù)提交大量的 spark 作業(yè)去測試。還有一點好處，yarn-client 模式提交，可以在本地機器觀察到詳細全面的 log。通過查看 log，可以去解決線上報錯的故障（troubleshooting）、對性能進行觀察并進行性能調(diào)優(yōu)。

實際上線了以后，在生產(chǎn)環(huán)境中，都得用 yarn-cluster 模式，去提交你的 spark 作業(yè)。

yarn-cluster 模式，就跟你的本地機器引起的網(wǎng)卡流量激增的問題，就沒有關(guān)系了。也就是說，就算有問題，也應(yīng)該是 yarn 運維團隊和基礎(chǔ)運維團隊之間的事情了。他們?nèi)タ紤] Yarn 集群里面每臺機器是虛擬機還是物理機呢？網(wǎng)卡流量激增后會不會對其他東西產(chǎn)生影響呢？如果網(wǎng)絡(luò)流量激增，要不要給 Yarn 集群增加一些網(wǎng)絡(luò)帶寬等等這些東西。那就是他們倆個團隊的事情了，和你就沒有關(guān)系了

使用了 yarn-cluster 模式以后，

就不是你的本地機器運行 Driver，進行 task 調(diào)度了。是 yarn 集群中，某個節(jié)點會運行 driver 進程，負責(zé) task 調(diào)度。

“Spark on yarn 執(zhí)行流程是怎樣的”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實用文章！