Spark&Spark性能調優實戰

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

一、場景：精確客戶羣

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

二、優化達到的效果：查詢由原來的40.232s下降爲2.7s

三、優化過程分析

第一步：首先發現磁盤存在大量的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。

四、總結

        優化是一個逐步求精的過程，回顧該優化過程，主要是從如下幾個因素考慮：(1)mem;(2)cpu;(3)dis;(4)網絡IO;(5)序列化機制。認真這些因素爲主線，挖掘與其相關的內容時行大膽嘗試。