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

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