1.压缩
KyroSerializer相比于JavaSerialize处理性能上10倍以上（综合了内存以及CPU）；但是对于基本类型比如Int等压缩效果和javaSerializer相比并没有明显优势；另外Kyro支持的Java对象类型比较少，需要做相关配置。
2. Shuffle原理以及Manager选择
Shuffle是指spark的某个节点发起，向另外一节点发送数据的行为。Shuffle在内存中整理数据后将会flush到硬盘文件中，这个过程称之为“spill”，每个Task里面会有100M的“缓存”，一旦存储数据达到了阈值比例（spill.percent，默认是0.8）则会flush到硬盘的一个临时文件中；然后基于文件进行文件传输。、
而且传输过程可能并不是之前设想的那种零拷贝，而是以数据为单位一条一条的发过去。为什么呢？因为在代码处理过程中（foreachPartition）就是逐条读取，所以要么是逐条发送，要么就是即使直接发送过去，但是数据协议保证了可以分辨每条记录。
Shuffle有两种Manager：HashManager和SortManager；
Hash Manager将会对于数据基于分区进行，如果有m个分区（mapper），目标是n个reducer，那么将会有m*n个文件。Hash在生成数据的过程中不会对文件进行排序，数据整理完成后，将会直接写入到shuffle文件中；
Sort Managere则是会对数据进行排序，然后再写入到shuffle文件中。而且sort的数据是写入到一个shuffle文件中，对于不同reducer，将会有在文件中做标记。
在实际应用中就有了性能差别，对于分区较少的场景下，或者说m*n数据较少的情况下，因为数据不需要排序，所以其shuffle性能将会优于sort manager；但是对于分区很多的场景下，因为每个文件对应一个stream，将会因为文件的开销而使得其性能严重下降，进而效率是低于sortManager。
3. Cache
缓存数据，不多说了，避免了和硬盘IO，提升性能。
4. 数据压缩
数据压缩发生在Shuffle的时候，Spark支持三种压缩算法，Snappy，LZF，LZ4；LZF以及LZ4的压缩处理速度是要好于snappy的，但是压缩率相对而言比Snappy要小。snappy的压缩率比较低，但是对于CPU压力同样比较小。LZ4各方面表现都比较好，但是同样也消耗比较大的CPU的资源；所以看资源情况和压力所在选择 / 不选择压缩算法。