這篇文章將為大家詳細講解有關(guān)如何解析spark sql 非業(yè)務(wù)調(diào)優(yōu)，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
創(chuàng)新互聯(lián)是創(chuàng)新、創(chuàng)意、研發(fā)型一體的綜合型網(wǎng)站建設(shè)公司，自成立以來公司不斷探索創(chuàng)新，始終堅持為客戶提供滿意周到的服務(wù)，在本地打下了良好的口碑，在過去的十多年時間我們累計服務(wù)了上千家以及全國政企客戶，如成都廣告設(shè)計等企業(yè)單位，完善的項目管理流程，嚴格把控項目進度與質(zhì)量監(jiān)控加上過硬的技術(shù)實力獲得客戶的一致表揚。
1，jvm調(diào)優(yōu)
這個是扯不斷，理還亂。建議能加內(nèi)存就加內(nèi)存，沒事調(diào)啥JVM，你都不了解JVM和你的任務(wù)數(shù)據(jù)。默認的參數(shù)已經(jīng)很好了，對于GC算法，spark sql可以嘗試一些 G1。
下面文章建議多讀幾遍，記住最好。
必背|spark 內(nèi)存，GC及數(shù)據(jù)結(jié)構(gòu)調(diào)優(yōu)
2，內(nèi)存調(diào)優(yōu)
緩存表
spark2.+采用：
重慶分公司
重慶分公司
spark.catalog.cacheTable("tableName")緩存表，spark.catalog.uncacheTable("tableName")解除緩存。 spark 1.+采用：
sqlContext.cacheTable("tableName")緩存，sqlContext.uncacheTable("tableName") 解除緩存。 Sparksql僅僅會緩存必要的列，并且自動調(diào)整壓縮算法來減少內(nèi)存和GC壓力。
屬性 | 默認值 | 介紹 |
spark.sql.inMemoryColumnarStorage.compressed | true | 假如設(shè)置為true，SparkSql會根據(jù)統(tǒng)計信息自動的為每個列選擇壓縮方式進行壓縮。 |
spark.sql.inMemoryColumnarStorage.batchSize | 10000 | 控制列緩存的批量大小。批次大有助于改善內(nèi)存使用和壓縮，但是緩存數(shù)據(jù)會有OOM的風險 |
3，廣播
大小表進行join時，廣播小表到所有的Worker節(jié)點，來提升性能是一個不錯的選擇。Spark提供了兩個參數(shù)可以調(diào)整，不同版本會有些許不一樣，本文以Spark2.2.1為例講解。
屬性 | 默認值 | 描述 |
spark.sql.broadcastTimeout | 300 | 廣播等待超時時間，單位秒 |
spark.sql.autoBroadcastJoinThreshold | 10485760 (10 MB) | 最大廣播表的大小。設(shè)置為-1可以禁止該功能。當前統(tǒng)計信息僅支持Hive Metastore表 |
廣播的變量的使用其實，有時候沒啥用處。在任務(wù)超多，夸stage使用數(shù)據(jù)的時候才能凸顯其真正作用。任務(wù)一趟跑完了，其實廣播不廣播無所謂了。。。
4，分區(qū)數(shù)據(jù)的調(diào)控
分區(qū)設(shè)置spark.sql.shuffle.partitions，默認是200.
對于有些公司來說，估計在用的時候會有Spark sql處理的數(shù)據(jù)比較少，然后資源也比較少，這時候這個shuffle分區(qū)數(shù)200就太大了，應(yīng)該適當調(diào)小，來提升性能。
也有一些公司，估計在處理離線數(shù)據(jù)，數(shù)據(jù)量特別大，而且資源足，這時候shuffle分區(qū)數(shù)200，明顯不夠了，要適當調(diào)大。
適當，就完全靠經(jīng)驗。
5，文件與分區(qū)
這個總共有兩個參數(shù)可以調(diào)整：
一個是在讀取文件的時候一個分區(qū)接受多少數(shù)據(jù)；
另一個是文件打開的開銷，通俗理解就是小文件合并的閾值。
文件打開是有開銷的，開銷的衡量，Spark 采用了一個比較好的方式就是打開文件的開銷用，相同時間能掃描的數(shù)據(jù)的字節(jié)數(shù)來衡量。
參數(shù)介紹如下：
屬性名稱 | 默認值 | 介紹 |
spark.sql.files.maxPartitionBytes | 134217728 (128 MB) | 打包傳入一個分區(qū)的最大字節(jié)，在讀取文件的時候。 |
spark.sql.files.openCostInBytes | 4194304 (4 MB) | 用相同時間內(nèi)可以掃描的數(shù)據(jù)的大小來衡量打開一個文件的開銷。當將多個文件寫入同一個分區(qū)的時候該參數(shù)有用。該值設(shè)置大一點有好處，有小文件的分區(qū)會比大文件分區(qū)處理速度更快（優(yōu)先調(diào)度）。 |
spark.sql.files.maxPartitionBytes該值的調(diào)整要結(jié)合你想要的并發(fā)度及內(nèi)存的大小來進行。
spark.sql.files.openCostInBytes說直白一些這個參數(shù)就是合并小文件的閾值，小于這個閾值的文件將會合并。
6，文件格式
建議parquet或者orc。Parquet已經(jīng)可以達到很大的性能了。性能指標，網(wǎng)上一堆，在這里浪尖就不啰嗦了。
7，sql調(diào)優(yōu)
聽天由命吧。主要要熟悉業(yè)務(wù)，熟悉數(shù)據(jù)，熟悉sql解析的過程。
關(guān)于調(diào)優(yōu)多說一句：
對于Spark任務(wù)的調(diào)優(yōu)，要深入了解的就是數(shù)據(jù)在整個spark計算鏈條中，在每個分區(qū)的分布情況。有了這點的了解，我們就會知道數(shù)據(jù)是否傾斜，在哪傾斜，然后在針對傾斜進行調(diào)優(yōu)。
分區(qū)數(shù)該增大增大，該減少減少。
內(nèi)存要盡可能大。
表別動不動就緩存，有時候重新加載比緩存速度都快。
關(guān)于如何解析spark sql 非業(yè)務(wù)調(diào)優(yōu)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
