spark sql 非業務調優

1，jvm調優

這個是扯不斷，理還亂。建議能加記憶體就加記憶體，沒事調啥JVM，你都不了解JVM和你的任務資料。預設的參數已經很好了，對于GC算法，spark sql可以嘗試一些 G1。

下面文章建議多讀幾遍，記住最好。

必背|spark 記憶體，GC及資料結構調優

2，記憶體調優

緩存表

spark2.+采用：

spark 1.+采用：

Sparksql僅僅會緩存必要的列，并且自動調整壓縮算法來減少記憶體和GC壓力。

屬性

預設值

介紹

spark.sql.inMemoryColumnarStorage.compressed

true

假如設定為true，SparkSql會根據統計資訊自動的為每個列選擇壓縮方式進行壓縮。

spark.sql.inMemoryColumnarStorage.batchSize

10000

控制列緩存的批量大小。批次大有助于改善記憶體使用和壓縮，但是緩存資料會有OOM的風險

3，廣播

大小表進行join時，廣播小表到所有的Worker節點，來提升性能是一個不錯的選擇。Spark提供了兩個參數可以調整，不同版本會有些許不一樣，本文以Spark2.2.1為例講解。

描述

spark.sql.broadcastTimeout

300

廣播等待逾時時間，機關秒

spark.sql.autoBroadcastJoinThreshold

10485760 (10 MB)

最大廣播表的大小。設定為-1可以禁止該功能。目前統計資訊僅支援Hive Metastore表

廣播的變量的使用其實，有時候沒啥用處。在任務超多，誇stage使用資料的時候才能凸顯其真正作用。任務一趟跑完了，其實廣播不廣播無所謂了。。。

4，分區資料的調控

分區設定spark.sql.shuffle.partitions，預設是200.

對于有些公司來說，估計在用的時候會有Spark sql處理的資料比較少，然後資源也比較少，這時候這個shuffle分區數200就太大了，應該适當調小，來提升性能。

也有一些公司，估計在處理離線資料，資料量特别大，而且資源足，這時候shuffle分區數200，明顯不夠了，要适當調大。

适當，就完全靠經驗。

5，檔案與分區

這個總共有兩個參數可以調整：

一個是在讀取檔案的時候一個分區接受多少資料；

另一個是檔案打開的開銷，通俗了解就是小檔案合并的門檻值。

檔案打開是有開銷的，開銷的衡量，Spark 采用了一個比較好的方式就是打開檔案的開銷用，相同時間能掃描的資料的位元組數來衡量。

參數介紹如下：

屬性名稱

spark.sql.files.maxPartitionBytes

134217728 (128 MB)

打包傳入一個分區的最大位元組，在讀取檔案的時候。

spark.sql.files.openCostInBytes

4194304 (4 MB)

用相同時間内可以掃描的資料的大小來衡量打開一個檔案的開銷。當将多個檔案寫入同一個分區的時候該參數有用。該值設定大一點有好處，有小檔案的分區會比大檔案分區處理速度更快（優先排程）。

spark.sql.files.maxPartitionBytes該值的調整要結合你想要的并發度及記憶體的大小來進行。

spark.sql.files.openCostInBytes說直白一些這個參數就是合并小檔案的門檻值，小于這個門檻值的檔案将會合并。

6，檔案格式

建議parquet或者orc。Parquet已經可以達到很大的性能了。性能名額，網上一堆，在這裡浪尖就不啰嗦了。

7，sql調優

聽天由命吧。主要要熟悉業務，熟悉資料，熟悉sql解析的過程。

關于調優多說一句：

對于Spark任務的調優，要深入了解的就是資料在整個spark計算鍊條中，在每個分區的分布情況。有了這點的了解，我們就會知道資料是否傾斜，在哪傾斜，然後在針對傾斜進行調優。

分區數該增大增大，該減少減少。

記憶體要盡可能大。

表别動不動就緩存，有時候重新加載比緩存速度都快。

該廣播廣播，不該廣播的時候就别廣播，就一個批次執行完的任務你廣播毛線。

。。。。。

多測幾次，得出自己的經驗。

Spark算子在使用的時候注意事項，容浪尖後續整理。