作者介绍：涂小刚，攻城狮一枚，有代码洁癖，热爱学习，热爱生活，痛恨酱油帝、跪舔帝。目前主要从事Spark大数据平台与机器学习平台相关方向的工作，关注Spark与TensorFlow
训练数据是通过 Facebook SNS 公开数据集生成器得到，在HDFS上大小为9.3G，100个文件，添加如下两个参数以保证所有资源全部到位后才启动task，训练时间为加载数据到训练完毕这期间的耗时。
测试集群为3个节点的TS5机器搭建而成，其中一台作为RM，两台NM。除以上配置外，其他配置全部保持Spark默认状态。公共资源配置、分区设置以及算法参数如下表所示，<code>executor_memory</code>视不同的测试用例不同:
在不使用Cache的情况和使用Cache的情况下，分别测试<code>Spark-Kmeans</code>算法的训练时间以及GC时间占比，相关测试指标数据如下表所示：
从以上测试数据看来，让人有点出乎意料，一开始有点不太相信，但是多次测试后数据并没有多大的抖动，所以说Spark的性能受多方面因素的影响，单单Cache这块不同的Cache方式以及不同的资源情况下，其性能差别就相差较大，下面分析其内在原因。
不使用cache时，GC不是瓶颈，在每次迭代时均要读一遍HDFS，访问HDFS有较大的开销。从HDFS加载训练数据后直接采用Spark原生的Cache：
当<code>executor_memory</code>为2g时，不足以Cache住原始训练数据，从UI上看到Cache的比例只有33%左右，导致频繁的<code>rdd-block</code> 剔除重建，同时由于内存吃紧，可能引发较重的GC，从UI上看到GC时间占到总的task运行时间的12%左右，已经成为瓶颈，其整体性能还不如不使用Cache；
当<code>executor_memory</code>为4g时，也不足以Cache住原始训练数据，但是其Cache的比例有90%左右，同样存在<code>rdd-block</code> 剔除重建，并引发较重的GC，GC时间占总的task运行时间的7%左右，虽然比<code>executor_memory</code>为2g的情况有所好转，但是仍然不理想，只比不做Cache好7%左右，但是内存却多用了20g，并不是特别划算；
当<code>executor_memory为6g</code>时，可以全部Cache住原始训练数据，性能较优，GC占比较小，但是比不用Cache要多用40g内存，有些代价。
一般来说，当我们内存不够时，可以选择<code>MEMORY_AND_DISK</code>的缓存方式，但是测试发现<code>MEMORY_AND_DISK</code>的缓存效果并不是特别好，从测试数据来看，还不如直接使用<code>DISK_ONLY</code>的缓存方式，<code>MEMORY_AND_DISK</code>的缓存方式带来的GC开销非常大，可能是因为每次都尽可能地Cache数据到内存，不够再Spill到磁盘，同时引发频繁GC。
为了排除偶然性，拿 BigDataBenchmark 中的 PageRank 算法进行测试，分别测试各种Cache方式下整体性能，在保证每种Cache方式下都能100%Cache住数据的情况下，得到如下测试结果。
Spark的Cache并不是总是会加速任务运行，Cache的方式不同，对任务产生的影响不同。并不是能用内存Cache就用内存，而是要考虑是否有充足的内存Cache住你的数据，否则可能适得其反。在内存充足时，优先考虑使用<code>MEMORY_ONLY</code>，但是当内存不足以Cache住你的中间数据时，建议直接用<code>MEMORY_ONLY_SER(spark.rdd.compress=true)</code>或<code>DISK_ONLY</code>而不要用<code>MEMORY_AND_DISK，MEMORY_AND_DISK</code>可能会频繁地触发Spark的内存管理，增加Spill以及GC的开销。