作者：刘旭晖 Raymond 转载请注明出处

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

随着Spark的逐渐成熟完好, 越来越多的可配置參数被加入到Spark中来, 在Spark的官方文档http://spark.apache.org/docs/latest/configuration.html 中提供了这些可配置參数中相当大一部分的说明.

可是文档的更新总是落后于代码的开发的, 另一些配置參数没有来得及被加入到这个文档中, 最重要的是在这个文档中,对于很多的參数也仅仅能简单的介绍它所代表的内容的字面含义, 假设没有一定的实践基础或者对其背后原理的理解, 往往无法真正理解该怎样针对详细应用场合进行合理配置。

本文试图通过阐述这当中部分參数的工作原理和配置思路, 和大家一起探讨一下怎样依据实际场合对Spark进行配置优化。须要注意的是。理论上。没有绝对正确的配置（否则也就不须要相应的配置參数了。Spark框架内部直接写死就好了）。所以请结合自己的实际情况，辩证的看以下的内容。

因为本文主要针对和性能相关的一些配置參数进行阐述，所以基本不会覆盖其他和性能没有太多关系的配置參数。

因为篇幅较长，所以在这里分篇组织，假设要看最新完整的网页版内容，能够戳这里：http://spark-config.readthedocs.org/。主要是便于更新内容

Shuffle 相关

个分区，假设内存GC问题严重，能够降低这个值。

spark.shuffle.consolidateFiles

这个配置參数仅适用于HashShuffleMananger的实现，相同是为了解决生成过多文件的问题，採用的方式是在不同批次运行的Map任务之间重用Shuffle输出文件。也就是说合并的是不同批次的Map任务的输出数据，可是每一个Map任务所须要的文件还是取决于Reduce分区的数量。因此，它并不降低同一时候打开的输出文件的数量，因此对内存使用量的降低并没有帮助。仅仅是HashShuffleManager里的一个折中的解决方式。

须要注意的是。这部分的代码实现虽然原理上说非常easy，可是涉及究竟层详细的文件系统的实现和限制等因素，比如在并发訪问等方面，须要处理的细节非常多，因此一直存在着这样那样的bug或者问题。导致在比如EXT3上使用时。特定情况下性能反而可能下降。因此从Spark 0.8的代码開始，一直到Spark 1.1的代码为止也还没有被标志为Stable，不是默认採用的方式。此外因为并不降低同一时候打开的输出文件的数量，因此对性能详细能带来多大的改善也取决于详细的文件数量的情况。所以即使你面临着Shuffle文件数量巨大的问题，这个配置參数是否使用，在什么版本号中能够使用，也不妨实际測试以后再决定。

spark.shuffle.spill

shuffle的过程中。假设涉及到排序，聚合等操作，势必会须要在内存中维护一些数据结构，进而占用额外的内存。假设内存不够用怎么办，那仅仅有两条路能够走。一就是out of memory 出错了。二就是将部分数据暂时写到外部存储设备中去。最后再合并到终于的Shuffle输出文件里去。

这里spark.shuffle.spill 决定是否Spill到外部存储设备（默认打开）,假设你的内存足够使用。或者数据集足够小，当然也就不须要Spill。毕竟Spill带来了额外的磁盘操作。

spark.shuffle.memoryFraction/ spark.shuffle.safetyFraction

在启用Spill的情况下，spark.shuffle.memoryFraction（1.1后默觉得0.2）决定了当Shuffle过程中使用的内存达到总内存多少比例的时候開始Spill。

通过spark.shuffle.memoryFraction能够调整Spill的触发条件，即Shuffle占用内存的大小，进而调整Spill的频率和GC的行为。

总的来说，假设Spill太过频繁，能够适当添加spark.shuffle.memoryFraction的大小。添加用于Shuffle的内存，降低Spill的次数。当然这样一来为了避免内存溢出，相应的可能须要降低RDD cache占用的内存。即减小spark.storage.memoryFraction的值。这样RDD cache的容量降低，有可能带来性能影响，因此须要综合考虑。

因为Shuffle数据的大小是估算出来的，一来为了降低开销。并非每添加一个数据项都完整的估算一次。二来估算也会有误差。所以实际暂用的内存可能比估算值要大，这里spark.shuffle.safetyFraction（默觉得0.8）用来作为一个保险系数，降低实际Shuffle使用的内存阀值。添加一定的缓冲，降低实际内存占用超过用户配置值的概率。

spark.shuffle.spill.compress/ spark.shuffle.compress

这两个配置參数都是用来设置Shuffle过程中是否使用压缩算法对Shuffle数据进行压缩。前者针对Spill的中间数据，后者针对终于的shuffle输出文件，默认都是True

理论上说。spark.shuffle.compress设置为True通常都是合理的，因为假设使用千兆以下的网卡。网络带宽往往最easy成为瓶颈。此外，眼下的Spark任务调度实现中，以Shuffle划分Stage，下一个Stage的任务是要等待上一个Stage的任务所有完毕以后才干開始运行，所以shuffle数据的传输和CPU计算任务之间通常不会重叠。这样Shuffle传输数据量的大小和所需的时间就直接影响到了整个任务的完毕速度。可是压缩也是要消耗大量的CPU资源的，所以打开压缩选项会添加Map任务的运行时间，因此假设在CPU负载的影响远大于磁盘和网络带宽的影响的场合下，也可能将spark.shuffle.compress 设置为False才是最佳的方案

对于spark.shuffle.spill.compress而言，情况相似，可是spill数据不会被发送到网络中，仅仅是暂时写入本地磁盘。并且在一个任务中同一时候须要运行压缩和解压缩两个步骤。所以对CPU负载的影响会更大一些，而磁盘带宽（假设标配12HDD的话）可能往往不会成为Spark应用的主要问题，所以这个參数相对而言，也许更有机会须要设置为False。

总之，Shuffle过程中数据是否应该压缩，取决于CPU/DISK/NETWORK的实际能力和负载。应该综合考虑。