常見(jiàn)的Spark面試題

Spark

1. 通常來(lái)說(shuō)，Spark與MapReduce相比，Spark運(yùn)行效率更高。請(qǐng)說(shuō)明效率更高來(lái)源于Spark內(nèi)置的哪些機(jī)制？

2. hadoop和spark使用場(chǎng)景？

3. spark如何保證宕機(jī)迅速恢復(fù)?

4. hadoop和spark的相同點(diǎn)和不同點(diǎn)？

5. RDD持久化原理？

6. checkpoint檢查點(diǎn)機(jī)制？

7. checkpoint和持久化機(jī)制的區(qū)別？

8. RDD機(jī)制理解嗎？

9. Spark streaming以及基本工作原理？

10. DStream以及基本工作原理？

11. spark有哪些組件？

12. spark工作機(jī)制？

13. 說(shuō)下寬依賴和窄依賴

14. Spark主備切換機(jī)制原理知道嗎？

15. spark解決了hadoop的哪些問(wèn)題？

16. 數(shù)據(jù)傾斜的產(chǎn)生和解決辦法？

17. 你用sparksql處理的時(shí)候， 處理過(guò)程中用的dataframe還是直接寫(xiě)的sql？為什么？

18. 現(xiàn)場(chǎng)寫(xiě)一個(gè)筆試題

19. RDD中reduceBykey與groupByKey哪個(gè)性能好，為什么

20. Spark master HA主從切換過(guò)程不會(huì)影響到集群已有作業(yè)的運(yùn)行，為什么

21. spark master使用zookeeper進(jìn)行ha，有哪些源數(shù)據(jù)保存到Zookeeper里面

1. 通常來(lái)說(shuō)，Spark與MapReduce相比，Spark運(yùn)行效率更高。請(qǐng)說(shuō)明效率更高來(lái)源于Spark內(nèi)置的哪些機(jī)制？

spark是借鑒了Mapreduce,并在其基礎(chǔ)上發(fā)展起來(lái)的，繼承了其分布式計(jì)算的優(yōu)點(diǎn)并進(jìn)行了改進(jìn)，spark生態(tài)更為豐富，功能更為強(qiáng)大，性能更加適用范圍廣，mapreduce更簡(jiǎn)單，穩(wěn)定性好。主要區(qū)別

（1）spark把運(yùn)算的中間數(shù)據(jù)(shuffle階段產(chǎn)生的數(shù)據(jù))存放在內(nèi)存，迭代計(jì)算效率更高，mapreduce的中間結(jié)果需要落地，保存到磁盤(pán)

（2）Spark容錯(cuò)性高，它通過(guò)彈性分布式數(shù)據(jù)集RDD來(lái)實(shí)現(xiàn)高效容錯(cuò)，RDD是一組分布式的存儲(chǔ)在 節(jié)點(diǎn)內(nèi)存中的只讀性的數(shù)據(jù)集，這些集合石彈性的，某一部分丟失或者出錯(cuò)，可以通過(guò)整個(gè)數(shù)據(jù)集的計(jì)算流程的血緣關(guān)系來(lái)實(shí)現(xiàn)重建，mapreduce的容錯(cuò)只能重新計(jì)算

（3）Spark更通用，提供了transformation和action這兩大類的多功能api，另外還有流式處理sparkstreaming模塊、圖計(jì)算等等，mapreduce只提供了map和reduce兩種操作，流計(jì)算及其他的模塊支持比較缺乏

（4）Spark框架和生態(tài)更為復(fù)雜，有RDD，血緣lineage、執(zhí)行時(shí)的有向無(wú)環(huán)圖DAG,stage劃分等，很多時(shí)候spark作業(yè)都需要根據(jù)不同業(yè)務(wù)場(chǎng)景的需要進(jìn)行調(diào)優(yōu)以達(dá)到性能要求，mapreduce框架及其生態(tài)相對(duì)較為簡(jiǎn)單，對(duì)性能的要求也相對(duì)較弱，運(yùn)行較為穩(wěn)定，適合長(zhǎng)期后臺(tái)運(yùn)行。

（5）Spark計(jì)算框架對(duì)內(nèi)存的利用和運(yùn)行的并行度比mapreduce高，Spark運(yùn)行容器為executor，內(nèi)部ThreadPool中線程運(yùn)行一個(gè)Task,mapreduce在線程內(nèi)部運(yùn)行container，container容器分類為MapTask和ReduceTask.程序運(yùn)行并行度高

（6）Spark對(duì)于executor的優(yōu)化，在JVM虛擬機(jī)的基礎(chǔ)上對(duì)內(nèi)存彈性利用：storage memory與Execution memory的彈性擴(kuò)容，使得內(nèi)存利用效率更高

2. hadoop和spark使用場(chǎng)景？

Hadoop/MapReduce和Spark最適合的都是做離線型的數(shù)據(jù)分析，但Hadoop特別適合是單次分析的數(shù)據(jù)量“很大”的情景，而Spark則適用于數(shù)據(jù)量不是很大的情景。

• 一般情況下，對(duì)于中小互聯(lián)網(wǎng)和企業(yè)級(jí)的大數(shù)據(jù)應(yīng)用而言，單次分析的數(shù)量都不會(huì)“很大”，因此可以優(yōu)先考慮使用Spark。

• 業(yè)務(wù)通常認(rèn)為Spark更適用于機(jī)器學(xué)習(xí)之類的“迭代式”應(yīng)用，80GB的壓縮數(shù)據(jù)（解壓后超過(guò)200GB），10個(gè)節(jié)點(diǎn)的集群規(guī)模，跑類似“sum+group-by”的應(yīng)用，MapReduce花了5分鐘，而spark只需要2分鐘。

3. spark如何保證宕機(jī)迅速恢復(fù)?

適當(dāng)增加spark standby master
編寫(xiě)shell腳本，定期檢測(cè)master狀態(tài)，出現(xiàn)宕機(jī)后對(duì)master進(jìn)行重啟操作

4. hadoop和spark的相同點(diǎn)和不同點(diǎn)？

Hadoop底層使用MapReduce計(jì)算架構(gòu)，只有map和reduce兩種操作，表達(dá)能力比較欠缺，而且在MR過(guò)程中會(huì)重復(fù)的讀寫(xiě)hdfs，造成大量的磁盤(pán)io讀寫(xiě)操作，所以適合高時(shí)延環(huán)境下批處理計(jì)算的應(yīng)用；

Spark是基于內(nèi)存的分布式計(jì)算架構(gòu)，提供更加豐富的數(shù)據(jù)集操作類型，主要分成轉(zhuǎn)化操作和行動(dòng)操作，包括map、reduce、filter、flatmap、groupbykey、reducebykey、union和join等，數(shù)據(jù)分析更加快速，所以適合低時(shí)延環(huán)境下計(jì)算的應(yīng)用；

spark與hadoop最大的區(qū)別在于迭代式計(jì)算模型?；趍apreduce框架的Hadoop主要分為map和reduce兩個(gè)階段，兩個(gè)階段完了就結(jié)束了，所以在一個(gè)job里面能做的處理很有限；spark計(jì)算模型是基于內(nèi)存的迭代式計(jì)算模型，可以分為n個(gè)階段，根據(jù)用戶編寫(xiě)的RDD算子和程序，在處理完一個(gè)階段后可以繼續(xù)往下處理很多個(gè)階段，而不只是兩個(gè)階段。所以spark相較于mapreduce，計(jì)算模型更加靈活，可以提供更強(qiáng)大的功能。

但是spark也有劣勢(shì)，由于spark基于內(nèi)存進(jìn)行計(jì)算，雖然開(kāi)發(fā)容易，但是真正面對(duì)大數(shù)據(jù)的時(shí)候，在沒(méi)有進(jìn)行調(diào)優(yōu)的輕局昂下，可能會(huì)出現(xiàn)各種各樣的問(wèn)題，比如OOM內(nèi)存溢出等情況，導(dǎo)致spark程序可能無(wú)法運(yùn)行起來(lái)，而mapreduce雖然運(yùn)行緩慢，但是至少可以慢慢運(yùn)行完。

5. RDD持久化原理？

spark非常重要的一個(gè)功能特性就是可以將RDD持久化在內(nèi)存中。

調(diào)用cache()和persist()方法即可。cache()和persist()的區(qū)別在于，cache()是persist()的一種簡(jiǎn)化方式，cache()的底層就是調(diào)用persist()的無(wú)參版本persist(MEMORY_ONLY)，將數(shù)據(jù)持久化到內(nèi)存中。

如果需要從內(nèi)存中清除緩存，可以使用unpersist()方法。RDD持久化是可以手動(dòng)選擇不同的策略的。在調(diào)用persist()時(shí)傳入對(duì)應(yīng)的StorageLevel即可。

6. checkpoint檢查點(diǎn)機(jī)制？

應(yīng)用場(chǎng)景：當(dāng)spark應(yīng)用程序特別復(fù)雜，從初始的RDD開(kāi)始到最后整個(gè)應(yīng)用程序完成有很多的步驟，而且整個(gè)應(yīng)用運(yùn)行時(shí)間特別長(zhǎng)，這種情況下就比較適合使用checkpoint功能。

原因：對(duì)于特別復(fù)雜的Spark應(yīng)用，會(huì)出現(xiàn)某個(gè)反復(fù)使用的RDD，即使之前持久化過(guò)但由于節(jié)點(diǎn)的故障導(dǎo)致數(shù)據(jù)丟失了，沒(méi)有容錯(cuò)機(jī)制，所以需要重新計(jì)算一次數(shù)據(jù)。

Checkpoint首先會(huì)調(diào)用SparkContext的setCheckPointDIR()方法，設(shè)置一個(gè)容錯(cuò)的文件系統(tǒng)的目錄，比如說(shuō)HDFS；然后對(duì)RDD調(diào)用checkpoint()方法。之后在RDD所處的job運(yùn)行結(jié)束之后，會(huì)啟動(dòng)一個(gè)單獨(dú)的job，來(lái)將checkpoint過(guò)的RDD數(shù)據(jù)寫(xiě)入之前設(shè)置的文件系統(tǒng)，進(jìn)行高可用、容錯(cuò)的類持久化操作。

檢查點(diǎn)機(jī)制是我們?cè)趕park streaming中用來(lái)保障容錯(cuò)性的主要機(jī)制，它可以使spark streaming階段性的把應(yīng)用數(shù)據(jù)存儲(chǔ)到諸如HDFS等可靠存儲(chǔ)系統(tǒng)中，以供恢復(fù)時(shí)使用。具體來(lái)說(shuō)基于以下兩個(gè)目的服務(wù)：

• 控制發(fā)生失敗時(shí)需要重算的狀態(tài)數(shù)。Spark streaming可以通過(guò)轉(zhuǎn)化圖的譜系圖來(lái)重算狀態(tài)，檢查點(diǎn)機(jī)制則可以控制需要在轉(zhuǎn)化圖中回溯多遠(yuǎn)。

• 提供驅(qū)動(dòng)器程序容錯(cuò)。如果流計(jì)算應(yīng)用中的驅(qū)動(dòng)器程序崩潰了，你可以重啟驅(qū)動(dòng)器程序并讓驅(qū)動(dòng)器程序從檢查點(diǎn)恢復(fù)，這樣spark streaming就可以讀取之前運(yùn)行的程序處理數(shù)據(jù)的進(jìn)度，并從那里繼續(xù)。

7. checkpoint和持久化機(jī)制的區(qū)別？

最主要的區(qū)別在于持久化只是將數(shù)據(jù)保存在BlockManager中，但是RDD的lineage(血緣關(guān)系，依賴關(guān)系)是不變的。但是checkpoint執(zhí)行完之后，rdd已經(jīng)沒(méi)有之前所謂的依賴rdd了，而只有一個(gè)強(qiáng)行為其設(shè)置的checkpointRDD，checkpoint之后rdd的lineage就改變了。

持久化的數(shù)據(jù)丟失的可能性更大，因?yàn)楣?jié)點(diǎn)的故障會(huì)導(dǎo)致磁盤(pán)、內(nèi)存的數(shù)據(jù)丟失。但是checkpoint的數(shù)據(jù)通常是保存在高可用的文件系統(tǒng)中，比如HDFS中，所以數(shù)據(jù)丟失可能性比較低

8. RDD機(jī)制理解嗎？

• rdd分布式彈性數(shù)據(jù)集，簡(jiǎn)單的理解成一種數(shù)據(jù)結(jié)構(gòu)，是spark框架上的通用貨幣。所有算子都是基于rdd來(lái)執(zhí)行的，不同的場(chǎng)景會(huì)有不同的rdd實(shí)現(xiàn)類，但是都可以進(jìn)行互相轉(zhuǎn)換。rdd執(zhí)行過(guò)程中會(huì)形成dag圖，然后形成lineage保證容錯(cuò)性等。從物理的角度來(lái)看rdd存儲(chǔ)的是block和node之間的映射。

• RDD是spark提供的核心抽象，全稱為彈性分布式數(shù)據(jù)集。

• RDD在邏輯上是一個(gè)hdfs文件，在抽象上是一種元素集合，包含了數(shù)據(jù)。它是被分區(qū)的，分為多個(gè)分區(qū)，每個(gè)分區(qū)分布在集群中的不同結(jié)點(diǎn)上，從而讓RDD中的數(shù)據(jù)可以被并行操作（分布式數(shù)據(jù)集）

• 比如有個(gè)RDD有90W數(shù)據(jù)，3個(gè)partition，則每個(gè)分區(qū)上有30W數(shù)據(jù)。RDD通常通過(guò)Hadoop上的文件，即HDFS或者HIVE表來(lái)創(chuàng)建，還可以通過(guò)應(yīng)用程序中的集合來(lái)創(chuàng)建；RDD最重要的特性就是容錯(cuò)性，可以自動(dòng)從節(jié)點(diǎn)失敗中恢復(fù)過(guò)來(lái)。即如果某個(gè)結(jié)點(diǎn)上的RDD partition因?yàn)楣?jié)點(diǎn)故障，導(dǎo)致數(shù)據(jù)丟失，那么RDD可以通過(guò)自己的數(shù)據(jù)來(lái)源重新計(jì)算該partition。這一切對(duì)使用者都是透明的。

• RDD的數(shù)據(jù)默認(rèn)存放在內(nèi)存中，但是當(dāng)內(nèi)存資源不足時(shí)，spark會(huì)自動(dòng)將RDD數(shù)據(jù)寫(xiě)入磁盤(pán)。比如某結(jié)點(diǎn)內(nèi)存只能處理20W數(shù)據(jù)，那么這20W數(shù)據(jù)就會(huì)放入內(nèi)存中計(jì)算，剩下10W放到磁盤(pán)中。RDD的彈性體現(xiàn)在于RDD上自動(dòng)進(jìn)行內(nèi)存和磁盤(pán)之間權(quán)衡和切換的機(jī)制。

9. Spark streaming以及基本工作原理？

Spark streaming是spark core API的一種擴(kuò)展，可以用于進(jìn)行大規(guī)模、高吞吐量、容錯(cuò)的實(shí)時(shí)數(shù)據(jù)流的處理。

它支持從多種數(shù)據(jù)源讀取數(shù)據(jù)，比如Kafka、Flume、Twitter和TCP Socket，并且能夠使用算子比如map、reduce、join和window等來(lái)處理數(shù)據(jù)，處理后的數(shù)據(jù)可以保存到文件系統(tǒng)、數(shù)據(jù)庫(kù)等存儲(chǔ)中。

Spark streaming內(nèi)部的基本工作原理是：接受實(shí)時(shí)輸入數(shù)據(jù)流，然后將數(shù)據(jù)拆分成batch，比如每收集一秒的數(shù)據(jù)封裝成一個(gè)batch，然后將每個(gè)batch交給spark的計(jì)算引擎進(jìn)行處理，最后會(huì)生產(chǎn)處一個(gè)結(jié)果數(shù)據(jù)流，其中的數(shù)據(jù)也是一個(gè)一個(gè)的batch組成的。

10. DStream以及基本工作原理？

• DStream是spark streaming提供的一種高級(jí)抽象，代表了一個(gè)持續(xù)不斷的數(shù)據(jù)流。

• DStream可以通過(guò)輸入數(shù)據(jù)源來(lái)創(chuàng)建，比如Kafka、flume等，也可以通過(guò)其他DStream的高階函數(shù)來(lái)創(chuàng)建，比如map、reduce、join和window等。

• DStream內(nèi)部其實(shí)不斷產(chǎn)生RDD，每個(gè)RDD包含了一個(gè)時(shí)間段的數(shù)據(jù)。

• Spark streaming一定是有一個(gè)輸入的DStream接收數(shù)據(jù)，按照時(shí)間劃分成一個(gè)一個(gè)的batch，并轉(zhuǎn)化為一個(gè)RDD，RDD的數(shù)據(jù)是分散在各個(gè)子節(jié)點(diǎn)的partition中。

11. spark有哪些組件？

• master：管理集群和節(jié)點(diǎn)，不參與計(jì)算。

• worker：計(jì)算節(jié)點(diǎn)，進(jìn)程本身不參與計(jì)算，和master匯報(bào)。

• Driver：運(yùn)行程序的main方法，創(chuàng)建spark context對(duì)象。

• spark context：控制整個(gè)application的生命周期，包括dagsheduler和task scheduler等組件。

• client：用戶提交程序的入口。

12. spark工作機(jī)制？

用戶在client端提交作業(yè)后，會(huì)由Driver運(yùn)行main方法并創(chuàng)建spark context上下文。執(zhí)行add算子，形成dag圖輸入dagscheduler，按照add之間的依賴關(guān)系劃分stage輸入task scheduler。task scheduler會(huì)將stage劃分為task set分發(fā)到各個(gè)節(jié)點(diǎn)的executor中執(zhí)行。

13. 說(shuō)下寬依賴和窄依賴

寬依賴：
本質(zhì)就是shuffle。父RDD的每一個(gè)partition中的數(shù)據(jù)，都可能會(huì)傳輸一部分到下一個(gè)子RDD的每一個(gè)partition中，此時(shí)會(huì)出現(xiàn)父RDD和子RDD的partition之間具有交互錯(cuò)綜復(fù)雜的關(guān)系，這種情況就叫做兩個(gè)RDD之間是寬依賴。

窄依賴：
父RDD和子RDD的partition之間的對(duì)應(yīng)關(guān)系是一對(duì)一的。

14. Spark主備切換機(jī)制原理知道嗎？

Master實(shí)際上可以配置兩個(gè)，Spark原生的standalone模式是支持Master主備切換的。當(dāng)Active Master節(jié)點(diǎn)掛掉以后，我們可以將Standby Master切換為Active Master。

Spark Master主備切換可以基于兩種機(jī)制，一種是基于文件系統(tǒng)的，一種是基于ZooKeeper的。

基于文件系統(tǒng)的主備切換機(jī)制，需要在Active Master掛掉之后手動(dòng)切換到Standby Master上；

而基于Zookeeper的主備切換機(jī)制，可以實(shí)現(xiàn)自動(dòng)切換Master。

15. spark解決了hadoop的哪些問(wèn)題？

• MR：抽象層次低，需要使用手工代碼來(lái)完成程序編寫(xiě)，使用上難以上手；

• Spark：Spark采用RDD計(jì)算模型，簡(jiǎn)單容易上手。

• MR：只提供map和reduce兩個(gè)操作，表達(dá)能力欠缺；

• Spark：Spark采用更加豐富的算子模型，包括map、flatmap、groupbykey、reducebykey等；

• MR：一個(gè)job只能包含map和reduce兩個(gè)階段，復(fù)雜的任務(wù)需要包含很多個(gè)job，這些job之間的管理以來(lái)需要開(kāi)發(fā)者自己進(jìn)行管理；

• Spark：Spark中一個(gè)job可以包含多個(gè)轉(zhuǎn)換操作，在調(diào)度時(shí)可以生成多個(gè)stage，而且如果多個(gè)map操作的分區(qū)不變，是可以放在同一個(gè)task里面去執(zhí)行；

• MR：中間結(jié)果存放在hdfs中；

• Spark：Spark的中間結(jié)果一般存在內(nèi)存中，只有當(dāng)內(nèi)存不夠了，才會(huì)存入本地磁盤(pán)，而不是hdfs；

• MR：只有等到所有的map task執(zhí)行完畢后才能執(zhí)行reduce task；

• Spark：Spark中分區(qū)相同的轉(zhuǎn)換構(gòu)成流水線在一個(gè)task中執(zhí)行，分區(qū)不同的需要進(jìn)行shuffle操作，被劃分成不同的stage需要等待前面的stage執(zhí)行完才能執(zhí)行。

• MR：只適合batch批處理，時(shí)延高，對(duì)于交互式處理和實(shí)時(shí)處理支持不夠；

• Spark：Spark streaming可以將流拆成時(shí)間間隔的batch進(jìn)行處理，實(shí)時(shí)計(jì)算。

16. 數(shù)據(jù)傾斜的產(chǎn)生和解決辦法？

數(shù)據(jù)傾斜以為著某一個(gè)或者某幾個(gè)partition的數(shù)據(jù)特別大，導(dǎo)致這幾個(gè)partition上的計(jì)算需要耗費(fèi)相當(dāng)長(zhǎng)的時(shí)間。

在spark中同一個(gè)應(yīng)用程序劃分成多個(gè)stage，這些stage之間是串行執(zhí)行的，而一個(gè)stage里面的多個(gè)task是可以并行執(zhí)行，task數(shù)目由partition數(shù)目決定，如果一個(gè)partition的數(shù)目特別大，那么導(dǎo)致這個(gè)task執(zhí)行時(shí)間很長(zhǎng)，導(dǎo)致接下來(lái)的stage無(wú)法執(zhí)行，從而導(dǎo)致整個(gè)job執(zhí)行變慢。

避免數(shù)據(jù)傾斜，一般是要選用合適的key，或者自己定義相關(guān)的partitioner，通過(guò)加鹽或者哈希值來(lái)拆分這些key，從而將這些數(shù)據(jù)分散到不同的partition去執(zhí)行。

如下算子會(huì)導(dǎo)致shuffle操作，是導(dǎo)致數(shù)據(jù)傾斜可能發(fā)生的關(guān)鍵點(diǎn)所在：groupByKey；reduceByKey；aggregaByKey；join；cogroup；

17. 你用sparksql處理的時(shí)候， 處理過(guò)程中用的dataframe還是直接寫(xiě)的sql？為什么？

這個(gè)問(wèn)題的宗旨是問(wèn)你spark sql 中dataframe和sql的區(qū)別，從執(zhí)行原理、操作方便程度和自定義程度來(lái)分析這個(gè)問(wèn)題。

18. 現(xiàn)場(chǎng)寫(xiě)一個(gè)筆試題

有hdfs文件，文件每行的格式為作品ID，用戶id，用戶性別。請(qǐng)用一個(gè)spark任務(wù)實(shí)現(xiàn)以下功能：統(tǒng)計(jì)每個(gè)作品對(duì)應(yīng)的用戶（去重后）的性別分布。輸出格式如下：作品ID，男性用戶數(shù)量，女性用戶數(shù)量

答案：

sc.textfile() .flatmap(.split(","))//分割成作    
    品ID，用戶id，用戶性別
.map(((_.1,_._2),1))//((作品id,用戶性別),1)
.reduceByKey(_+_)//((作品id,用戶性別),n)
.map(_._1._1,_._1._2,_._2)//(作品id,用戶性別,n)

19. RDD中reduceBykey與groupByKey哪個(gè)性能好，為什么

reduceByKey：reduceByKey會(huì)在結(jié)果發(fā)送至reducer之前會(huì)對(duì)每個(gè)mapper在本地進(jìn)行merge，有點(diǎn)類似于在MapReduce中的combiner。這樣做的好處在于，在map端進(jìn)行一次reduce之后，數(shù)據(jù)量會(huì)大幅度減小，從而減小傳輸，保證reduce端能夠更快的進(jìn)行結(jié)果計(jì)算。

groupByKey：groupByKey會(huì)對(duì)每一個(gè)RDD中的value值進(jìn)行聚合形成一個(gè)序列(Iterator)，此操作發(fā)生在reduce端，所以勢(shì)必會(huì)將所有的數(shù)據(jù)通過(guò)網(wǎng)絡(luò)進(jìn)行傳輸，造成不必要的浪費(fèi)。同時(shí)如果數(shù)據(jù)量十分大，可能還會(huì)造成OutOfMemoryError。

所以在進(jìn)行大量數(shù)據(jù)的reduce操作時(shí)候建議使用reduceByKey。不僅可以提高速度，還可以防止使用groupByKey造成的內(nèi)存溢出問(wèn)題。

20. Spark master HA主從切換過(guò)程不會(huì)影響到集群已有作業(yè)的運(yùn)行，為什么

不會(huì)的。

因?yàn)槌绦蛟谶\(yùn)行之前，已經(jīng)申請(qǐng)過(guò)資源了，driver和Executors通訊，不需要和master進(jìn)行通訊的。

21. spark master使用zookeeper進(jìn)行ha，有哪些源數(shù)據(jù)保存到Zookeeper里面

spark通過(guò)這個(gè)參數(shù)spark.deploy.zookeeper.dir指定master元數(shù)據(jù)在zookeeper中保存的位置，包括Worker，Driver和Application以及Executors。standby節(jié)點(diǎn)要從zk中，獲得元數(shù)據(jù)信息，恢復(fù)集群運(yùn)行狀態(tài)，才能對(duì)外繼續(xù)提供服務(wù)，作業(yè)提交資源申請(qǐng)等，在恢復(fù)前是不能接受請(qǐng)求的。

1、在Master切換的過(guò)程中，所有的已經(jīng)在運(yùn)行的程序皆正常運(yùn)行！
因?yàn)镾park Application在運(yùn)行前就已經(jīng)通過(guò)Cluster Manager獲得了    
計(jì)算資源，所以在運(yùn)行時(shí)Job本身的    
調(diào)度和處理和Master是沒(méi)有任何關(guān)系。
2、在Master的切換過(guò)程中唯一的影響是不能提交新的Job：
一方面不能夠提交新的應(yīng)用程序給集群，    
因?yàn)橹挥蠥ctive Master才能接受新的程序的提交請(qǐng)求；
另外一方面，已經(jīng)運(yùn)行的程序中也不能夠因    
Action操作觸發(fā)新的Job的提交請(qǐng)求。