sparksql參數

全局參數：

1. --master yarn-cluster (or yarn-client)

參數說明：

制定yarn的執行模式，分集羣模式和客戶端模式，通常使用集羣模式

2. --num-executors 50

參數說明：
　　該參數用於設置Spark做業總共要用多少個Executor進程來執行。Driver在向YARN集羣管理器申請資源時，YARN集羣管理器會盡量按照你的設置來在集羣的各個工做節點上，啓動相應數量的Executor進程。這個參數很是之重要，若是不設置的話，默認只會給你啓動少許的Executor進程，此時你的Spark做業的運行速度是很是慢的。
參數調優建議：
　　每一個Spark做業的運行通常設置20~50個左右的Executor進程比較合適，設置太少或太多的Executor進程都很差。設置的太少，沒法充分利用集羣資源；設置的太多的話，大部分隊列可能沒法給予充分的資源。

3.--executor-memory 6G

參數說明：
　　該參數用於設置每一個Executor進程的內存。Executor內存的大小，不少時候直接決定了Spark做業的性能，並且跟常見的JVM OOM異常，也有直接的關聯。
參數調優建議：
　　每一個Executor進程的內存設置4G~8G較爲合適,最大不超過 20G，不然會致使 GC 代價太高，或資源浪費嚴重。可是這只是一個參考值，具體的設置仍是得根據不一樣部門的資源隊列來定。能夠看看本身團隊的資源隊列的最大內存限制是多少，num-executors乘以executor-memory，是不能超過隊列的最大內存量的。此外，若是你是跟團隊裏其餘人共享這個資源隊列，那麼申請的內存量最好不要超過資源隊列最大總內存的1/3~1/2，避免你本身的Spark做業佔用了隊列全部的資源，致使別的同窗的做業沒法運行

4.--conf spark.executor.cores=4

參數說明：
    該參數用於設置每一個Executor進程的CPU core數量。這個參數決定了每一個Executor進程並行執行task線程的能力。由於每一個CPU core同一時間只能執行一個task線程，所以每一個Executor進程的CPU core數量越多，越可以快速地執行完分配給本身的全部task線程。
參數調優建議：
    Executor的CPU executor_cores 不宜爲1！不然 work 進程中線程數過少，通常 2~4 爲宜。。一樣得根據不一樣部門的資源隊列來定，能夠看看本身的資源隊列的最大CPU core限制是多少，再依據設置的Executor數量，來決定每一個Executor進程能夠分配到幾個CPU core。一樣建議，若是是跟他人共享這個隊列，那麼num-executors * executor-cores不要超過隊列總CPU core的1/3~1/2左右比較合適，也是避免影響其餘同窗的做業運行。

5.--conf spark.yarn.executor.memoryOverhead=2048

Ececutor堆外內存 
當Spark處理超大數據量時(數十億,百億級別),executor的堆外內存可能會不夠用,出現shuffle file can’t find, task lost,OOM等狀況 
默認狀況下,這個堆外內存是300M,當運行超大數據量時,一般會出現問題,所以須要調節到1G,2G,4G等大小 
調節方法必須在spark-submit提交腳本中設置而不能在程序中設置

6.--driver-memory 2G

參數說明：
    該參數用於設置Driver進程的內存。
參數調優建議：
    Driver的內存一般來講不設置，或者設置2G左右應該就夠了。惟一須要注意的一點是，若是須要使用collect算子將RDD的數據所有拉取到Driver上進行處理，那麼必須確保Driver的內存足夠大，不然會出現OOM內存溢出、GC FULL等問題。

7.--conf spark.default.parallelism=150

參數說明：
　　spark_parallelism通常爲executor_cores*num_executors 的 1~4 倍，系統默認值 64，不設置的話會致使 task 不少的時候被分批串行執行，或大量 cores 空閒，資源浪費嚴重

8.動態executor    --避免使用

--conf spark.dynamicAllocation.enable=true //打開動態executor模式
--conf spark.shuffle.service.enabled=true //動態executor須要的服務，須要和上面的spark.dynamicAllocation.enable同時打開或關閉

9.--conf spark.storage.memoryFraction=0.2

參數說明：
　　該參數用於設置RDD持久化數據在Executor內存中能佔的比例，默認是0.6。也就是說，默認Executor 60%的內存，能夠用來保存持久化的RDD數據。

10.exector、storage內存分配

當Spark一個JOB被提交，就會開闢內存空間來存儲和計算
Spark中執行計算和數據存儲都是共享同一個內存區域（M），spark.memory.fraction 表示M的大小，其值爲相對於JVM堆內存的比例（默認0.6）。剩餘的40%是爲其餘用戶數據結構、Spark內部元數據以及避免OOM錯誤的安全預留空間（大量稀疏數據和異常大的數據記錄）。

spark.memory.storageFraction 表示數據存儲比例（R）的大小，其值爲相對於M的一個比例（默認0.5）。R是M中專門用於緩存數據塊，且這部分數據塊永遠不會因執行計算任務而逐出內存。
因此當發生FULL GC以後，有兩種辦法：
第一就是增大M區域，也就是增長--executor-memory 10G
這樣至關於增大了new generation區和old generation區，能放得下大數據塊

第二就是減少R區域，也就是減少-- spark.memory.storageFraction
這樣至關於增大了內存中用於計算的區域，從而避免FULL GC的問題

spark.memory.fraction這個參數建議保持默認值，非特殊狀況不要修改。

 

shuffle參數：

 1.--conf spark.shuffle.memoryFraction=0.5

參數說明：
    該參數用於設置shuffle過程當中一個task拉取到上個stage的task的輸出後，進行聚合操做時可以使用的Executor內存的比例，默認是0.2。

　　　　也就是說，Executor默認只有20%的內存用來進行該操做。shuffle操做在進行聚合時，若是發現使用的內存超出了這個20%的限制，那麼多餘的數據就會溢寫到磁盤文件中去，此時就會極大地下降性能。
參數調優建議：

　　若是Spark做業中的RDD持久化操做較少，shuffle操做較多時，建議下降持久化操做的內存佔比，提升shuffle操做的內存佔比比例，避免shuffle過程當中數據過多時內存不夠用，必須溢寫到磁盤上，下降了性能。此外，若是發現做業因爲頻繁的gc致使運行緩慢，意味着task執行用戶代碼的內存不夠用，那麼一樣建議調低這個參數的值。

按實際狀況設置這個參數，可是不推薦超過0.6 

2.--conf spark.sql.shuffle.partitions=20

默認值：300
spark中有partition的概念，每一個partition都會對應一個task，task越多，在處理大規模數據的時候，就會越有效率。不過task並非越多越好，若是發現數據量沒有那麼大，則沒有必要task數量太多。
其實這個參數至關於Hive參數mapred.reduce.tasks，那種大促期間數據量翻好幾倍的任務不推薦寫死這個參數，不然會形成單個task處理的數據量激增致使任務失敗或者阻塞。

3.--conf spark.shuffle.compress=true   //shuffle過程是否壓縮

4.--conf spark.shuffle.file.buffer=512

默認值：32k
參數說明：
　　該參數用於設置shuffle write task的BufferedOutputStream的buffer緩衝大小。將數據寫到磁盤文件以前，會先寫入buffer緩衝中，待緩衝寫滿以後，纔會溢寫到磁盤。
調優建議：
　　若是做業可用的內存資源較爲充足的話，能夠適當增長這個參數的大小（好比64k），從而減小shuffle write過程當中溢寫磁盤文件的次數，也就能夠減小磁盤IO次數，進而提高性能。在實踐中發現，合理調節該參數，性能會有1%~5%的提高。

5.--conf spark.reducer.maxSizeInFlight=256m

默認值：48m
參數說明：
　　該參數用於設置shuffle read task的buffer緩衝大小，而這個buffer緩衝決定了每次可以拉取多少數據。
調優建議：
　　若是做業可用的內存資源較爲充足的話，能夠適當增長這個參數的大小（好比96m），從而減小拉取數據的次數，也就能夠減小網絡傳輸的次數，進而提高性能。在實踐中發現，合理調節該參數，性能會有1%~5%的提高。

6.--conf spark.shuffle.io.maxRetries=20

默認值：3
參數說明：
　　shuffle read task從shuffle write task所在節點拉取屬於本身的數據時，若是由於網絡異常致使拉取失敗，是會自動進行重試的。該參數就表明了能夠重試的最大次數。若是在指定次數以內拉取仍是沒有成功，就可能會致使做業執行失敗。
調優建議：
　　對於那些包含了特別耗時的shuffle操做的做業，建議增長重試最大次數（好比60次），以免因爲JVM的full gc或者網絡不穩定等因素致使的數據拉取失敗。在實踐中發現，對於針對超大數據量（數十億~上百億）的shuffle過程，調節該參數能夠大幅度提高穩定性。

7.--spark.shuffle.io.retryWait=5s

默認值：5s
參數說明：
　　具體解釋同上，該參數表明了每次重試拉取數據的等待間隔，默認是5s。調優建議：建議加大間隔時長（好比60s），以增長shuffle操做的穩定性。

動態分配

 1.reducer的可伸縮化

--spark.sql.adaptive.enabled=true
--spark.sql.adaptive.shuffle.targetPostShuffleInputSize=102400000

2.JOIN過程動態廣播

--spark.sql.autoBroadcastJoinThreshold=10485760  //(10 MB)

相似Hive中的mapjoin，在join的過程當中把小於10M的小表廣播到全部節點，從而進行Hashjoin，提高join的效率。

目前動態分配在處理幾十億以上的數據量時仍是有不少未知bug缺陷，使用需謹慎