Livy探究(二) -- 運行模式

上一篇的例子採用Livy默認的Local模式運行Spark任務。本篇咱們嘗試一下其餘模式。由於修改配置文件須要重啓,而每次重啓服務都要設置SPARK_HOMEHADOOP_CONF_DIR比較麻煩。咱們首先修改一下conf/livy-env.shpython

cp conf/livy-env.sh.template conf/livy-env.sh
vi conf/livy-env.sh

# 將環境變量添加進來,每次重啓會自動使環境變量生效

HADOOP_CONF_DIR=/etc/hadoop/conf
SPARK_HOME=/home/spark-2.4.1-bin-hadoop2.7
許多apache軟件都採用一樣的套路,例如spark, zeppelin。因此弄的東西多了,即便沒有文檔指導也能猜想出配置的方式

Standalone集羣模式

首先咱們須要部署一個spark的standalone集羣,此處略過部署的過程。假設集羣的master地址以下:web

spark://vm3198:7077

修改conf/livy.conf,設置以下參數,指向部署好的spark集羣:apache

livy.spark.master = spark://vm3198:7077

重啓服務服務器

bin/livy-server stop
bin/livy-server start

用第一篇中的命令建立session,並運行兩個例子,能夠發現是可以成功的,這裏略過這個過程了。重點來看一看提交到集羣上的應用。觀察spark集羣上的應用咱們看到livy在集羣上提交了一個application叫livy-session-0restful

image.png

這個session關聯了1個driver和2個executor:session

image.png

driver其實運行在livy所在的服務器上,做爲livy的子進程,由livy管理。雖然從進程關係上與local模式沒什麼區別。可是咱們知道,本質上,local模式實際上是在一個進程中經過多個線程來運行driver和executor的;而standalone模式時,這個進程僅僅運行driver,而真正的job是在spark集羣運行的。顯然,standalone模式更合理一些。app

筆者嘗試經過修改livy.spark.deploy-mode = cluster,可是這種模式下沒法成功運行session。因此standalone模式中,只能採用client模式

yarn模式

咱們知道,生產環境最好配合yarn來運行spark任務。因此必需要實驗一下yarn模式。因爲yarn-client模式本質上與standalone區別不大。因此直接選擇yarn-cluster模式。oop

修改conf/livy.conf,設置以下參數,設置yarn-cluster模式:ui

livy.spark.master = yarn-cluster
後來經過日誌發現Warning: Master yarn-cluster is deprecated since 2.0. Please use master "yarn" with specified deploy mode instead. 因此更好的配置是 livy.spark.master = yarn,而且 livy.spark.deploy-mode = cluster

因爲咱們提早設置了HADOOP_CONF_DIR,因此顯然livy是能夠知道yarn的RM位置的。重啓livy後,建立一個session。咱們經過yarn的webui界面能夠看到啓動的Spark應用:spa

image.png

進一步到spark界面查看executor:

image.png

注意到此次一樣啓動了1個driver和2個executor,可是區別在於driver並非啓動在livy所在服務器的。這與yarn-cluster模式的行爲一直。

再次查看livy的webui,看到剛剛建立的這個應用:

image.png

這裏注意到一個細節,Logs列有兩個連接,一個是session,一個是drvier。點進去看,能夠察覺到:

  • session日誌顯示的是提交spark任務時client打印的日誌
  • drvier日誌跳轉到yarn日誌,顯示的是driver運行輸出的日誌

進一步,咱們仍是經過python代碼提交兩個job。查看ui界面看到兩個任務已經執行成功:

image.png

查看livy服務器上與livy有關的進程,以前不管是local模式仍是standalone模式都存在一個SparkSubmit進程。而此次,在yarn-cluster模式下,並無這個進程。那麼問題來了,咱們經過restful接口,提交的代碼,到底是如何傳輸到driver進程,並執行的呢?觀察日誌咱們大概找到寫蛛絲馬跡。在driver端,找到以下日誌:

...
20/10/01 20:04:18 INFO driver.RSCDriver: Connecting to: vm3198:10000
20/10/01 20:04:18 INFO driver.RSCDriver: Starting RPC server...
20/10/01 20:04:18 INFO rpc.RpcServer: Connected to the port 10001
...

帶着這些問題,下一篇咱們一塊兒去源碼中找一下線索。

總結

本篇咱們分別針對standalone和yarn-cluster模式,實驗了livy的工做方式。瞭解了livy是如何支持多種運行模式的。

相關文章
相關標籤/搜索