您好,登錄后才能下訂單哦!
本篇內容介紹了“Spark on yarn執行流程是怎樣的”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
很多公司都是通過Yarn來進行調度,mapreduce on yarn、spark on yarn、甚至storm on yarn。
Yarn集群分成兩種節點:
ResourceManager負責資源的調度;
NodeManager負責資源的分配、應用程序執行這些東西。
通過Spark-submit腳本來提交,用yarn-client提交模式,這種模式其實會在本地啟動起來driver程序
Spark on yarn執行流程
我們寫的spark程序,打成jar包,用spark-submit來提交。jar包中的一個main類,通過jvm的命令啟動起來。JVM進程,這個進程,其實就是咱們的Driver進程。Driver進程啟動起來以后,執行我們自己寫的main函數,從new SparkContext()。。。
在客戶端給我們啟動一個driver
去ResourceManager申請啟動container(資源)
通知一個NodeManager在container里面啟動ApplicationMaster
ApplicationMaster去找ResourceManager申請Executor
ResourceManager返回可以啟動的NodeManager的地址
ApplicationMaster去找NodeManager啟動Executor
Executor進程會反過來去向Driver注冊上去
最后Driver接收到了Executor資源之后就可以去進行我們spark代碼的執行了
執行到某個action就觸發一個JOB
DAGScheduler會劃分JOB為一個個Stage
TaskScheduler會劃分Stage為一個個Task
Task發送到Executor執行
Driver就來進行Task的調度
Application-Master???
yarn中的核心概念,任何要在yarn上啟動的作業類型(mr、spark),都必須有一個。每種計算框架(mr、spark),如果想要在yarn上執行自己的計算應用,那么就必須自己實現和提供一個ApplicationMaster相當于是實現了yarn提供的接口,spark自己開發的一個類
spark在yarn-client模式下,application的注冊(executor的申請)和計算task的調度,是分離開來的。standalone模式下,這兩個操作都是driver負責的。
ApplicationMaster(ExecutorLauncher)負責executor的申請;driver負責job和stage的劃分,以及task的創建、分配和調度
yarn-client模式下,會產生什么樣的問題呢?
由于咱們的driver是啟動在本地機器的,而且driver是全權負責所有的任務的調度的,也就是說要跟yarn集群上運行的多個executor進行頻繁的通信(中間有task的啟動消息、task的執行統計消息、task的運行狀態、shuffle的輸出結果)。
咱們來想象一下。比如你的executor有100個,stage有10個,task有1000個。每個stage運行的時候,都有1000個task提交到executor上面去運行,平均每個executor有10個task。接下來問題來了,driver要頻繁地跟executor上運行的1000個task進行通信。通信消息特別多,通信的頻率特別高。運行完一個stage,接著運行下一個stage,又是頻繁的通信。
在整個spark運行的生命周期內,都會頻繁的去進行通信和調度。所有這一切通信和調度都是從你的本地機器上發出去的,和接收到的。這是最要人命的地方。你的本地機器,很可能在30分鐘內(spark作業運行的周期內),進行頻繁大量的網絡通信。那么此時,你的本地機器的網絡通信負載是非常非常高的。會導致你的本地機器的網卡流量會激增!!!
你的本地機器的網卡流量激增,當然不是一件好事了。因為在一些大的公司里面,對每臺機器的使用情況,都是有監控的。不會允許單個機器出現耗費大量網絡帶寬等等這種資源的情況。運維人員不會允許。可能對公司的網絡,或者其他(你的機器還是一臺虛擬機),如果你是一臺虛擬機的話,和其他機器共享網卡的話,可能對其他機器,公司整個網絡環境,都會有負面和惡劣的影響。
解決的方法:
實際上解決的方法很簡單,就是心里要清楚,yarn-client模式是什么情況下,可以使用的?
yarn-client模式,通常咱們就只會使用在測試環境中,你寫好了某個spark作業,打了一個jar包,在某臺測試機器上,用yarn-client模式去提交一下。因為測試的行為是偶爾為之的,不會長時間連續提交大量的spark作業去測試。還有一點好處,yarn-client模式提交,可以在本地機器觀察到詳細全面的log。通過查看log,可以去解決線上報錯的故障(troubleshooting)、對性能進行觀察并進行性能調優。
實際上線了以后,在生產環境中,都得用yarn-cluster模式,去提交你的spark作業。
yarn-cluster模式,就跟你的本地機器引起的網卡流量激增的問題,就沒有關系了。也就是說,就算有問題,也應該是yarn運維團隊和基礎運維團隊之間的事情了。他們去考慮Yarn集群里面每臺機器是虛擬機還是物理機呢?網卡流量激增后會不會對其他東西產生影響呢?如果網絡流量激增,要不要給Yarn集群增加一些網絡帶寬等等這些東西。那就是他們倆個團隊的事情了,和你就沒有關系了
使用了yarn-cluster模式以后,
就不是你的本地機器運行Driver,進行task調度了。是yarn集群中,某個節點會運行driver進程,負責task調度。
“Spark on yarn執行流程是怎樣的”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。