Spark-submit 參數(shù)調(diào)優(yōu)完整攻略

點(diǎn)擊上方藍(lán)色字體，選擇“設(shè)為星標(biāo)”

--sparksubmit

--num-executors??

該參數(shù)主要用于設(shè)置該應(yīng)用總共需要多少executors來(lái)執(zhí)行，Driver在向集群資源管理器申請(qǐng)資源時(shí)需要根據(jù)此參數(shù)決定分配的Executor個(gè)數(shù)，并盡量滿(mǎn)足所需。在不帶的情況下只會(huì)分配少量Executor。這個(gè)值得設(shè)置還是要看分配的隊(duì)列的資源情況，太少了無(wú)法充分利用集群資源，太多了則難以分配需要的資源。

--executor-memory

設(shè)置每個(gè)executor的內(nèi)存，對(duì)Spark作業(yè)運(yùn)行的性能影響很大。一般4-8G就差不多了，當(dāng)然還要看資源隊(duì)列的情況。num-executor*executor-memory的大小絕不能超過(guò)隊(duì)列的內(nèi)存總大小。

--executor-cores

設(shè)置每個(gè)executor的cpu核數(shù)，其決定了每個(gè)executor并行執(zhí)行task的能力。Executor的CPU core數(shù)量設(shè)置為2-4個(gè)即可。但要注意，num-executor*executor-cores也不能超過(guò)分配隊(duì)列中cpu核數(shù)的大小。具體的核數(shù)的設(shè)置需要根據(jù)分配隊(duì)列中資源統(tǒng)籌考慮，取得Executor，核數(shù)，及任務(wù)數(shù)的平衡。對(duì)于多任務(wù)共享的隊(duì)列，更要注意不能將資源占滿(mǎn)? ??

--driver-memory

運(yùn)行sparkContext的Driver所在所占用的內(nèi)存，通常不必設(shè)置，設(shè)置的話1G就足夠了，除非是需要使用collect之類(lèi)算子經(jīng)常需要將數(shù)據(jù)提取到driver中的情況。

? --total-executor-cores? ??

是所有executor總共使用的cpu核數(shù) standalone default all cores

--conf

?--conf spark.default.parallelism

此參數(shù)用于設(shè)置每個(gè)stage經(jīng)TaskScheduler進(jìn)行調(diào)度時(shí)生成task的數(shù)量，此參數(shù)未設(shè)置時(shí)將會(huì)根據(jù)讀到的RDD的分區(qū)生成task，即根據(jù)源數(shù)據(jù)在hdfs中的分區(qū)數(shù)確定，若此分區(qū)數(shù)較小，則處理時(shí)只有少量task在處理，前述分配的executor中的core大部分無(wú)任務(wù)可干。通常可將此值設(shè)置為num-executors*executor-cores的2-3倍為宜，如果與其相近的話，則對(duì)于先完成task的core則無(wú)任務(wù)可干。2-3倍數(shù)量關(guān)系的話即不至于太零散，又可使得任務(wù)執(zhí)行更均衡。

--conf spark.storage.memoryFraction

參數(shù)說(shuō)明：該參數(shù)用于設(shè)置RDD持久化數(shù)據(jù)在Executor內(nèi)存中能占的比例，默認(rèn)是0.6。也就是說(shuō)，默認(rèn)Executor 60%的內(nèi)存，可以用來(lái)保存持久化的RDD數(shù)據(jù)。根據(jù)你選擇的不同的持久化策略，如果內(nèi)存不夠時(shí)，可能數(shù)據(jù)就不會(huì)持久化，或者數(shù)據(jù)會(huì)寫(xiě)入磁盤(pán)。

參數(shù)調(diào)優(yōu)建議：如果Spark作業(yè)中，有較多的RDD持久化操作，該參數(shù)的值可以適當(dāng)提高一些，保證持久化的數(shù)據(jù)能夠容納在內(nèi)存中。避免內(nèi)存不夠緩存所有的數(shù)據(jù)，導(dǎo)致數(shù)據(jù)只能寫(xiě)入磁盤(pán)中，降低了性能。但是如果Spark作業(yè)中的shuffle類(lèi)操作比較多，而持久化操作比較少，那么這個(gè)參數(shù)的值適當(dāng)降低一些比較合適。此外，如果發(fā)現(xiàn)作業(yè)由于頻繁的gc導(dǎo)致運(yùn)行緩慢（通過(guò)spark web ui可以觀察到作業(yè)的gc耗時(shí)），意味著task執(zhí)行用戶(hù)代碼的內(nèi)存不夠用，那么同樣建議調(diào)低這個(gè)參數(shù)的值。個(gè)人不太建議調(diào)該參數(shù)

--conf spark.shuffle.memoryFraction

參數(shù)說(shuō)明：該參數(shù)用于設(shè)置shuffle過(guò)程中一個(gè)task拉取到上個(gè)stage的task的輸出后，進(jìn)行聚合操作時(shí)能夠使用的Executor內(nèi)存的比例，默認(rèn)是0.2。也就是說(shuō)，Executor默認(rèn)只有20%的內(nèi)存用來(lái)進(jìn)行該操作。shuffle操作在進(jìn)行聚合時(shí)，如果發(fā)現(xiàn)使用的內(nèi)存超出了這個(gè)20%的限制，那么多余的數(shù)據(jù)就會(huì)溢寫(xiě)到磁盤(pán)文件中去，此時(shí)就會(huì)極大地降低性能。

參數(shù)調(diào)優(yōu)建議：如果Spark作業(yè)中的RDD持久化操作較少，shuffle操作較多時(shí)，建議降低持久化操作的內(nèi)存占比，提高shuffle操作的內(nèi)存占比比例，避免shuffle過(guò)程中數(shù)據(jù)過(guò)多時(shí)內(nèi)存不夠用，必須溢寫(xiě)到磁盤(pán)上，降低了性能。此外，如果發(fā)現(xiàn)作業(yè)由于頻繁的gc導(dǎo)致運(yùn)行緩慢，意味著task執(zhí)行用戶(hù)代碼的內(nèi)存不夠用，那么同樣建議調(diào)低這個(gè)參數(shù)的值。個(gè)人不太建議調(diào)該參數(shù)

--conf spark.sql.codegen

默認(rèn)值為false，當(dāng)它設(shè)置為true時(shí)，Spark SQL會(huì)把每條查詢(xún)的語(yǔ)句在運(yùn)行時(shí)編譯為java的二進(jìn)制代碼。這有什么作用呢？它可以提高大型查詢(xún)的性能，但是如果進(jìn)行小規(guī)模的查詢(xún)的時(shí)候反而會(huì)變慢，就是說(shuō)直接用查詢(xún)反而比將它編譯成為java的二進(jìn)制代碼快。所以在優(yōu)化這個(gè)選項(xiàng)的時(shí)候要視情況而定。

這個(gè)選項(xiàng)可以讓Spark SQL把每條查詢(xún)語(yǔ)句在運(yùn)行前編譯為java二進(jìn)制代碼，由于生成了專(zhuān)門(mén)運(yùn)行指定查詢(xún)的代碼，codegen可以讓大型查詢(xún)或者頻繁重復(fù)的查詢(xún)明顯變快，然而在運(yùn)行特別快（1-2秒）的即時(shí)查詢(xún)語(yǔ)句時(shí)，codegen就可能增加額外的開(kāi)銷(xiāo)（將查詢(xún)語(yǔ)句編譯為java二進(jìn)制文件）。codegen還是一個(gè)實(shí)驗(yàn)性的功能，但是在大型的或者重復(fù)運(yùn)行的查詢(xún)中使用codegen

--conf spark.sql.inMemoryColumnStorage.compressed

默認(rèn)值為false 它的作用是自動(dòng)對(duì)內(nèi)存中的列式存儲(chǔ)進(jìn)行壓縮

--conf spark.sql.inMemoryColumnStorage.batchSize? ??

默認(rèn)值為1000 這個(gè)參數(shù)代表的是列式緩存時(shí)的每個(gè)批處理的大小。如果將這個(gè)值調(diào)大可能會(huì)導(dǎo)致內(nèi)存不夠的異常，所以在設(shè)置這個(gè)的參數(shù)的時(shí)候得注意你的內(nèi)存大小

在緩存SchemaRDD（Row RDD）時(shí)，Spark SQL會(huì)安照這個(gè)選項(xiàng)設(shè)定的大小（默認(rèn)為1000）把記錄分組，然后分批次壓縮。

太小的批處理會(huì)導(dǎo)致壓縮比過(guò)低，而太大的話，比如當(dāng)每個(gè)批處理的數(shù)據(jù)超過(guò)內(nèi)存所能容納的大小時(shí)，也有可能引發(fā)問(wèn)題。

如果你表中的記錄比價(jià)大（包含數(shù)百個(gè)字段或者包含像網(wǎng)頁(yè)這樣非常大的字符串字段），就可能需要調(diào)低批處理的大小來(lái)避免內(nèi)存不夠（OOM）的錯(cuò)誤。如果不是在這樣的場(chǎng)景下，默認(rèn)的批處理 的大小是比較合適的，因?yàn)閴嚎s超過(guò)1000條壓縮記錄時(shí)也基本無(wú)法獲得更高的壓縮比了。

--conf spark.sql.parquet.compressed.codec

默認(rèn)值為snappy 這個(gè)參數(shù)代表使用哪種壓縮編碼器。可選的選項(xiàng)包括uncompressed/snappy/gzip/lzo ?? ? ? uncompressed這個(gè)顧名思義就是不用壓縮的意思

--conf spark.speculation?

推測(cè)執(zhí)行優(yōu)化機(jī)制采用了典型的以空間換時(shí)間的優(yōu)化策略，它同時(shí)啟動(dòng)多個(gè)相同task（備份任務(wù)）處理相同的數(shù)據(jù)塊，哪個(gè)完成的早，則采用哪個(gè)task的結(jié)果，這樣可防止拖后腿Task任務(wù)出現(xiàn)，進(jìn)而提高作業(yè)計(jì)算速度，但是，這樣卻會(huì)占用更多的資源，在集群資源緊缺的情況下，設(shè)計(jì)合理的推測(cè)執(zhí)行機(jī)制可在多用少量資源情況下，減少大作業(yè)的計(jì)算時(shí)間。

檢查邏輯代碼中注釋很明白，當(dāng)成功的Task數(shù)超過(guò)總Task數(shù)的75%(可通過(guò)參數(shù)spark.speculation.quantile設(shè)置)時(shí)，再統(tǒng)計(jì)所有成功的Tasks的運(yùn)行時(shí)間，得到一個(gè)中位數(shù)，用這個(gè)中位數(shù)乘以1.5(可通過(guò)參數(shù)spark.speculation.multiplier控制)得到運(yùn)行時(shí)間門(mén)限，如果在運(yùn)行的Tasks的運(yùn)行時(shí)間超過(guò)這個(gè)門(mén)限，則對(duì)它啟用推測(cè)。簡(jiǎn)單來(lái)說(shuō)就是對(duì)那些拖慢整體進(jìn)度的Tasks啟用推測(cè)，以加速整個(gè)Stage的運(yùn)行

• spark.speculation.interval ?? 100毫秒? ? Spark經(jīng)常檢查要推測(cè)的任務(wù)。

• spark.speculation.multiplier ?? 1.5 ?? 任務(wù)的速度比投機(jī)的中位數(shù)慢多少倍。

• spark.speculation.quantile ?? 0.75 ?? 在為特定階段啟用推測(cè)之前必須完成的任務(wù)的分?jǐn)?shù)。

? ? ? ??

--conf spark.shuffle.consolidateFiles

默認(rèn)值：false

參數(shù)說(shuō)明：如果使用HashShuffleManager，該參數(shù)有效。如果設(shè)置為true，那么就會(huì)開(kāi)啟consolidate機(jī)制，會(huì)大幅度合并shuffle write的輸出文件，對(duì)于shuffle read task數(shù)量特別多的情況下，這種方法可以極大地減少磁盤(pán)IO開(kāi)銷(xiāo)，提升性能。

調(diào)優(yōu)建議：如果的確不需要SortShuffleManager的排序機(jī)制，那么除了使用bypass機(jī)制，還可以嘗試將spark.shffle.manager參數(shù)手動(dòng)指定為hash，使用HashShuffleManager，同時(shí)開(kāi)啟consolidate機(jī)制。在實(shí)踐中嘗試過(guò)，發(fā)現(xiàn)其性能比開(kāi)啟了bypass機(jī)制的SortShuffleManager要高出10%~30%。? ??

--conf spark.shuffle.file.buffer? ??

默認(rèn)值：32k

參數(shù)說(shuō)明：該參數(shù)用于設(shè)置shuffle write task的BufferedOutputStream的buffer緩沖大小。將數(shù)據(jù)寫(xiě)到磁盤(pán)文件之前，會(huì)先寫(xiě)入buffer緩沖中，待緩沖寫(xiě)滿(mǎn)之后，才會(huì)溢寫(xiě)到磁盤(pán)。

調(diào)優(yōu)建議：如果作業(yè)可用的內(nèi)存資源較為充足的話，可以適當(dāng)增加這個(gè)參數(shù)的大小（比如64k，一定是成倍的增加），從而減少shuffle write過(guò)程中溢寫(xiě)磁盤(pán)文件的次數(shù)，也就可以減少磁盤(pán)IO次數(shù)，進(jìn)而提升性能。在實(shí)踐中發(fā)現(xiàn)，合理調(diào)節(jié)該參數(shù)，性能會(huì)有1%~5%的提升。

--conf spark.reducer.maxSizeInFlight

默認(rèn)值：48m

參數(shù)說(shuō)明：該參數(shù)用于設(shè)置shuffle read task的buffer緩沖大小，而這個(gè)buffer緩沖決定了每次能夠拉取多少數(shù)據(jù)。

調(diào)優(yōu)建議：如果作業(yè)可用的內(nèi)存資源較為充足的話，可以適當(dāng)增加這個(gè)參數(shù)的大小（比如96m），從而減少拉取數(shù)據(jù)的次數(shù)，也就可以減少網(wǎng)絡(luò)傳輸?shù)拇螖?shù)，進(jìn)而提升性能。在實(shí)踐中發(fā)現(xiàn)，合理調(diào)節(jié)該參數(shù)，性能會(huì)有1%~5%的提升。

--conf spark.shuffle.io.maxRetries

默認(rèn)值：3

參數(shù)說(shuō)明：shuffle read task從shuffle write task所在節(jié)點(diǎn)拉取屬于自己的數(shù)據(jù)時(shí)，如果因?yàn)榫W(wǎng)絡(luò)異常導(dǎo)致拉取失敗，是會(huì)自動(dòng)進(jìn)行重試的。該參數(shù)就代表了可以重試的最大次數(shù)。如果在指定次數(shù)之內(nèi)拉取還是沒(méi)有成功，就可能會(huì)導(dǎo)致作業(yè)執(zhí)行失敗。

調(diào)優(yōu)建議：對(duì)于那些包含了特別耗時(shí)的shuffle操作的作業(yè)，建議增加重試最大次數(shù)（比如60次），以避免由于JVM的full gc或者網(wǎng)絡(luò)不穩(wěn)定等因素導(dǎo)致的數(shù)據(jù)拉取失敗。在實(shí)踐中發(fā)現(xiàn)，對(duì)于針對(duì)超大數(shù)據(jù)量（數(shù)十億~上百億）的shuffle過(guò)程，調(diào)節(jié)該參數(shù)可以大幅度提升穩(wěn)定性。

taskScheduler不負(fù)責(zé)重試task，由DAGScheduler負(fù)責(zé)重試stage

--conf spark.shuffle.io.retryWait

默認(rèn)值：5s

參數(shù)說(shuō)明：具體解釋同上，該參數(shù)代表了每次重試?yán)?shù)據(jù)的等待間隔，默認(rèn)是5s。

調(diào)優(yōu)建議：建議加大間隔時(shí)長(zhǎng)（比如60s），以增加shuffle操作的穩(wěn)定性。

--conf spark.shuffle.memoryFraction

默認(rèn)值：0.2

參數(shù)說(shuō)明：該參數(shù)代表了Executor內(nèi)存中，分配給shuffle read task進(jìn)行聚合操作的內(nèi)存比例，默認(rèn)是20%。

調(diào)優(yōu)建議：在資源參數(shù)調(diào)優(yōu)中講解過(guò)這個(gè)參數(shù)。如果內(nèi)存充足，而且很少使用持久化操作，建議調(diào)高這個(gè)比例，給shuffle read的聚合操作更多內(nèi)存，以避免由于內(nèi)存不足導(dǎo)致聚合過(guò)程中頻繁讀寫(xiě)磁盤(pán)。在實(shí)踐中發(fā)現(xiàn)，合理調(diào)節(jié)該參數(shù)可以將性能提升10%左右。? ??

--conf spark.shuffle.manager

默認(rèn)值：sort|hash

參數(shù)說(shuō)明：該參數(shù)用于設(shè)置ShuffleManager的類(lèi)型。Spark 1.5以后，有三個(gè)可選項(xiàng)：hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默認(rèn)選項(xiàng)，但是Spark 1.2以及之后的版本默認(rèn)都是SortShuffleManager了。tungsten-sort與sort類(lèi)似，但是使用了tungsten計(jì)劃中的堆外內(nèi)存管理機(jī)制，內(nèi)存使用效率更高。

調(diào)優(yōu)建議：由于SortShuffleManager默認(rèn)會(huì)對(duì)數(shù)據(jù)進(jìn)行排序，因此如果你的業(yè)務(wù)邏輯中需要該排序機(jī)制的話，則使用默認(rèn)的SortShuffleManager就可以；而如果你的業(yè)務(wù)邏輯不需要對(duì)數(shù)據(jù)進(jìn)行排序，那么建議參考后面的幾個(gè)參數(shù)調(diào)優(yōu)，通過(guò)bypass機(jī)制或優(yōu)化的HashShuffleManager來(lái)避免排序操作，同時(shí)提供較好的磁盤(pán)讀寫(xiě)性能。這里要注意的是，tungsten-sort要慎用，因?yàn)橹鞍l(fā)現(xiàn)了一些相應(yīng)的bug。

--conf spark.shuffle.sort.bypassMergeThreshold

默認(rèn)值：200

參數(shù)說(shuō)明：當(dāng)ShuffleManager為SortShuffleManager時(shí)，如果shuffle read task的數(shù)量小于這個(gè)閾值（默認(rèn)是200），則shuffle write過(guò)程中不會(huì)進(jìn)行排序操作，而是直接按照未經(jīng)優(yōu)化的HashShuffleManager的方式去寫(xiě)數(shù)據(jù)，但是最后會(huì)將每個(gè)task產(chǎn)生的所有臨時(shí)磁盤(pán)文件都合并成一個(gè)文件，并會(huì)創(chuàng)建單獨(dú)的索引文件。

調(diào)優(yōu)建議：當(dāng)你使用SortShuffleManager時(shí)，如果的確不需要排序操作，那么建議將這個(gè)參數(shù)調(diào)大一些，大于shuffle read task的數(shù)量。那么此時(shí)就會(huì)自動(dòng)啟用bypass機(jī)制，map-side就不會(huì)進(jìn)行排序了，減少了排序的性能開(kāi)銷(xiāo)。但是這種方式下，依然會(huì)產(chǎn)生大量的磁盤(pán)文件，因此shuffle write性能有待提高。

--conf spark.shuffle.consolidateFiles

默認(rèn)值：false

參數(shù)說(shuō)明：如果使用HashShuffleManager，該參數(shù)有效。如果設(shè)置為true，那么就會(huì)開(kāi)啟consolidate機(jī)制，會(huì)大幅度合并shuffle write的輸出文件，對(duì)于shuffle read task數(shù)量特別多的情況下，這種方法可以極大地減少磁盤(pán)IO開(kāi)銷(xiāo)，提升性能。

調(diào)優(yōu)建議：如果的確不需要SortShuffleManager的排序機(jī)制，那么除了使用bypass機(jī)制，還可以嘗試將spark.shffle.manager參數(shù)手動(dòng)指定為hash，使用HashShuffleManager，同時(shí)開(kāi)啟consolidate機(jī)制。在實(shí)踐中嘗試過(guò)，發(fā)現(xiàn)其性能比開(kāi)啟了bypass機(jī)制的SortShuffleManager要高出10%~30%。

文章不錯(cuò)？點(diǎn)個(gè)【在看】吧！??