如何進行Spark性能調(diào)優(yōu)實戰(zhàn)

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

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

1、場景：精確客戶群

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

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

3、優(yōu)化過程分析

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

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

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

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

CPU:系統(tǒng)總的task數(shù)=work數(shù)×work所占的cores數(shù)=SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES，計算task并行度，內(nèi)存分配情況，調(diào)優(yōu)參數(shù)：

SPARK_WORKER_INSTANCES=4

SPARK_WORKER_CORES = 3

SPARK_WORKER_MEMORY = 6G

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

第五步：進一步發(fā)現(xiàn)Sharkserver端出現(xiàn)明顯的fullGC,通過調(diào)優(yōu)參數(shù)

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

第六步：又發(fā)現(xiàn)當兩表關聯(lián)時，cpu 出現(xiàn)瓶頸，分析原因是日表做了gzip壓縮，優(yōu)化方法：日表不使用gzip壓縮，將日表做成內(nèi)存表。查詢從3s降到2s。

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