Spark 集群相關
來源於官方, 可以理解為是官方譯文, 外加一點自己的理解. 版本是2.4.4
本篇文章涉及到:
- 集群概述
- master, worker, driver, executor的理解
- 打包提交,發布 Spark application
- standalone模式
- SparkCluster 啟動 及相關配置
- 資源, executor分配
- 開放網絡端口
- 高可用(Zookeeper)
名詞解釋
| Term（術語） | Meaning（含義） |
|---|---|
| Application | 用戶構建在 Spark 上的程序。由集群上的一個 driver 程序和多個 executor 組成。 |
| Driver program | 該進程運行應用的 main() 方法並且創建了 SparkContext。 |
| Cluster manager | 一個外部的用於獲取集群上資源的服務。（例如，Standlone Manager，Mesos，YARN） |
| Worker node | 任何在集群中可以運行應用代碼的節點。 |
| Executor | 一個為了在 worker 節點上的應用而啟動的進程，它運行 task 並且將數據保持在內存中或者硬盤存儲。每個應用有它自己的 Executor。 |
| Task | 一個將要被發送到 Executor 中的工作單元。 |
| Job | 一個由多個任務組成的並行計算，並且能從 Spark action 中獲取響應（例如 save，collect）; 您將在 driver 的日志中看到這個術語。 |
| Stage | 每個 Job 被拆分成更小的被稱作 stage（階段）的 task（任務）組，stage 彼此之間是相互依賴的（與 MapReduce 中的 map 和 reduce stage 相似）。您將在 driver 的日志中看到這個術語。 |
概述
參考鏈接: Cluster Mode Overview
中文鏈接: 集群模式概述
Spark Application 在集群上作為獨立的進程組來運行，在 main程序(稱之為 driver 程序） 中通過 SparkContext 來協調。
具體來說，為了運行在集群上，SparkContext 可以連接至幾種類型的 Cluster Manager（既可以用 Spark 自己的 Standlone Cluster Manager，或者 Mesos，也可以使用 YARN），用以在 applications 之間 分配資源。
一旦連接上，Spark 獲得集群中節點上的 Executor，這些進程可以運行計算並且為應用存儲數據。
接下來，它將發送 application 的代碼（通過 JAR 或者 Python 文件定義傳遞給 SparkContext）至 Executor。 而這一點大概也是 在 work目錄下, 每個application中都有對應的 jar包的原因. 最終，SparkContext 將發送 Task 到 Executor 以運行。
有這么幾點要注意的地方:
-
每個application擁有它自身的 executor 進程. 它們會保持在整個 application 的生命周期中並且在多個線程中運行 task. 這樣做的優點是 可以將 application 之間相互隔離, 無論是在 任務調度 層面(即driver, driver 負責任務調度.) 又或者是 executor的層面. 這意味着 如果沒有外部存儲機制, 各個 application之間是無法進行數據共享的.
-
Spark並不關心究竟是 基於怎樣的 集群模式, 它只關心 能夠獲取自身的 executor進程, 並且彼此之間可以相互通信即可.
-
Driver 程序必須在自己的生命周期內監聽和接受來自它的 Executor 的連接請求。（配置: spark.driver.port) 同樣的， 對於 worker node 而言, driver 程序也必須能夠從網絡中連接到.
-
因為 driver 負責在 整個集群上 調度任務， 因此能夠與 worker node 處於同一局域網下是更優的選擇(否則的話, 網絡通信可能就成為了 整個Spark最大的時間開銷)。如果你不喜歡發送請求到遠程的集群，倒不如打開一個 RPC 至 driver 並讓它就近提交操作而不是從很遠的節點上運行一個 driver。
在這里解決這樣一個比較問題: master, worker, driver, executor之間是什么樣的關系?
可以參考:
上面的博客是我看了幾篇之后, 覺得描述的比較准確的.
那么一點點來說: spark的application 運行需要一個環境, 也即spark本身.
而往往我們使用的就是集群環境, 集群環境中有多台機器, 多個進程, 這就需要一個管理器, 管理 多個master 和 多個 worker節點. 這個就是 cluster manager. 而我們直接通信的對象, 也就是 application 直接通信的對象 就是 master. 由master 來告訴我們 application 的可用資源在哪里.
一個集群中, 可以運行多個application.
當我們提交application之后, 會接入master, master分配給我們資源, 也即executor, main程序所在的進程. 就被稱作是 driver. driver 分配任務, 協調各個executor, 運行各個 task的就是 executor.
注意在這里並沒有指定driver究竟會運行在哪個節點上.
與選取的模式有關.
而master呢? 在master中注冊 application, driver, worker這三種資源, 而 executor資源是注冊在 driver中的, 新的worker加入, driver狀態變化, worker狀態變化 都會通告給 master 以重新協調資源.
我們會發現, executor在分配之后是與master無關的, 程序是運行在executor中的, driver並不一定運行在master中, 因此即使master掛掉, 程序也並不是就不能夠運行了.
master worker是集群中的物理資源分配, driver , executor 是對物理資源的使用. 在申請新的資源時, 需要向master申請, 在任務調度運行時, 則無需向master通報.
其實仔細想想, 在大多數集群的處理中, 都是采用這種模式, cluster manager負責集群的資源管理, 相互通信, master節點負責資源調度, 資源狀態變更處理, 而 application 是獨立於它們運行的, 一旦獲取到自己需要的資源, 就不和master進行通信了.
Cluster Manager 類型
系統目前支持三種 Cluster Manager:
Standalone – 包含在 Spark 中, 簡單易使用。
Apache Mesos – 一個通用的 Cluster Manager，它也可以運行 Hadoop MapReduce 和其它服務應用。
Hadoop YARN – Hadoop 2 中的 resource manager（資源管理器）。
Kubernetes (experimental)
Nomad: 存在第三方的項目(並非受到Spark項目支持的) 可以添加對應的集群支持.
提交應用程序
官方鏈接: Submitting Applications
中文鏈接: Submitting Applications
在 Spark的 bin 目錄中的spark-submit 腳本 用於 在集群上啟動應用程序。它可以通過一個統一的接口使用所有 Spark 支持的 cluster managers，所以您不需要專門的為每個cluster managers配置您的應用程序。
打包
打包的時候, 需要將程序自身的jar與 程序的 依賴jar一起進行打包, 這一點可以通過maven 的 shade / assembly 來實現. 在 項目中 將 spark 和 hadoop 的包 范圍權限定義為 provided即可.它們不需要被打包，因為在運行時它們已經被 Cluster Manager 提供了.
啟動
打包完成之后, 就可以通過 bin/spark-submit 進行提交了.
這個腳本負責設置 Spark 和它的依賴的 classpath，並且可以支持 Spark 所支持的不同的 Cluster Manager 以及 deploy mode（部署模式）:
./bin/spark-submit \
--class <main-class> \
--master <master-url> \
--deploy-mode <deploy-mode> \
--conf <key>=<value> \
... # other options
<application-jar> \
[application-arguments]
常用的參數有:
- --class：您的應用程序的入口點（例如 org.apache.spark.examples.SparkPi)
- --master：集群的 master URL（例如 spark://23.195.26.187:7077）
- --deploy-mode：是在 worker 節點（cluster）上還是在本地作為一個外部的客戶端（client）部署您的 driver（默認：client）
- --conf：按照 key=value 格式任意的 Spark 配置屬性。對於包含空格的 value（值）使用引號包 “key=value” 起來。
- application-jar：包括您的應用以及所有依賴的一個打包的 Jar 的路徑。該 URL 在您的集群上必須是全局可見的，例如，一個 hdfs:// path 或者一個 file:// 在所有節點是可見的。
- application-arguments：傳遞到您的 main class 的 main 方法的參數，如果有的話。
其中 參數順序並沒有嚴格要求, 但要求 jar路徑 必須在倒數第二 或 最后一個參數位置(如果不通過 application-jar 來指定的話).
有一些特定於所使用的集群管理器的可用選項 。例如，對於具有部署模式的Spark standalone Cluster，您還可以指定--supervise以確保驅動程序在非零退出代碼失敗的情況下自動重新啟動。要枚舉所有可用的此類選項，請使用來spark-submit運行它--help.
其中 StandaloneCluster的 可配置參數在稍后會有所說明.
Master URLS
| Master URL | Meaning |
|---|---|
| local | 使用一個線程本地運行 Spark（即，沒有並行性）。 |
| local[ K ] | 使用 K 個 worker 線程 在本地運行 Spark（理想情況下，設置這個值的數量為你的機器的 core 數量）。 |
| local[K, F] | 使用 K 個 worker 線程本地運行 Spark並允許最多失敗 F次（對於任意job失敗會進行重試, 重試次數等 F - 1) |
| local[ * ] | 使用與機器的 邏輯 core數量相等的 worker線程. |
| local[*, F] | 使用與機器的 邏輯 core數量相等的 worker線程. 並允許最多失敗 F次。 |
| spark://HOST:PORT | 連接至給定的 Spark standalone cluster master. master。該 port（端口）必須有一個作為您的 master 配置來使用，默認是 7077。 |
| spark://HOST1:PORT1,HOST2:PORT2 | 連接至給定的 Spark standalone cluster with standby masters with Zookeeper。該列表必須包含由zookeeper設置的高可用集群中的所有master主機。該 port（端口）必須有一個作為您的 master 配置來使用，默認是 7077。 |
| mesos://HOST:PORT | 連接至給定的 Mesos 集群。該 port（端口）必須有一個作為您的配置來使用，默認是 5050。或者，對於使用了 ZooKeeper 的 Mesos cluster 來說，使用 mesos://zk://...。使用 --deploy-mode cluster，來提交，該 HOST:PORT 應該被配置以連接到 MesosClusterDispatcher。 |
| yarn | 以 client 或 cluster 模式 連接至一個 YARN cluster, 模式取決於 --deploy-mode. 該 cluster 的位置將根據 HADOOP_CONF_DIR 或者 YARN_CONF_DIR 變量來找到。 |
| k8s://HOST:PORT | 以集群模式 連接至 k8s 集群, 在目前版本不支持設定客戶端模式(在將來會提供), HOST PORT 指向對應 k8s API服務, 默認使用 TSL連接. 如果不想使用 TSL, 需要強制指定 k8s://http://HOST:PORT. |
配置
spark-submit 腳本可以從一個 properties 文件加載默認的 Spark configuration values。默認情況下，它將從 Spark 目錄下的 conf/spark-defaults.conf 讀取配置.
加載默認的 Spark 配置，可以在提交時省略一部分參數, 例如，如果 spark.master 屬性被設置了，您可以在 spark-submit 中安全的省略 --master 配置. 一般情況下，明確設置在 SparkConf 上的配置值的優先級最高，然后是傳遞給 spark-submit的值，最后才是 default value（默認文件）中的值。
如果你不是很清楚其中的配置設置來自哪里，您可以通過使用 --verbose 選項來運行 spark-submit 打印出細粒度的調試信息.
高級依賴管理
並非只有把所有的需要的jar包都打包在一起這一種方式.
通過 --jars 選項包括的應用程序的 jar 和任何其它的 jar 都將被自動的傳輸到集群. --jars 后面提供的 URL 必須用逗號分隔。該列表會被包含到 driver 和 executor 的 classpath 中。 --jars 不支持目錄的形式。
URL有以下幾種方式:
-
file: 絕對路徑和 file:/ URI 通過 driver 的 HTTP file server 提供服務，並且每個 executor 會從 driver 的 HTTP server 拉取這些文件。
-
hdfs:, http:, https:, ftp: 指定下載 文件的 URI.
-
local: 一個用 local:/ 開頭的 URL, 要求作在每個 worker 節點上都存在。這樣意味着沒有網絡 IO 發生，並且非常適用於那些已經被推送到每個 worker 或通過 NFS，GlusterFS 等共享的大型的 file/JAR。
注意: JARS 和 files 被復制到 每個SparkContext 的 executor 節點 的 工作目錄. 在長時間的運行中, 所需要的空間會逐漸加大, 因此去清理掉這些文件. 在 YARN 模式下, 可以自動清理文件, 而在 standalone模式下, 需要在配置中加入spark.worker.cleanup.appDataTtl 用以自動清理.
Standalone 模式
官方文檔: Spark Standalone Mode
中文文檔: Spark Standalone Mode
由於在我們目前的項目中, 采用的就是 standalone模式, 因此只介紹這一種模式.
Spark 提供了一個簡單的 standalone 部署模式。你可以手動啟動 master 和 worker 來啟動 standalone 集群.
安裝 Spark Standalone 集群，只需要將編譯好的版本部署在集群中的每個節點上。
先回答一個問題:
在當前模式下, driver 是選取 幾個worker中的一個來運行相關進程, 並非是在master節點.
啟動Spark Cluster
通常來說, 我使用的啟動命令為:
${SPARK_HOME}/sbin/start-all.sh
會 加載配置文件, 啟動 spark master, spark slaves.
停止的時候, 也可以采用 stop-all.sh
注意: 這些腳本必須在您想要運行 Spark master 的機器上執行，而不是您本地的機器。
當然可以加入一部分配置文件, 指定參數配置:
比較重要的或有趣的我會標注出來.
-
conf/spark-env.sh
可以在復制 conf/spark-env.sh.template > spark-env.sh 中設置環境變量來進一步配置集群。
可接收參數有:
環境變量 含義 SPARK_MASTER_HOST 綁定 master 到一個指定的 hostname 或者 IP 地址 SPARK_MASTER_PORT 在不同的端口上啟動 master（默認：7077） SPARK_MASTER_WEBUI_PORT master的 web ui (默認: 8080) SPARK_MASTER_OPTS 僅應用到 master 上的配置屬性，格式是 "-Dx=y"（默認是：none）, 可用參數在下面會提到. SPARK_LOCAL_DIRS Spark 中 "scratch" space（暫存空間）的目錄，包括 map 的輸出文件 和 存儲在磁盤上的 RDDs, 我們知道內存溢出會根據策略, 有可能存儲在磁盤上. 這必須在你的系統中的一個快速的(不太明白這個快速的, 是什么意思?)，本地的磁盤上。這也可以是逗號分隔的不同磁盤上的多個目錄的列表。 SPARK_WORKER_CORES 機器上 所有 Spark 應用程序可以使用的的 cores 的總數.（默認：全部的核可用） SPARK_WORKER_MEMORY 機器上的 所有的 spark applications 允許使用的 總的內存, 默認是 機器內存 - 1GB; 而單個application的內存配置是由 spark.executor.memory 所決定的. SPARK_WORKER_PORT spark worker的端口, 默認是 隨機 SPARK_WORKER_WEBUI_PORT spark worker 的 web ui 端口, 默認是 (8081) SPARK_WORKER_DIR 運行application所在的路徑, 這個目錄中包含日志和暫存空間（default：SPARK_HOME/work） SPARK_WORKER_OPTS 與 SPARK_MASTER_OPTS 類似, 不過是應用於 worker SPARK_DAEMON_MEMORY 分配給 Spark master 和 worker 守護進程的內存。（默認： 1g） SPARK_DAEMON_JAVA_OPTS Spark master 和 worker 守護進程的 JVM 選項，格式是 "-Dx=y"（默認：none） SPARK_DAEMON_CLASSPATH Spark master 和 worker 守護進程的 classPath (default: none). SPARK_PUBLIC_DNS Spark master 和 worker 的公開 DNS 名稱(不是很理解)。（默認：none） 注意： 啟動腳本現在還不支持 Windows。要在 Windows 上運行一個 Spark 集群，需要手動啟動 master 和 workers。
但是不知為何, 我在運行 start-all的時候, 出現了 master 已經啟動, 但 worker不能啟動的問題.
最終的解決方式是將 在 Spark-env.sh中加入
export JAVA_HOME=$JAVA_PATH
才解決的這個問題, 因此 Spark-env.sh 不僅能夠用來容納所上述所提供的 部分參數, 還能夠指定, 提供Spark所需要的環境變量, 如 JAVA_HOME, SCALA_HOME, PYTHON_HOME 等等.
-
SPARK_MASTER_OPTS 參數
屬性名 默認值 含義 spark.deploy.retainedApplications 200 在 web ui上最大展示的 已經完成的 application數量. 超過限制的會被從UI中丟棄. spark.deploy.retainedDrivers 200 展示已完成的 drivers 的最大數量。舊的 driver 會從 UI 刪除掉以滿足限制。 spark.deploy.spreadOut true cluster mananger 是否將 多個 application 分配到不同的節點上 還是 盡量使用 越少的 節點越好(即整合操作). 默認true是分配到不同節點上. 對於數據在本地的 HDFS 文件中, 一般是盡量分離會比較好, 而對於 計算密集型 任務 來說, 使用盡量少的節點是 一種更好的選擇. spark.deploy.defaultCores (infinite) 如果沒有設置 spark.cores.max，在 Spark 的 standalone 模式下默認分配給應用程序的 cores（核）數。如果沒有設置，application 將總是獲得所有的可用核，除非application設置了 spark.cores.max。在共享集群中設置較低的核數，可用於防止用戶 grabbing（抓取）整個集群. spark.deploy.maxExecutorRetries 10 executor 連續多次的最大失敗次數, 一旦到達最大次數, cluster manager 將會 移除發生錯誤的 application. 如果 application 有任意正在運行的 executor 則永遠不會移除. 如果一個應用程序經歷過超過 spark.deploy.maxExecutorRetries 次的連續失敗，在這期間沒有executor成功開始運行，並且應用程序沒有運行着的executor，然后 cluster manager 將會移除這個應用程序並將它標記為失敗。如果要禁用功能的話, 設置為-1即可. spark.worker.timeout 60 master 接收 worker 心跳的最大時間間隔, 單位 秒. -
SPARK_WORKER_OPTS 參數
屬性名 默認值 含義 spark.worker.cleanup.enabled false 允許定期清理 worker / application 目錄. 僅在standalone模式有效,且僅對已經停止運行的 application有效. spark.worker.cleanup.interval 1800 (30 minutes) 在本地機器上，多久去檢測並清理一次，以秒計數. spark.worker.cleanup.appDataTtl 604800 (7 days, 7 * 24 * 3600) 對於每一個worker, 允許目錄存在的最大時間, 這應該取決於你磁盤 可分配的最大空間. 隨着時間的推移, 這個工作目錄會很快填滿磁盤空間, 特別是如果您經常運行jobs. spark.storage.cleanupFilesAfterExecutorExit true 在executor退出之后自動清除 工作目錄下的 non-shuffle 文件(例如: 臨時文件, shuffle blocks, 緩存的 RDD/broadcast blocks, spill files, 等等) of worker directories following executor exits. 注意與 spark.worker.cleanup.enabled 是不同的. 后者會清理所有超時的項目文件.僅在 standalone模式下有效. spark.worker.ui.compressedLogFileLengthCacheSize 100 對於壓縮日志文件，只能通過未壓縮文件來計算未壓縮文件。Spark 緩存未壓縮日志文件的文件大小。此屬性控制緩存的大小. -
要在 Spark 集群中運行一個應用程序，只需要簡單地將 master 的 spark://IP:PORT URL.
要針對集群運行交互式 Spark shell，運行下面的命令：
./bin/spark-shell --master spark://IP:PORT可以通過指定 --total-executor-cores numCores 控制集群中使用的 總的 cores數量.
提交application
對於 standalone 集群, park 目前支持兩種部署模式。在 client 模式下，driver 在與 client 提交應用程序相同的進程中啟動。
在 cluster 模式下，driver 是集群中的某個 Worker 中的進程中啟動，並且 client 進程將會在完成提交應用程序的任務之后退出，而不需要等待應用程序完成再退出。
如果應用程序是通過 Spark submit, application 會被 自動發送到所有的工作節點, 對於你所依賴的任何jar包, 可以通過 --jars 的方式傳入, 多個jar之間用,分割. 但正如之前 高級依賴管理 中提到的, 並不支持目錄形式.
standalone cluster 模式支持 自動重啟 application, 如果程序是以 非零代碼退出的話. 只需要在 submit的時候加入 --supervise 標識即可.如果您想殺死一個重復失敗的應用程序，您可以使用如下方式：
./bin/spark-class org.apache.spark.deploy.Client kill <master url> <driver ID>
資源分配
standalone 集群模式當前只支持一個簡單的跨應用程序的 FIFO 調度。然而，為了允許多個並發的用戶，您可以控制每個應用程序能用的最大資源數。默認情況下，它將獲取集群中的 all cores（核），這只有在某一時刻只允許一個應用程序運行時才有意義, 因為如果此時其他的核被占用, 自然無法獲取資源, 運行程序, 此時是有多少核用多少核.
您可以通過 spark.cores.max 在 SparkConf 中設置 cores（核）的數量。例如：
val conf = new SparkConf()
.setMaster(...)
.setAppName(...)
.set("spark.cores.max", "10")
val sc = new SparkContext(conf)
這樣就不用擔心一個application占用了集群所有的資源, 又因為在 FIFO 模式下, 導致其他application無法使用.
此外, 如果不想通過 spark.cores.max,也可以通過在集群的 master 進程中配置 spark.deploy.defaultCores 來修改的應用程序。通過添加下面的命令到 conf/spark-env.sh：
export SPARK_MASTER_OPTS="-Dspark.deploy.defaultCores=$value"
executor分配
每個executor的可使用 核心數 是 可配置的, 當 spark.executor.cores 被設置之后, 同一application的多個 executors 可能在同一台機器上運行, 在機器的 core 和 memory 資源充足的情況下.
否則 每個executor 會獲取 所有的可用 core, 當然 和 資源分配中提到的一致, 這需要在每次任務調度期間, 每個worker上的單個 application 只有 一個 executor.
監控 & 日志
監控自然是:
SPARK_MASTER_WEBUI_PORT 默認8080
SPARK_WORKER_WEBUI_PORT 默認8081, 如果8081已經被占用, 則會順延一位.
分別對應 master的web ui 和 worker的web ui
至於日志 則是在各個節點的 worker目錄.
配置網絡安全端口
通常來說, 一個 spark cluster 和 其服務 並不會放在公共網絡上, 一般都運行在私有服務內, 並且只能在部署Spark的組織網絡內訪問.
對Spark服務使用的主機和端口的訪問 應僅限於需要訪問服務的 原始主機.
這對於standalone來說更為重要, 因為這種模式並不支持 自由的 網絡資源控制.
可以參考鏈接:
同樣的關鍵部分, 與外界交互的端口, 用特殊顏色標注:
| 起始地址 | 目標地址 | 默認端口 | 用戶 | 配置 | 說明 |
|---|---|---|---|---|---|
| 瀏覽器 | standalone master | 8080 | WEBUI | spark.master.ui.port / SPARK_MASTER_WEBUI_PORT | 僅在 standalone模式使用 |
| 瀏覽器 | standalone Worker | 8081 | Web UI | spark.worker.ui.port | SPARK_WORKER_WEBUI_PORT |
| Driver / Standalone Worker | Standalone Master | 7077 | driver提交任務到 cluster/worker加入 cluster Submit job to cluster | SPARK_MASTER_PORT | |
| 外部服務 | Standalone Master | 6066 | 通過 REST API的方式提交任務到集群中. | spark.master.rest.port | 需要spark.master.rest.enabled 設置為 enabled. 僅在集群模式下使用. |
| Standalone Master | Standalone Worker | (random) | 調度分配 executors | SPARK_WORKER_PORT | 設置為0則二十隨機端口. 僅在 standalone模式下使用. |
| 瀏覽器 | application | 4040 | WebUI | spark.ui.port | |
| 瀏覽器 | 歷史服務: Spark學習筆記-使用Spark History Server | 18080 | Web UI | spark.history.ui.port | 所有模式 |
| Executor / Standalone Master | Driver | (random) | 連接到 application 或 發現 executor狀態變更 | spark.driver.port | 設置為0即是隨機端口, 所有模式可用. |
| Executor / Driver | Executor / Driver | (random) | Block Manager 端口 | spark.blockManager.port | 通過 ServerSocketChannelRaw socket |
高可用
一般來說, standalone 集群 調度 對於 worker的失敗都是有一定彈性的(會將 失去連接 的worker從 worker中移除, 並將任務分配給其他worker.) 然而, 調度器使用的是 master去進行調度決策, 並且（默認情況下）會產生一個單點故障: 如果master 一旦崩潰, 則不會有任何 application 能夠被創建, 為了規避這一點, 有如下兩個高可用性方案:
-
Zookeeper
使用zk提供 leader的選舉 和 存儲一些狀態. 我們可以通過 啟動 多個masters 並連接到同一個 Zookeeper, 其中一個master會被選舉為 leader, 其他的節點會維持在備用狀態, 如果當前leader宕機, 則會從備份中選取一個master作為 leader, 恢復master狀態, 並恢復調度. 從master宕機開始到另一個master恢復啟用, 應該會用1~2分鍾的時間.
注意 這種延遲僅僅會影響 調度新的 application, 在master掛掉期間, 正在運行的application是不受影響的.
配置:
為了啟用這個恢復模式，您可以在 spark-env 中設置 SPARK_DAEMON_JAVA_OPTS 通過配置 spark.deploy.recoveryMode 和相關的 spark.deploy.zookeeper.* 配置。
配置連接: zk配置
內容如下:
屬性名稱 默認值 含義 spark.deploy.recoveryMode NONE 恢復模式設置，用於在失敗並重新啟動時以集群模式恢復提交的Spark作業。這僅適用於與Standalone或Mesos一起運行的群集模式。 spark.deploy.zookeeper.url NONE 當spark.deploy.recoveryMode設置為ZOOKEEPER時，此配置用於設置要連接的Zookeeper URL. spark.deploy.zookeeper.dir NONE 當spark.deploy.recoveryMode設置為ZOOKEEPER時，此配置用於設置zookeeper 存儲狀態的目錄. 當你已經加入了ZK的相關配置之后, 實現高可用就是一件很簡單的事, 只需要啟動在 多個節點上 啟動 多個 master進程 配置同一個zk(包括url 和 目錄.), 可以在任意時間添加 或 移除 master.
為了添加新的 application 或 加入 新的 worker節點, 我們需要知道當前leader的 地址.這可以通過簡單地傳遞一個你在一個單一的進程中傳遞的 Masters 的列表來完成。
如:
spark://host1:port1, host2:port2, host3:port3
通過這種方式 就可以將所有的master注冊給 SparkContext了, 如果一個host掛掉, 通過這種方式就可以正確的找到 leader2.
在使用 Master 注冊 與 正常操作之間有一個重要的區別。當啟動的時候，一個 application 或者 Worker 需要找到當前的 lead Master 並 注冊.一旦它成功注冊，它就是 “在系統中” 了（即存儲在了 ZooKeeper 中）。如果發生故障切換，新的 leader 將會聯系所有之前已經注冊的應用程序和 Workers 來通知他們領導層的變化，所以他們甚至不知道新的 Master 在啟動時是否是否存在.
需要了解到的一個小細節就是， 在哪一台機器上先啟動master，哪個master就是主master（alive）狀態， 但這並不會影響driver節點所在的位置，以及 executor的分布， executor的分布與上面提到過的參數 spark.deploy.spreadOut 有關。
通過這個屬性, 新的master可以在任何時候被創建, 所以你唯一需要擔心的是, 新的application 和 worker 能夠找到它, 假設它成為了新的leader. 一旦成功注冊, 你就不需要擔心了.
- 本地文件的方式
Zookeeper是最佳方式, 因此我就不再這里介紹另一種方式了.
這種方式的目的是, 你僅僅只是想要在 master 掛掉之后, 選舉另一台master進行資源分配。