Spark性能優(yōu)化第七季

1、“鎢絲計劃”產生的根本背景
2、“鎢絲計劃”內幕詳解
3、“鎢絲計劃”下的Shuffle
一、“鎢絲計劃”產生的本質原因
1、Spark作為一個一體化多元化的（大）數(shù)據(jù)處理通用平臺，性能一直是其根本性的追求之一，Spark基于內存迭代（部分基于磁盤迭代）的模型，極大的滿足了人們對分布式系統(tǒng)處理性能的渴望。但是由于Spark是采用Scala+Java語言編寫的，所以運行在JVM平臺，JVM讓整個離散的主機容為了一體（網絡即OS），但是JVM的死穴是GC，反過來限制了Spark（也就是說平臺限制了Spark），所以Tungsten聚焦于CPU和Memory的使用以達到對分布式硬件潛能的終極壓榨！
2、對Memory的使用，Tungsten使用了Off-Heap，也就是在JVM之外的內存空間（這就好像C語言對內存的分配、使用和銷毀），此時Spark實現(xiàn)了自己獨立的內存管理，就避免了JVM的GC引發(fā)的性能問題，其實還包含避免序列化和反序列化。
3、對于Memory管理方面，一個至關重要的內容Cache，Tungsten提出了Cache-aware computation，也就是說使用對緩存友好的算法和數(shù)據(jù)結構來完成數(shù)據(jù)的存儲和復用；
4、對于CPU而言，Tungsten提出了Code Generation，其首先在Spark SQL使用，通過Tungsten要把該功能普及到Spark的所有功能中
總結：Tungsten的內存管理機制獨立于JVM，所以Spark操作數(shù)據(jù)的時候具體操作的是Binary Data而不是JVM Object。而且還免去了序列化和反序列化的過程。
二、“鎢絲計劃”內幕詳解
1、內存管理方面：
不是Java Object，沒有GC問題。Spark使用sun.misc.Unsafe來進行Off-heap級別的內存分配、指針使用及內存釋放。Java中64bit的引用以及具體的一個offset，GC時還會導致堆內結構的重新組織。Off-heap直接是一個指針，效率更高。Spark應用開發(fā)者不用關心On-heap或是Off-heap，管理器可以根據(jù)堆內/外進行尋址，但框架是透明的。Spark為了統(tǒng)一管理Off-heap和On-heap而提出了Page。Page針對堆內/堆外進行適配，尋址時包含兩部分，一部分是Page，另一部分是Offset。工作機制是：Off-heap下，內存是long 64位指針。on-heap下64位Object引用以及64位offset來表述具體數(shù)據(jù)。邏輯地址映射到物理地址