如何進行Spark性能調優實戰

如何進行Spark性能調優實戰，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

       Spark特別適用于多次操作特定的數據，分mem-only和mem & disk。其中mem-only:效率高，但占用大量的內存，成本很高;mem & disk:內存用完后，會自動向磁盤遷移，解決了內存不足的問題，卻帶來了數據的置換的消費。Spark常見的調優工具有nman、Jmeter和Jprofile,以下是Spark調優的一個實例分析：

1、場景：精確客戶群

對一個容量為300g的客戶信息表在spark上進行查詢優化，該大寬表有1800多列，有效使用的有20列。

2、優化達到的效果：查詢由原來的40.232s降低為2.7s

3、優化過程分析

第一步：首先發現磁盤存在大量的iowait，通過查看相關日志文件，發現一個block的大小進而推算出整個數據文件大小為300G整個內存無法容納，采用壓縮的方法實現優化，結合本數據文件的特點，存在大量的0和1，選 Gzip算法進行壓縮，壓縮后的大小為1.9G，該步使得查詢從40.232降為了20.12s。

第二步：大寬表存在1800多列，而有效使用的只有20多列，故通過RCFILE只將有效的列加載，該步使得查詢從20s降為12s。

第三步：通過Jprofile分析出CPU的負載過高，到底是什么原因造成的，仔細發現序列化機制有問題。Spark的serialization框架有兩種：java自身的和kryo的。其中kryo 是一個快速高效的Java對象圖形序列化框架,主要特點是性能、高效和易用，換成kryo后，查詢從12s降到7s。

第四步：進一步分析CPU各核負載量很不均勻，內存也沒有用滿，系統的資源沒有得到充分利用，該如何利 用？ (1)Spark的RDD的partition個數創建task的個數是對應的;(2)Partition的個數在hadoop的RDD中由block的 個數決定的，內存：系統總內存數=work內存大小*work 數=SPARK_WORKER_MEMORY*SPARK_WORKER_INSTANCES;

CPU:系統總的task數=work數×work所占的cores數=SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES，計算task并行度，內存分配情況，調優參數：

SPARK_WORKER_INSTANCES=4

SPARK_WORKER_CORES = 3

SPARK_WORKER_MEMORY = 6G

Cpu(12core)  mem(24G)，通過這幾個參數的優化，查詢由7s降到5s。

第五步：進一步發現Sharkserver端出現明顯的fullGC,通過調優參數

Export SHARK_MASTER_MEM=2g,該步由6s降到3sl;

第六步：又發現當兩表關聯時，cpu 出現瓶頸，分析原因是日表做了gzip壓縮，優化方法：日表不使用gzip壓縮，將日表做成內存表。查詢從3s降到2s。

關于如何進行Spark性能調優實戰問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。