效能調優分類

1. 常規效能調優：分配資源、並行度等等方式。

2. JVM 調優（Java虛擬機器）：JVM相關的引數。通常情況下，如果你的硬體配置、基礎的 JVM 的配置都 ok 的話，JVM 通常不會造成太嚴重的效能問題，反而更多的是在 troubleshooting 中 JVM 佔了很重要的地位， JVM 造成線上的 spark 作業的執行報錯，甚至失敗（比如OOM）。

3. shuffle 調優（相當重要）：spark 在執行 groupByKey、reduceByKey 等操作時的 shuffle 環節的調優，這個很重要。shuffle 調優其實對 spark 作業的效能的影響是相當之高！經驗總結：在 spark 作業的執行過程中只要一牽扯到有 shuffle 的操作，基本上 shuffle 操作的效能消耗要佔到整個 spark 作業的 50%~90%。

4. spark 操作調優（spark運算元調優，比較重要）：原來使用groupByKey進行的操作現在使用 countByKey 或 aggregateByKey 來重構實現，用foreachPartition替代foreach。有些運算元的效能是比其他一些運算元的效能要高的。如果一旦遇到合適的情況，效果還是不錯的。

調優順序最好依照：

1. 分配資源、並行度、RDD架構與快取；
2. shuffle調優；
3. spark運算元調優；
4. JVM調優、廣播大變數……

理論基礎

Spark 是用 scala 開發的，大家不要以為 scala 就跟java一點關係都沒有了，這是一個很常見的錯誤。spark 的 scala 程式碼呼叫了很多 java api，scala 也是執行在 java 虛擬機器中的，spark 是執行在 java 虛擬機器中的。java虛擬機器可能會產生的問題就是記憶體不足！我們的 RDD 的快取、task執行定義的運算元函式可能會建立很多物件，都可能會佔用大量記憶體，沒搞好的話，可能導致JVM出問題。

JVM結構

JVM中的堆記憶體存放我們建立的一些物件，堆記憶體裡有年輕代（yong generation）和老年代（old generation），年輕代內部又分為三部分：Eden區域和兩個survivor 區域。理想情況下，老年代都是放一些宣告週期很長的物件，數量應該是很少的，比如資料庫連線池。

我們在 spark task 執行運算元函式的時候可能會建立很多物件，這些物件都是要放入JVM 年輕代中的。

每一次放物件的時候都是放入 eden 區域和其中一個 survivor 區域，另外一個 survivor 區域是空閒的。當 eden 區域和一個 survivor 區域放滿了以後（spark執行過程中，產生的物件實在太多了）就會觸發 minor gc（小型垃圾回收），把不再使用的物件從記憶體中清空，給後面新建立的物件騰出來點兒地方。

清理掉了不再使用的物件之後，也會將存活下來的物件（還要繼續使用的）放入之前空閒的那一個 survivor 區域中。這裡可能會出現一個問題：預設 eden、survior1 和 survivor2 的記憶體佔比是 8:1:1，問題是如果存活下來的物件是1.5，一個 survivor區域放不下，此時就可能通過JVM的擔保機制（不同JVM版本可能對應的行為）將多餘的物件直接放入老年代了。

如果你的JVM記憶體不夠大的話，可能導致頻繁的年輕代記憶體滿溢，頻繁的進行 minor gc，頻繁的 minor gc 會導致短時間內有些存活的物件多次垃圾回收都沒有回收掉，會導致這種短宣告週期（其實不一定是要長期使用的）物件年齡過大（垃圾回收次數太多還沒有回收到）跑到老年代。

老年代中可能會因為記憶體不足囤積非常多的短生命週期的，本來應該在年輕代中的可能馬上就要被回收掉的物件。此時，可能導致老年代頻繁滿溢，頻繁進行 full gc（全域性/全面垃圾回收），full gc就會去回收老年代中的物件。full gc由於這個演算法的設計針對的是老年代中的物件數量很少，滿溢進行full gc的頻率應該很少，因此採取了不太複雜，但是耗費效能和時間的垃圾回收演算法，full gc很慢。

full gc / minor gc無論是快還是慢，都會導致 jvm 的工作執行緒停止工作（stop the world）。簡而言之，就是說：gc 的時候 spark 停止工作了，等著垃圾回收結束。

記憶體不充足的時候會導致的問題： 
1. 頻繁minor gc 也會導致頻繁spark停止工作； 
2. 老年代囤積大量活躍物件（短生命週期的物件）導致頻繁full gc，full gc時間很長，短則數十秒，長則數分鐘，甚至數小時，可能導致 spark 長時間停止工作。 
3. 嚴重影響咱們的 spark 的效能和執行的速度。

JVM調優

JVM調優的第一個點：降低cache操作的記憶體佔比 
spark 中堆記憶體又被劃分成了兩塊兒，一塊兒是專門用來給 RDD 的cache、persist 操作進行 RDD 資料快取用的；另外一塊兒是用來給 spark 運算元函式的執行使用的，用來存放函式中自己建立的物件。

預設情況下，給RDD cache操作的記憶體佔比是0.6，也就是說60%的記憶體都給了cache 操作了。但是問題是如果某些情況下 cache 不是那麼的緊張，問題在於 task 運算元函式中建立的物件過多，然後記憶體又不太大，導致了頻繁的minor gc，甚至頻繁full gc，導致spark頻繁的停止工作，效能影響會很大。

針對上述這種情況，大家可以在spark ui 中yarn 的介面去檢視 spark 作業的執行統計，一層一層點選進去可以看到每個stage 的執行情況，包括每個task的執行時間、gc時間等等。如果發現gc太頻繁，時間太長，此時就可以適當調價這個比例。降低cache操作的記憶體佔比，大不了用 persist 操作選擇將一部分快取的RDD資料寫入磁碟或者序列化方式，配合Kryo序列化類減少RDD快取的記憶體佔用，降低cache操作記憶體佔比，對應的運算元函式的記憶體佔比就提升了。這個時候，可能就可以減少 minor gc 的頻率，同時減少 full gc 的頻率，對效能的提升是有一定的幫助的。

最終實現的效果就是：讓 task 執行運算元函式時，有更多的記憶體可以使用。

程式碼實現

通過spark.storage.memoryFraction引數進行調節 cache 記憶體佔比，預設是0.6，可以調節為 0.5 , 0.4 或 0.2，具體調節資料要根據 yarn 介面的spark執行統計而定。具體在專案中設定是在構建Spark上下文的時候傳入這個引數：

        SparkConf conf = new SparkConf()
                .setAppName(Constants.SPARK_APP_NAME_SESSION)
                .setMaster("local")
                .set("spark.storage.memoryFraction", "0.5")
                .set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
                .registerKryoClasses(new Class[]{
                        CategorySortKey.class,
                        IntList.class});