Spark Cache 性能测试

作者介绍：涂小刚，攻城狮一枚，有代码洁癖，热爱学习，热爱生活，痛恨酱油帝、跪舔帝。目前主要从事Spark大数据平台与机器学习平台相关方向的工作，关注Spark与TensorFlow

测试准备

训练数据是通过 Facebook SNS 公开数据集生成器得到，在HDFS上大小为9.3G，100个文件，添加如下两个参数以保证所有资源全部到位后才启动task，训练时间为加载数据到训练完毕这期间的耗时。

--conf spark.scheduler.minRegisteredResourcesRatio=1
--conf
spark.scheduler.maxRegisteredResourcesWaitingTime=10000000000

测试集群为3个节点的TS5机器搭建而成，其中一台作为RM，两台NM。除以上配置外，其他配置全部保持Spark默认状态。公共资源配置、分区设置以及算法参数如下表所示，executor_memory视不同的测试用例不同:

[1492587918645_1100_1492587919019.png]

测试用例

在不使用Cache的情况和使用Cache的情况下，分别测试Spark-Kmeans算法的训练时间以及GC时间占比，相关测试指标数据如下表所示：

[1492588024317_2410_1492588024796.png]

从以上测试数据看来，让人有点出乎意料，一开始有点不太相信，但是多次测试后数据并没有多大的抖动，所以说Spark的性能受多方面因素的影响，单单Cache这块不同的Cache方式以及不同的资源情况下，其性能差别就相差较大，下面分析其内在原因。

不使用cache时，GC不是瓶颈，在每次迭代时均要读一遍HDFS，访问HDFS有较大的开销。从HDFS加载训练数据后直接采用Spark原生的Cache：

• 当executor_memory为2g时，不足以Cache住原始训练数据，从UI上看到Cache的比例只有33%左右，导致频繁的rdd-block 剔除重建，同时由于内存吃紧，可能引发较重的GC，从UI上看到GC时间占到总的task运行时间的12%左右，已经成为瓶颈，其整体性能还不如不使用Cache；
• 当executor_memory为4g时，也不足以Cache住原始训练数据，但是其Cache的比例有90%左右，同样存在rdd-block 剔除重建，并引发较重的GC，GC时间占总的task运行时间的7%左右，虽然比executor_memory为2g的情况有所好转，但是仍然不理想，只比不做Cache好7%左右，但是内存却多用了20g，并不是特别划算；

• 当executor_memory为6g时，可以全部Cache住原始训练数据，性能较优，GC占比较小，但是比不用Cache要多用40g内存，有些代价。

一般来说，当我们内存不够时，可以选择MEMORY_AND_DISK的缓存方式，但是测试发现MEMORY_AND_DISK的缓存效果并不是特别好，从测试数据来看，还不如直接使用DISK_ONLY的缓存方式，MEMORY_AND_DISK的缓存方式带来的GC开销非常大，可能是因为每次都尽可能地Cache数据到内存，不够再Spill到磁盘，同时引发频繁GC。

交叉验证测试

为了排除偶然性，拿 BigDataBenchmark 中的 PageRank 算法进行测试，分别测试各种Cache方式下整体性能，在保证每种Cache方式下都能100%Cache住数据的情况下，得到如下测试结果。

[1492588366617_9141_1492588366833.png]

总结

Spark的Cache并不是总是会加速任务运行，Cache的方式不同，对任务产生的影响不同。并不是能用内存Cache就用内存，而是要考虑是否有充足的内存Cache住你的数据，否则可能适得其反。在内存充足时，优先考虑使用MEMORY_ONLY，但是当内存不足以Cache住你的中间数据时，建议直接用MEMORY_ONLY_SER(spark.rdd.compress=true)或DISK_ONLY而不要用MEMORY_AND_DISK，MEMORY_AND_DISK可能会频繁地触发Spark的内存管理，增加Spill以及GC的开销。