性能優化概覽
why
Spark是基于內存的計算，所以集群的CPU、網絡帶寬、內存等都可能成為性能的瓶頸。
when
Spark應用開發成熟時，滿足業務要求后，就可以開展性能優化了。
what
一般來說，Spark應用程序80%的優化集中在內存、磁盤IO、網絡IO，即Driver、Executor的內存、shuffle的設置、文件系統的配置，集群的搭建，集群和文件系統的搭建（文件系統的集群在同一個局域網內）。
how
web UI+log是Spark性能優化的倚天劍和屠龍刀。
driver的log信息大致如“INFO BlockManagerMasterActor: Added rdd_0_1 in memory on mbk.local:50311 (size: 717.5 KB, free: 332.3 MB)”的日志信息。這就顯示了每個partition占用了多少內存。
內存都去哪了
Java對象頭
每個Java對象，都有一個對象頭，會占用16個字節，主要是包括了一些對象的元信息，比如指向它的類的指針。如果一個對象本身很小，比如就包括了一個int類型的field，那么它的對象頭實際上比對象自己還要大。
String對象
Java的String對象會比它內部的原始數據多出40個字節。因為它內部使用char數組來保存內部的字符序列的，并且還得保存諸如數組長度之類的信息；而且String使用的是UTF-16編碼，每個字符會占用2個字節。比如，包含10個字符的String，會占用60個字節。
集合類型
Java中的集合類型，比如HashMap和LinkedList，內部使用的是鏈表數據結構，所以對鏈表中的每一個數據，都使用了Entry對象來包裝。Entry對象不光有對象頭，還有指向下一個Entry的指針，通常占用8個字節。
其他
元素類型為原始數據類型（比如int）的集合，內部通常會使用原始數據類型的包裝類型，比如Integer，來存儲元素。
List<Integer> list = new ArrayList<Integer>()
性能優化方法
數據序列化
Spark默認序列化機制
Spark自身對于序列化的便捷性和性能進行了一個取舍和權衡。默認，Spark傾向于序列化的便捷性，使用了Java自身提供的序列化機制——基于ObjectInputStream和ObjectOutputStream的序列化機制。
Java序列化機制的缺陷
Java序列化機制的性能并不高，序列化的速度相對較慢；而且序列化以后的數據，還是相對來說比較大，還是比較占用內存空間。
Kryo序列化機制
Spark也支持使用Kryo類庫來進行序列化。Kryo序列化機制比Java序列化機制更快，而且序列化后的數據占用的空間更小，通常比Java序列化的數據占用的空間要小10倍。SparkConf().set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
Kryo使用場景
算子函數使用到了外部的大數據的情況。
比如自定義了一個MyConfiguration對象，里面包含了100m的數據。然后，在算子函數里面，使用到了這個外部的大對象。
conf.registerKryoClasses(XXX.class)
優化Kryo緩存大小
如果注冊的要序列化的自定義的類型，本身特別大，就需要調整Kryo緩存的大小，默認值是2M。SparkConf.set(“spark.kryoserializer.buffer.mb”,nM)。
數據結構優化
場景
算子中用到的內部和外部的數據，優化之后，會減少內存的消耗和占用。
優先使用數組以及字符串而不是集合類
比如將
List<Integer> list = new ArrayList<Integer>()
替換為
int[] arr = new int[]
這樣array既比List少了額外信息的存儲開銷，還能使用原始數據類型（int）來存儲數據，要節省內存的多。
將
Map<Integer, Person> persons = new HashMap<Integer, Person>()
優化為特殊的字符串格式
id:name,address|id:name,address...。
避免使用多層嵌套的對象結構
如
public class Teacher {
private List<Student> students = new ArrayList<Student>()
}
就是非常不好的例子。因為Teacher類的內部又嵌套了大量的小Student對象。優化為json字符串來存儲數據
{
"teacherId": 1,
"teacherName": "leo",
students:[
{"studentId": 1, "studentName":"tom"},
{"studentId":2, "studentName":"marry"}
]
}
盡量使用int替代String
如用int行ID替代UUID等。
RDD持久化
持久化的場景
對RDD反復使用和重要的、關鍵的、耗時長的RDD。
持久化方法
使用cache（）|persist（）方法進行持久化，使用unpersist（）方法取消持久化。
持久化策略
Spark提供的多種持久化級別，主要是為了在CPU和內存消耗之間進行取舍。優先使用MEMORY_ONLY,內存不足時使用MEMORY_ONLY_SER。
注意事項
JavaRDD<String> targetwords = words.filter(new Function<String, Boolean>() {}).cache();
不應該是
JavaRDD<String> targetwords = words.filter(new Function<String, Boolean>() {})；
targetwords.cache();
Spark自己也會在shuffle操作時進行數的持久化，主要是為了在節點失敗時避免重算整個過程。
提高并行度
Spark集群的資源并不一定會被充分利用到，所以要盡量設置合理的并行度，來充分地利用集群的資源，以充分提高Spark應用程序的性能。
Spark會自動設置以文件作為輸入源的RDD的并行度，依據其大小，比如HDFS，就會給每一個block創建一個partition，也依據這個設置并行度。對于reduceByKey等會發生shuffle的操作，就使用并行度最大的父RDD的并行度即可。
手動使用textFile()、parallelize()等方法的第二個參數來設置并行度；
使用spark.default.parallelism參數來設置統一的并行度
Spark官方的推薦是，給集群中的每個cpu core設置2~3個task。
比如說，spark-submit設置了executor數量是10個，每個executor要求分配2個core，那么application總共會有20個core。此時可以設置new SparkConf().set("spark.default.parallelism", "60")
來設置合理的并行度，從而充分利用資源。
廣播共享數據
優化前
默認情況下，算子函數使用到的外部數據，會被拷貝到每個task中，如果使用到的外部數據很大，那么就會占用大量的內存空間和網絡傳輸。
優化后
外部數據在每個節點上只保留一份副本，大大節省了內存和網絡傳輸。
廣播共享數據的用戶
創建廣播變量
...
Broadcast<T> broadcast = sc.broadcast(T);
...
使用廣播變量
...
broadcast.value();
...
數據本地化
數據本地化對性能的影響
數據本地化對于Spark Job性能有著巨大的影響，如果數據與要計算它的代碼是在一起的，那么性能當然會非常高。Spark傾向于使用最好的本地化級別來調度task，如果沒有任何未處理的數據在空閑的executor上，那么Spark就會放低本地化級別。這時有兩個選擇：等待直到executor上的cpu釋放出來，那么就分配task過去或者立即在任意一個executor上啟動一個task。
數據本地化級別
PROCESS_LOCAL：數據和計算它的代碼在同一個JVM進程中。
NODE_LOCAL：數據和計算它的代碼在一個節點上，但是不在一個進程中；
NO_PREF：數據從哪里過來，性能都是一樣的。
RACK_LOCAL：數據和計算它的代碼在一個機架上。
ANY：數據可能在任意地方，比如其他網絡環境內，或者其他機架上。
優化參數
spark.locality.wait（3000毫秒）
spark.locality.wait.node
spark.locality.wait.process
spark.locality.wait.rack
reduceByKey和groupByKey優化
如果能用reduceByKey，那就用reduceByKey，因為它會在map端，先進行本地combine，可以大大減少要傳輸到reduce端的數據量，減小網絡傳輸的開銷。
只有在reduceByKey處理不了時，才用groupByKey().map()來替代。
JVN垃圾回收調優
GC對性能的影響
默認情況下，Executor的內存空間60%用于RDD的緩存，40%分配給Task用于運行。Task很可能很快就耗光了內存而觸發GC。GC發生時將停止一切工作線程，GC本身需要花費時間，如果再頻繁發生GC，將嚴重影響Spark應用程序的性能。
GC 優化
可通過調整比例達到優化GC的目的。
SparkConf().set(“spark.storage.memoryFraction”, “0.5”)
比值在0.6~0.1之間調整。
若配合使用序列化持久化級別如MEMORY_ONLY_SER何kryo等手段，將會有更好的性能優化。
shuffle優化
spark.shuffle.consolidateFiles：是否開啟shuffle block file的合并，默認為false
spark.reducer.maxSizeInFlight：reduce task的拉取緩存，默認48m
spark.shuffle.file.buffer：map task的寫磁盤緩存，默認32k
spark.shuffle.io.maxRetries：拉取失敗的最大重試次數，默認3次
spark.shuffle.io.retryWait：拉取失敗的重試間隔，默認5s
spark.shuffle.memoryFraction：用于reduce端聚合的內存比例，默認0.2，超過比例就會溢出到磁盤上
