看了之后不再迷糊-Spark多種運行模式

早就想寫這章了,一直懶得動筆,不過還好,總算靜下心來完成了。

剛接觸Spark時,很希望能對它的運行方式有個直觀的了解,而Spark同時支持多種運行模式,官網和書籍中對他們的區別所說不詳,尤其是模式之間是否有關聯、啟動的JVM進程是否有區別、啟動的JVM進程的作用是否都一樣,等等這些都沒有說明,也沒有現成的資料可以查詢。

所以,我今天總結一下,供新手參考和學習(下述結論基于Spark2.1.0版本和hadoop2.7.3版本)

1,測試或實驗性質的本地運行模式 (單機)

該模式被稱為Local[N]模式,是用單機的多個線程來模擬Spark分布式計算,通常用來驗證開發出來的應用程序邏輯上有沒有問題。

其中N代表可以使用N個線程,每個線程擁有一個core。如果不指定N,則默認是1個線程(該線程有1個core)。

如果是local[*],則代表 Run Spark locally with as many worker threads as logical cores on your machine.

如下:

spark-submit 和 spark-submit --master local 效果是一樣的

(同理:spark-shell 和 spark-shell --master local 效果是一樣的)

spark-submit --master local[4] 代表會有4個線程(每個線程一個core)來并發執行應用程序。

那么,這些線程都運行在什么進程下呢?后面會說到,請接著往下看。

運行該模式非常簡單,只需要把Spark的安裝包解壓后,改一些常用的配置即可使用,而不用啟動Spark的Master、Worker守護進程( 只有集群的Standalone方式時,才需要這兩個角色),也不用啟動Hadoop的各服務(除非你要用到HDFS),這是和其他模式的區別哦,要記住才能理解。

那么,這些執行任務的線程,到底是共享在什么進程中呢?

我們用如下命令提交作業:

spark-submit --class JavaWordCount --master local[10] JavaWordCount.jar file:///tmp/test.txt?

可以看到,在程序執行過程中,只會生成一個SparkSubmit進程。


這個SparkSubmit進程又當爹、又當媽,既是客戶提交任務的Client進程、又是Spark的driver程序、還充當著Spark執行Task的Executor角色。(如下圖所示:driver的web ui)


這里有個小插曲,因為driver程序在應用程序結束后就會終止,那么如何在web界面看到該應用程序的執行情況呢,需要如此這般:(如下圖所示)

先在spark-env.sh 增加SPARK_HISTORY_OPTS;

然后啟動start-history-server.sh服務;

就可以看到啟動了HistoryServer進程,且監聽端口是18080。

之后就可以在web上使用http://hostname:18080愉快的玩耍了。

想必你們已經清楚了第一種運行模式了吧,我們接著往下說。

2,測試或實驗性質的本地偽集群運行模式(單機模擬集群)

這種運行模式,和Local[N]很像,不同的是,它會在單機啟動多個進程來模擬集群下的分布式場景,而不像Local[N]這種多個線程只能在一個進程下委屈求全的共享資源。通常也是用來驗證開發出來的應用程序邏輯上有沒有問題,或者想使用Spark的計算框架而沒有太多資源。

用法是:提交應用程序時使用local-cluster[x,y,z]參數:x代表要生成的executor數,y和z分別代表每個executor所擁有的core和memory數。

? spark-submit --master local-cluster[2, 3, 1024]

(同理:spark-shell --master local-cluster[2, 3, 1024]用法也是一樣的)

上面這條命令代表會使用2個executor進程,每個進程分配3個core和1G的內存,來運行應用程序。可以看到,在程序執行過程中,會生成如下幾個進程:

SparkSubmit依然充當全能角色,又是Client進程,又是driver程序,還有點資源管理的作用。生成的兩個CoarseGrainedExecutorBackend,就是用來并發執行程序的進程。它們使用的資源如下:

運行該模式依然非常簡單,只需要把Spark的安裝包解壓后,改一些常用的配置即可使用。而不用啟動Spark的Master、Worker守護進程( 只有集群的standalone方式時,才需要這兩個角色),也不用啟動Hadoop的各服務(除非你要用到HDFS),這是和其他模式的區別哦,要記住才能理解。下面說說集群上的運行模式。

3,Spark自帶Cluster Manager的Standalone Client模式(集群)

終于說到了體現分布式計算價值的地方了!(有了前面的基礎,后面的內容我會稍微說快一點,只講本文的關注點)

和單機運行的模式不同,這里必須在執行應用程序前,先啟動Spark的Master和Worker守護進程。不用啟動Hadoop服務,除非你用到了HDFS的內容。

start-master.sh

start-slave.sh -h hostname url:master

圖省事,可以在想要做為Master的節點上用start-all.sh一條命令即可,不過這樣做,和上面的分開配置有點差別,以后講到數據本地性如何驗證時會說。

啟動的進程如下:(其他非Master節點上只會有Worker進程)

這種運行模式,可以使用Spark的8080 web ui來觀察資源和應用程序的執行情況了。

可以看到,當前環境下,我啟動了8個worker進程,每個可使用的core是2個,內存沒有限制。

言歸正傳,用如下命令提交應用程序

spark-submit --master spark://wl1:7077

或者 spark-submit --master spark://wl1:7077 --deploy-mode client

代表著會在所有有Worker進程的節點上啟動Executor來執行應用程序,此時產生的JVM進程如下:(非master節點,除了沒有Master、SparkSubmit,其他進程都一樣)

Master進程做為cluster manager,用來對應用程序申請的資源進行管理;

SparkSubmit 做為Client端和運行driver程序;

CoarseGrainedExecutorBackend 用來并發執行應用程序;

注意,Worker進程生成幾個Executor,每個Executor使用幾個core,這些都可以在spark-env.sh里面配置,此處不在啰嗦。

這是driver web ui的顯示,可以看到每個executor的資源使用情況


4,spark自帶cluster manager的standalone cluster模式(集群)

這種運行模式和上面第3個還是有很大的區別的。使用如下命令執行應用程序(前提是已經啟動了spark的Master、Worker守護進程)不用啟動Hadoop服務,除非你用到了HDFS的內容。

spark-submit --master spark://wl1:6066 --deploy-mode cluster

各節點啟動的JVM進程情況如下:

master節點上的進程

提交應用程序的客戶端上的進程

某worker節點上的進程

客戶端的SparkSubmit進程會在應用程序提交給集群之后就退出(區別1)

Master會在集群中選擇一個Worker進程生成一個子進程DriverWrapper來啟動driver程序(區別2)

而該DriverWrapper 進程會占用Worker進程的一個core,所以同樣的資源下配置下,會比第3種運行模式,少用1個core來參與計算(觀察下圖executor id 7的core數)(區別3)

應用程序的結果,會在執行driver程序的節點的stdout中輸出,而不是打印在屏幕上(區別4)

5,基于YARN的Resource Manager的Client模式(集群)

現在越來越多的場景,都是Spark跑在Hadoop集群中,所以為了做到資源能夠均衡調度,會使用YARN來做為Spark的Cluster Manager,來為Spark的應用程序分配資源。

在執行Spark應用程序前,要啟動Hadoop的各種服務。由于已經有了資源管理器,所以不需要啟動Spark的Master、Worker守護進程。相關配置的修改,請自行研究。

使用如下命令執行應用程序

spark-submit --master yarn?

或者 spark-submit --master yarn --deploy-mode client

提交應用程序后,各節點會啟動相關的JVM進程,如下:

在Resource Manager節點上提交應用程序,會生成SparkSubmit進程,該進程會執行driver程序。

RM會在集群中的某個NodeManager上,啟動一個ExecutorLauncher進程,來做為

ApplicationMaster。另外,也會在多個NodeManager上生成CoarseGrainedExecutorBackend進程來并發的執行應用程序。

對應的YARN資源管理的單元Container,關系如下:

為ApplicationMaster生成了容器 000001;

為CoarseGrainedExecutorBackend生成了容器 000002-000003

6,基于YARN的Resource Manager的Custer模式(集群)

使用如下命令執行應用程序:

spark-submit --master yarn --deploy-mode cluster

和第5種運行模式,區別如下:

在Resource Manager端提交應用程序,會生成SparkSubmit進程,該進程只用來做Client端,應用程序提交給集群后,就會刪除該進程。

Resource Manager在集群中的某個NodeManager上運行ApplicationMaster,該AM同時會執行driver程序。緊接著,會在各NodeManager上運行CoarseGrainedExecutorBackend來并發執行應用程序。

應用程序的結果,會在執行driver程序的節點的stdout中輸出,而不是打印在屏幕上。

對應的YARN資源管理的單元Container,關系如下:

為ApplicationMaster生成了容器 000001

為CoarseGrainedExecutorBackend生成了容器 000002-000003

當然,3-6這幾種運行模式,你也可以在一臺單機上玩,前提是你的服務器足夠牛,同時你也足夠無聊。

歡迎指正,轉載請標明作者和出處,謝謝。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容