1、driver的功能是什么？

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

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

2、spark的有幾種部署模式，每種模式特點(diǎn)？

1) 本地模式

2) standalone 模式

3) spark on yarn 模式

4) mesos模式

3、Spark為什么比mapreduce快？

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

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

3)容錯(cuò)機(jī)制Linage，精華部分就是DAG和Lingae

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

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

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

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

5、RDD寬依賴和窄依賴？

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

2）寬依賴指的是多個(gè)子RDD的Partition會(huì)依賴同一個(gè)parent RDD的Partition

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

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

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

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

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

1）.數(shù)據(jù)檢查點(diǎn),會(huì)發(fā)生拷貝，浪費(fèi)資源

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

——————

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

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

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

8、RDD有哪些缺陷？

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

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

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

每個(gè)數(shù)據(jù)分片都對(duì)應(yīng)具體物理位置，數(shù)據(jù)的位置是被blockManager，無(wú)論數(shù)據(jù)是在磁盤(pán)，內(nèi)存還是tacyan，都是由blockManager管理

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

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

11、rdd有幾種操作類型？

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

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

1）因?yàn)檩斎霐?shù)據(jù)有很多task，尤其是有很多小文件的時(shí)候，有多少個(gè)輸入block就會(huì)有多少個(gè)task啟動(dòng)；

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

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

13、為什么Spark Application在沒(méi)有獲得足夠的資源，job就開(kāi)始執(zhí)行了，可能會(huì)導(dǎo)致什么什么問(wèn)題發(fā)生?

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

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

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

15、介紹一下cogroup rdd實(shí)現(xiàn)原理，你在什么場(chǎng)景下用過(guò)這個(gè)rdd？

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

最新評(píng)論