Spark集羣-Standalone 模式

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 以運行。

有這麼幾點要注意的地方:

1. 每一個application擁有它自身的 executor 進程. 它們會保持在整個 application 的生命週期中而且在多個線程中運行 task. 這樣作的優勢是 能夠將 application 之間相互隔離, 不管是在 任務調度 層面(即driver, driver 負責任務調度.) 又或者是 executor的層面. 這意味着 若是沒有外部存儲機制, 各個 application之間是沒法進行數據共享的.

2. Spark並不關心到底是 基於怎樣的 集羣模式, 它只關心 可以獲取自身的 executor進程, 而且彼此之間能夠相互通訊便可.

3. Driver 程序必須在本身的生命週期內監聽和接受來自它的 Executor 的鏈接請求。（配置: spark.driver.port) 一樣的， 對於 worker node 而言, driver 程序也必須可以從網絡中鏈接到.

4. 由於 driver 負責在 整個集羣上 調度任務， 所以可以與 worker node 處於同一局域網下是更優的選擇(不然的話, 網絡通訊可能就成爲了 整個Spark最大的時間開銷)。若是你不喜歡發送請求到遠程的集羣，倒不如打開一個 RPC 至 driver 並讓它就近提交操做而不是從很遠的節點上運行一個 driver。

在這裏解決這樣一個比較問題: master, worker, driver, executor之間是什麼樣的關係?

能夠參考:

Spark中master、worker、executor和driver的關係

Spark源碼之Master

上面的博客是我看了幾篇以後, 以爲描述的比較準確的.

那麼一點點來講: 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 的機器上執行，而不是您本地的機器。

固然能夠加入一部分配置文件, 指定參數配置:

比較重要的或有趣的我會標註出來.

1. 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 等等.

1. 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 心跳的最大時間間隔, 單位 秒.

2. 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 緩存未壓縮日誌文件的文件大小。此屬性控制緩存的大小.

3. 要在 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 可以被建立, 爲了規避這一點, 有以下兩個高可用性方案:

1. 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能夠在任什麼時候候被建立, 因此你惟一須要擔憂的是, 新的application 和 worker 可以找到它, 假設它成爲了新的leader. 一旦成功註冊, 你就不須要擔憂了.

   1. 本地文件的方式

   Zookeeper是最佳方式, 所以我就再也不這裏介紹另外一種方式了.

   這種方式的目的是, 你僅僅只是想要在 master 掛掉以後, 重啓master.

   Single-Node Recovery with Local File System 的最後一部分.