1、driver的功能是什么？

1）一個Spark作業(yè)運行時包括一個Driver進程，也是作業(yè)的主進程，具有main函數(shù)，并且有SparkContext的實例，是程序的人口點；

2）功能：負責向集群申請資源，向master注冊信息，負責了作業(yè)的調(diào)度，，負責作業(yè)的解析、生成Stage并調(diào)度Task到Executor上。包括DAGScheduler，TaskScheduler。

2、spark的有幾種部署模式，每種模式特點？

1) 本地模式

2) standalone 模式

3) spark on yarn 模式

4) mesos模式

3、Spark為什么比mapreduce快？

1）基于內(nèi)存計算，減少低效的磁盤交互；

2）高效的調(diào)度算法，基于DAG；

3)容錯機制Linage，精華部分就是DAG和Lingae

4、hadoop和spark的shuffle相同和差異？

1）從 high-level 的角度來看，兩者并沒有大的差別。 都是將 mapper（Spark 里是 ShuffleMapTask）的輸出進行 partition，不同的 partition 送到不同的 reducer（Spark 里 reducer 可能是下一個 stage 里的 ShuffleMapTask，也可能是 ResultTask）。Reducer 以內(nèi)存作緩沖區(qū)，邊 shuffle 邊 aggregate 數(shù)據(jù)，等到數(shù)據(jù) aggregate 好以后進行 reduce() （Spark 里可能是后續(xù)的一系列操作）。

2）從 low-level 的角度來看，兩者差別不小。 Hadoop MapReduce 是 sort-based，進入 combine() 和 reduce() 的 records 必須先 sort。這樣的好處在于 combine/reduce() 可以處理大規(guī)模的數(shù)據(jù)，因為其輸入數(shù)據(jù)可以通過外排得到（mapper 對每段數(shù)據(jù)先做排序，reducer 的 shuffle 對排好序的每段數(shù)據(jù)做歸并）。目前的 Spark 默認選擇的是 hash-based，通常使用 HashMap 來對 shuffle 來的數(shù)據(jù)進行 aggregate，不會對數(shù)據(jù)進行提前排序。如果用戶需要經(jīng)過排序的數(shù)據(jù)，那么需要自己調(diào)用類似 sortByKey() 的操作；如果你是Spark 1.1的用戶，可以將spark.shuffle.manager設置為sort，則會對數(shù)據(jù)進行排序。在Spark 1.2中，sort將作為默認的Shuffle實現(xiàn)。

3）從實現(xiàn)角度來看，兩者也有不少差別。 Hadoop MapReduce 將處理流程劃分出明顯的幾個階段：map(), spill, merge, shuffle, sort, reduce() 等。每個階段各司其職，可以按照過程式的編程思想來逐一實現(xiàn)每個階段的功能。在 Spark 中，沒有這樣功能明確的階段，只有不同的 stage 和一系列的 transformation()，所以 spill, merge, aggregate 等操作需要蘊含在 transformation() 中。如果我們將 map 端劃分數(shù)據(jù)、持久化數(shù)據(jù)的過程稱為 shuffle write，而將 reducer 讀入數(shù)據(jù)、aggregate 數(shù)據(jù)的過程稱為 shuffle read。那么在 Spark 中，問題就變?yōu)樵趺丛?job 的邏輯或者物理執(zhí)行圖中加入 shuffle write 和 shuffle read 的處理邏輯？以及兩個處理邏輯應該怎么高效實現(xiàn)？ Shuffle write由于不要求數(shù)據(jù)有序，shuffle write 的任務很簡單：將數(shù)據(jù) partition 好，并持久化。之所以要持久化，一方面是要減少內(nèi)存存儲空間壓力，另一方面也是為了 fault-tolerance。

5、RDD寬依賴和窄依賴？

RDD和它依賴的parent RDD(s)的關系有兩種不同的類型，即窄依賴（narrow dependency）和寬依賴（wide dependency）。1）窄依賴指的是每一個parent RDD的Partition最多被子RDD的一個Partition使用

2）寬依賴指的是多個子RDD的Partition會依賴同一個parent RDD的Partition

6、cache和pesist的區(qū)別

1）cache和persist都是用于將一個RDD進行緩存的，這樣在之后使用的過程中就不需要重新計算了，可以大大節(jié)省程序運行時間；

2） cache只有一個默認的緩存級別MEMORY_ONLY ，cache調(diào)用了persist，而persist可以根據(jù)情況設置其它的緩存級別；

3）executor執(zhí)行的時候，默認60%做cache，40%做task操作，persist最根本的函數(shù)，最底層的函數(shù)

7、常規(guī)的容錯方式有哪幾種類型？RDD通過Linage（記錄數(shù)據(jù)更新）的方式為何很高效？

1）.數(shù)據(jù)檢查點,會發(fā)生拷貝，浪費資源

2）.記錄數(shù)據(jù)的更新，每次更新都會記錄下來，比較復雜且比較消耗性能

——————

1）    ​lazy記錄了數(shù)據(jù)的來源，RDD是不可變的，且是lazy級別的，且rDD之間構成了鏈條，lazy是彈性的基石。由于RDD不可變，所以每次操作就產(chǎn)生新的rdd，不存在全局修改的問題，控制難度下降，所有有計算鏈條將復雜計算鏈條存儲下來，計算的時候從后往前回溯900步是上一個stage的結束，要么就checkpoint

2）    ​記錄原數(shù)據(jù)，是每次修改都記錄，代價很大如果修改一個集合，代價就很小，官方說rdd是粗粒度的操作，是為了效率，為了簡化，每次都是操作數(shù)據(jù)集合，寫或者修改操作，都是基于集合的rdd的寫操作是粗粒度的，rdd的讀操作既可以是粗粒度的也可以是細粒度，讀可以讀其中的一條條的記錄。

3）    ​簡化復雜度，是高效率的一方面，寫的粗粒度限制了使用場景如網(wǎng)絡爬蟲，現(xiàn)實世界中，大多數(shù)寫是粗粒度的場景

8、RDD有哪些缺陷？

1）不支持細粒度的寫和更新操作（如網(wǎng)絡爬蟲），spark寫數(shù)據(jù)是粗粒度的所謂粗粒度，就是批量寫入數(shù)據(jù)，為了提高效率。但是讀數(shù)據(jù)是細粒度的也就是說可以一條條的讀

2）不支持增量迭代計算，F(xiàn)link支持

9、Spark中數(shù)據(jù)的位置是被誰管理的？

每個數(shù)據(jù)分片都對應具體物理位置，數(shù)據(jù)的位置是被blockManager，無論數(shù)據(jù)是在磁盤，內(nèi)存還是tacyan，都是由blockManager管理

10、Spark的數(shù)據(jù)本地性有哪幾種？

答：Spark中的數(shù)據(jù)本地性有三種：a.PROCESS_LOCAL是指讀取緩存在本地節(jié)點的數(shù)據(jù)b.NODE_LOCAL是指讀取本地節(jié)點硬盤數(shù)據(jù)c.ANY是指讀取非本地節(jié)點數(shù)據(jù)通常讀取數(shù)據(jù)PROCESS_LOCAL>NODE_LOCAL>ANY，盡量使數(shù)據(jù)以PROCESS_LOCAL或NODE_LOCAL方式讀取。其中PROCESS_LOCAL還和cache有關，如果RDD經(jīng)常用的話將該RDD cache到內(nèi)存中，注意，由于cache是lazy的，所以必須通過一個action的觸發(fā)，才能真正的將該RDD cache到內(nèi)存中

11、rdd有幾種操作類型？

1）transformation，rdd由一種轉為另一種rdd2）action，3）cronroller，crontroller是控制算子,cache,persist，對性能和效率的有很好的支持三種類型，不要回答只有2中操作

12、Spark程序執(zhí)行，有時候默認為什么會產(chǎn)生很多task，怎么修改默認task執(zhí)行個數(shù)？

1）因為輸入數(shù)據(jù)有很多task，尤其是有很多小文件的時候，有多少個輸入block就會有多少個task啟動；

2）spark中有partition的概念，每個partition都會對應一個task，task越多，在處理大規(guī)模數(shù)據(jù)的時候，就會越有效率。不過task并不是越多越好，如果平時測試，或者數(shù)據(jù)量沒有那么大，則沒有必要task數(shù)量太多。

3）參數(shù)可以通過spark_home/conf/spark-default.conf配置文件設置:spark.sql.shuffle.partitions 50 spark.default.parallelism 10第一個是針對spark sql的task數(shù)量第二個是非spark sql程序設置生效

13、為什么Spark Application在沒有獲得足夠的資源，job就開始執(zhí)行了，可能會導致什么什么問題發(fā)生?

答：會導致執(zhí)行該job時候集群資源不足，導致執(zhí)行job結束也沒有分配足夠的資源，分配了部分Executor，該job就開始執(zhí)行task，應該是task的調(diào)度線程和Executor資源申請是異步的；如果想等待申請完所有的資源再執(zhí)行job的：需要將spark.scheduler.maxRegisteredResourcesWaitingTime設置的很大；spark.scheduler.minRegisteredResourcesRatio 設置為1，但是應該結合實際考慮否則很容易出現(xiàn)長時間分配不到資源，job一直不能運行的情況。

14、join操作優(yōu)化經(jīng)驗？

join其實常見的就分為兩類： map-side join 和  reduce-side join。當大表和小表join時，用map-side join能顯著提高效率。將多份數(shù)據(jù)進行關聯(lián)是數(shù)據(jù)處理過程中非常普遍的用法，不過在分布式計算系統(tǒng)中，這個問題往往會變的非常麻煩，因為框架提供的 join 操作一般會將所有數(shù)據(jù)根據(jù) key 發(fā)送到所有的 reduce 分區(qū)中去，也就是 shuffle 的過程。造成大量的網(wǎng)絡以及磁盤IO消耗，運行效率極其低下，這個過程一般被稱為 reduce-side-join。如果其中有張表較小的話，我們則可以自己實現(xiàn)在 map 端實現(xiàn)數(shù)據(jù)關聯(lián)，跳過大量數(shù)據(jù)進行 shuffle 的過程，運行時間得到大量縮短，根據(jù)不同數(shù)據(jù)可能會有幾倍到數(shù)十倍的性能提升。

15、介紹一下cogroup rdd實現(xiàn)原理，你在什么場景下用過這個rdd？

答：cogroup的函數(shù)實現(xiàn):這個實現(xiàn)根據(jù)兩個要進行合并的兩個RDD操作,生成一個CoGroupedRDD的實例,這個RDD的返回結果是把相同的key中兩個RDD分別進行合并操作,最后返回的RDD的value是一個Pair的實例,這個實例包含兩個Iterable的值,第一個值表示的是RDD1中相同KEY的值,第二個值表示的是RDD2中相同key的值.由于做cogroup的操作,需要通過partitioner進行重新分區(qū)的操作,因此,執(zhí)行這個流程時,需要執(zhí)行一次shuffle的操作(如果要進行合并的兩個RDD的都已經(jīng)是shuffle后的rdd,同時他們對應的partitioner相同時,就不需要執(zhí)行shuffle