Spark性能优化第七季
1、“钨丝计划”产生的根本背景
2、“钨丝计划”内幕详解
3、“钨丝计划”下的Shuffle
一、“钨丝计划”产生的本质原因
1、Spark作为一个一体化多元化的（大）数据处理通用平台，性能一直是其根本性的追求之一，Spark基于内存迭代（部分基于磁盘迭代）的模型，极大的满足了人们对分布式系统处理性能的渴望。但是由于Spark是采用Scala+Java语言编写的，所以运行在JVM平台，JVM让整个离散的主机容为了一体（网络即OS），但是JVM的死穴是GC，反过来限制了Spark（也就是说平台限制了Spark），所以Tungsten聚焦于CPU和Memory的使用以达到对分布式硬件潜能的终极压榨！
2、对Memory的使用，Tungsten使用了Off-Heap，也就是在JVM之外的内存空间（这就好像C语言对内存的分配、使用和销毁），此时Spark实现了自己独立的内存管理，就避免了JVM的GC引发的性能问题，其实还包含避免序列化和反序列化。
3、对于Memory管理方面，一个至关重要的内容Cache，Tungsten提出了Cache-aware computation，也就是说使用对缓存友好的算法和数据结构来完成数据的存储和复用；
4、对于CPU而言，Tungsten提出了Code Generation，其首先在Spark SQL使用，通过Tungsten要把该功能普及到Spark的所有功能中
总结：Tungsten的内存管理机制独立于JVM，所以Spark操作数据的时候具体操作的是Binary Data而不是JVM Object。而且还免去了序列化和反序列化的过程。
二、“钨丝计划”内幕详解
1、内存管理方面：
不是Java Object，没有GC问题。Spark使用sun.misc.Unsafe来进行Off-heap级别的内存分配、指针使用及内存释放。Java中64bit的引用以及具体的一个offset，GC时还会导致堆内结构的重新组织。Off-heap直接是一个指针，效率更高。Spark应用开发者不用关心On-heap或是Off-heap，管理器可以根据堆内/外进行寻址，但框架是透明的。Spark为了统一管理Off-heap和On-heap而提出了Page。Page针对堆内/堆外进行适配，寻址时包含两部分，一部分是Page，另一部分是Offset。工作机制是：Off-heap下，内存是long 64位指针。on-heap下64位Object引用以及64位offset来表述具体数据。逻辑地址映射到物理地址；
