spark面試總結4

Spark on Yarn面試篇04
1.MRV1有哪些不足？
1)可擴展性（對於變化的應付能力）

a) JobTracker內存中保存用戶做業的信息

b) JobTracker使用的是粗粒度的鎖
2)可靠性和可用性

a) JobTracker失效會多事集羣中全部的運行做業，用戶需手動從新提交和恢復工做流
3)對不一樣編程模型的支持
HadoopV1以MapReduce爲中心的設計雖然能支持普遍的用例，可是並不適合全部大型計算,如storm，spark
2.描述Yarn執行一個任務的過程？
1）客戶端client向ResouceManager提交Application，ResouceManager接受Application
並根據集羣資源情況選取一個node來啓動Application的任務調度器driver（ApplicationMaster）
2）ResouceManager找到那個node，命令其該node上的nodeManager來啓動一個新的
JVM進程運行程序的driver（ApplicationMaster）部分，driver（ApplicationMaster）啓動時會首先向ResourceManager註冊，說明由本身來負責當前程序的運行
3）driver（ApplicationMaster）開始下載相關jar包等各類資源，基於下載的jar等信息決定向ResourceManager申請具體的資源內容。
4）ResouceManager接受到driver（ApplicationMaster）提出的申請後，會最大化的知足
資源分配請求，併發送資源的元數據信息給driver（ApplicationMaster）；
5）driver（ApplicationMaster）收到發過來的資源元數據信息後會根據元數據信息發指令給具體
機器上的NodeManager，讓其啓動具體的container。
6）NodeManager收到driver發來的指令，啓動container，container啓動後必須向driver（ApplicationMaster）註冊。
7）driver（ApplicationMaster）收到container的註冊，開始進行任務的調度和計算，直到
任務完成。
補充：若是ResourceManager第一次沒有可以知足driver（ApplicationMaster）的資源請求
，後續發現有空閒的資源，會主動向driver（ApplicationMaster）發送可用資源的元數據信息
以提供更多的資源用於當前程序的運行。

3.Yarn中的container是由誰負責銷燬的，在Hadoop Mapreduce中container能夠複用麼？
答：ApplicationMaster負責銷燬，在Hadoop Mapreduce不能夠複用，在spark on yarn程序container能夠複用
4.提交任務時，如何指定Spark Application的運行模式？
1）cluster模式：./spark-submit --class xx.xx.xx --master yarn --deploy-mode cluster xx.jar
2) client模式:./spark-submit --class xx.xx.xx --master yarn --deploy-mode client xx.jar

1. 不啓動Spark集羣Master和work服務，可不能夠運行Spark程序？
   答：能夠，只要資源管理器第三方管理就能夠，如由yarn管理，spark集羣不啓動也可使用spark；spark集羣啓動的是work和master，這個其實就是資源管理框架，yarn中的resourceManager至關於master，NodeManager至關於worker，作計算是Executor，和spark集羣的work和manager能夠不要緊，歸根接底仍是JVM的運行，只要所在的JVM上安裝了spark就能夠。
   6.Spark中的4040端口由什麼功能?
   答：收集Spark做業運行的信息
   7.spark on yarn Cluster 模式下，ApplicationMaster和driver是在同一個進程麼？
   答：是,driver 位於ApplicationMaster進程中。該進程負責申請資源，還負責監控程序、資源的動態狀況。
   8.如何使用命令查看application運行的日誌信息
   答：yarn logs -applicationId
   9.Spark on Yarn 模式有哪些優勢？
   1)與其餘計算框架共享集羣資源（eg.Spark框架與MapReduce框架同時運行，若是不用Yarn進行資源分配，MapReduce分到的內存資源會不多，效率低下）；資源按需分配，進而提升集羣資源利用等。
   2)相較於Spark自帶的Standalone模式，Yarn的資源分配更加細緻
   3)Application部署簡化，例如Spark，Storm等多種框架的應用由客戶端提交後，由Yarn負責資源的管理和調度，利用Container做爲資源隔離的單位，以它爲單位去使用內存,cpu等。
   4)Yarn經過隊列的方式，管理同時運行在Yarn集羣中的多個服務，可根據不一樣類型的應用程序負載狀況，調整對應的資源使用量，實現資源彈性管理。
   10.談談你對container的理解？
   1）Container做爲資源分配和調度的基本單位，其中封裝了的資源如內存，CPU，磁盤，網絡帶寬等。 目前yarn僅僅封裝內存和CPU
   2)Container由ApplicationMaster向ResourceManager申請的，由ResouceManager中的資源調度器異步分配給ApplicationMaster
   3) Container的運行是由ApplicationMaster向資源所在的NodeManager發起的，Container運行時需提供內部執行的任務命令.
   11.運行在yarn中Application有幾種類型的container？
   1） 運行ApplicationMaster的Container：這是由ResourceManager（向內部的資源調度器）申請和啓動的，用戶提交應用程序時，可指定惟一的ApplicationMaster所需的資源；
   2） 運行各種任務的Container：這是由ApplicationMaster向ResourceManager申請的，並由ApplicationMaster與NodeManager通訊以啓動之。
   12.Spark on Yarn架構是怎麼樣的？（要會畫哦，這個圖）

Yarn提到的App Master能夠理解爲Spark中Standalone模式中的driver。Container中運行着Executor,在Executor中以多線程並行的方式運行Task。運行過程和第二題類似。
13.Executor啓動時，資源經過哪幾個參數指定？
1)num-executors是executor的數量
2)executor-memory 是每一個executor使用的內存
3)executor-cores 是每一個executor分配的CPU
14.爲何會產生yarn，解決了什麼問題，有什麼優點?
1)爲何產生yarn，針對MRV1的各類缺陷提出來的資源管理框架
2)解決了什麼問題，有什麼優點，參考這篇博文：http://www.aboutyun.com/forum.php?mod=viewthread&tid=6785
15.Mapreduce的執行過程?
階段1：input/map/partition/sort/spill
階段2：mapper端merge
階段3：reducer端merge/reduce/output
詳細過程參考這個http://www.cnblogs.com/hipercomer/p/4516581.html

16.一個task的map數量由誰來決定？
通常狀況下，在輸入源是文件的時候，一個task的map數量由splitSize來決定的，那麼splitSize是由如下幾個來決定的
goalSize = totalSize / mapred.map.tasks
inSize = max {mapred.min.split.size, minSplitSize}
splitSize = max (minSize, min(goalSize, dfs.block.size))
一個task的reduce數量，由partition決定。
17.reduce後輸出的數據量有多大？
並非想知道確切的數據量有多大這個，而是想問你，MR的執行機制，開發完程序，有沒有認真評估程序運行效率
1）用於處理redcue任務的資源狀況，若是是MRV1的話，分了多少資源給map，多少個reduce
若是是MRV2的話，能夠提一下，集羣有分了多少內存、CPU給yarn作計算 。
2）結合實際應用場景回答，輸入數據有多大，大約多少條記錄，作了哪些邏輯操做，輸出的時候有多少條記錄，執行了多久，reduce執行時候的數據有沒有傾斜等
3）再提一下，針對mapReduce作了哪幾點優化，速度提高了多久，列舉1,2個優化點就能夠
18.你的項目提交到job的時候數據量有多大？
答：1）回答出數據是什麼格式，有沒有采用什麼壓縮，採用了壓縮的話，壓縮比大概是多少；2）文件大概多大：大概起了多少個map，起了多少個reduce，map階段讀取了多少數據，reduce階段讀取了多少數據，程序大約執行了多久，3）集羣什麼規模，集羣有多少節點，多少內存，多少CPU核數等。把這些點回答進去，而不是給個數字了事。
19.大家提交的job任務大概有多少個？這些job執行完大概用多少時間？
仍是考察你開發完程序有沒有認真觀察過程序的運行，有沒有評估程序運行的效率
20.大家業務數據量多大？有多少行數據？
這個也是看大家有沒有實際的經驗,對於沒有實戰的同窗，請把回答的側重點放在MR的運行機制上面，
MR運行效率方面，以及如何優化MR程序（看別人的優化demo，而後在虛擬機上拿demo作一下測試）。
22.如何殺死一個正在運行的job
殺死一個job
MRV1：Hadoop job kill jobid
YARN: yarn application -kill applicationId
23.列出你所知道的調度器，說明其工做原理

a) Fifo schedular 默認的調度器 先進先出

b) Capacity schedular 計算能力調度器 選擇佔用內存小 優先級高的

c) Fair schedular 調肚臍 公平調度器 全部job 佔用相同資源
24.YarnClient模式下，執行Spark SQL報這個錯，Exception in thread "Thread-2" java.lang.OutOfMemoryError: PermGen space，可是在Yarn Cluster模式下正常運行，多是什麼緣由？
1）緣由查詢過程當中調用的是Hive的獲取元數據信息、SQL解析，而且使用Cglib等進行序列化反序列化，中間可能產生較多的class文件，致使JVM中的持久代使用較多
Cluster模式的持久代默認大小是64M，Client模式的持久代默認大小是32M，而Driver端進行SQL處理時，其持久代的使用可能會達到90M，致使OOM溢出，任務失敗。
yarn-cluster模式下出現，yarn-client模式運行時卻是正常的，原來在$SPARK_HOME/bin/spark-class文件中已經設置了持久代大小：
JAVA_OPTS="-XX:MaxPermSize=256m $OUR_JAVA_OPTS"
2）解決方法:在Spark的conf目錄中的spark-defaults.conf裏，增長對Driver的JVM配置，由於Driver才負責SQL的解析和元數據獲取。配置以下：
spark.driver.extraJavaOptions -XX:PermSize=128M -XX:MaxPermSize=256M
25.spark.driver.extraJavaOptions這個參數是什麼意思，大家生產環境配了多少？
傳遞給executors的JVM選項字符串。例如GC設置或者其它日誌設置。注意，在這個選項中設置Spark屬性或者堆大小是不合法的。Spark屬性須要用SparkConf對象或者spark-submit腳本用到的spark-defaults.conf文件設置。堆內存能夠經過spark.executor.memory設置
26.致使Executor產生FULL gc 的緣由，可能致使什麼問題？
答：可能致使Executor僵死問題，海量數據的shuffle和數據傾斜等均可能致使full gc。以shuffle爲例，伴隨着大量的Shuffle寫操做，JVM的新生代不斷GC，Eden Space寫滿了就往Survivor Space寫，同時超過必定大小的數據會直接寫到老生代，當新生代寫滿了以後，也會把老的數據搞到老生代，若是老生代空間不足了，就觸發FULL GC，仍是空間不夠，那就OOM錯誤了，此時線程被Blocked，致使整個Executor處理數據的進程被卡住
27.Combiner 和partition的做用
combine分爲map端和reduce端，做用是把同一個key的鍵值對合並在一塊兒，能夠自定義的。combine函數把一個map函數產生的<key,value>對（多個key,value）合併成一個新<key2,value2>.將新的<key2,value2>做爲輸入到reduce函數中這個value2亦可稱之爲values，由於有多個。這個合併的目的是爲了減小網絡傳輸。partition是分割map每一個節點的結果，按照key分別映射給不一樣的reduce，也是能夠自定義的。這裏其實能夠理解歸類。咱們對於錯綜複雜的數據歸類。好比在動物園裏有牛羊雞鴨鵝，他們都是混在一塊兒的，可是到了晚上他們就各自牛回牛棚，羊回羊圈，雞回雞窩。partition的做用就是把這些數據歸類。只不過在寫程序的時候，mapreduce使用哈希HashPartitioner幫咱們歸類了。這個咱們也能夠自定義。shuffle就是map和reduce之間的過程，包含了兩端的combine和partition。Map的結果，會經過partition分發到Reducer上，Reducer作完Reduce操做後，通OutputFormat，進行輸出shuffle階段的主要函數是fetchOutputs(),這個函數的功能就是將map階段的輸出，copy到reduce 節點本地
28.Spark執行任務時出現java.lang.OutOfMemoryError: GC overhead limit exceeded和java.lang.OutOfMemoryError: java heap space緣由和解決方法？
答：緣由：加載了太多資源到內存，本地的性能也很差，gc時間消耗的較多
解決方法：
1）增長參數，-XX:-UseGCOverheadLimit，關閉這個特性，同時增長heap大小，-Xmx1024m
2）下面這個兩個參數調大點
export SPARK_EXECUTOR_MEMORY=6000M
export SPARK_DRIVER_MEMORY=7000M
能夠參考這個：http://www.cnblogs.com/hucn/p/3572384.html
29.請列出在你之前工做中所使用過的開發map /reduce的語言
答：java，Scala，Python，shell
30.你認爲/etc/hosts配置錯誤，會對集羣有什麼影響？
答：1）直接致使域名無法解析，主節點與子節點，子節點與子節點無法正常通信，2）間接致使配置錯誤的相關節點刪的服務不正常，甚至無法啓動，job執行失敗等等