Spark性能优化总结（建议收藏）

近期优化了一个spark流量统计的程序，此程序跑5分钟小数据量日志不到5分钟，但相同的程序跑一天大数据量日志各种失败。经优化，使用160 vcores + 480G memory，一天的日志可在2.5小时内跑完，下面对一些优化的思路方法进行梳理。

优化的目标

1. 保证大数据量下任务运行成功

2. 降低资源消耗

3. 提高计算性能

三个目标优先级依次递减，首要解决的是程序能够跑通大数据量，资源性能尽量进行优化。

基础优化

这部分主要对程序进行优化，主要考虑stage、cache、partition等方面。

我的官方群点击进入

提升到30K进阶资料,免费获取：

【社群福利】30G-PHP进阶资料，助力大家都能30K

Stage

在进行shuffle操作时，如reduceByKey、groupByKey，会划分新的stage。同一个stage内部使用pipe line进行执行，效率较高；stage之间进行shuffle，效率较低。故大数据量下，应进行代码结构优化，尽量减少shuffle操作。

Cache

本例中，首先计算出一个baseRDD，然后对其进行cache，后续启动三个子任务基于cache进行后续计算。

对于5分钟小数据量，采用StorageLevel.MEMORY_ONLY，而对于大数据下我们直接采用了StorageLevel.DISK_ONLY。DISK_ONLY_2相较DISK_ONLY具有2备份，cache的稳定性更高，但同时开销更大，cache除了在executor本地进行存储外，还需走网络传输至其他节点。后续我们的优化，会保证executor的稳定性，故没有必要采用DISK_ONLY_2。实时上，如果优化的不好，我们发现executor也会大面积挂掉，这时候即便DISK_ONLY_2，也是然并卵，所以保证executor的稳定性才是保证cache稳定性的关键。

cache是lazy执行的，这点很容易犯错，例如：

val raw = sc.textFile(file)
 val baseRDD = raw.map(...).filter(...) 
baseRDD.cache() 
val threadList = new Array( 
  new Thread(new SubTaskThead1(baseRDD)), 
  new Thread(new SubTaskThead2(baseRDD)), 
  new Thread(new SubTaskThead3(baseRDD)) 
) 
threadList.map(_.start()) 
threadList.map(_.join())

这个例子在三个子线程开始并行执行的时候，baseRDD由于lazy执行，还没被cache，这时候三个线程会同时进行baseRDD的计算，cache的功能形同虚设。可以在baseRDD.cache()后增加baseRDD.count()，显式的触发cache，当然count()是一个action，本身会触发一个job。

再举一个错误的例子：

val raw = sc.textFile(file) 
val pvLog = raw.filter(isPV(_)) 
val clLog = raw.filter(isCL(_))
val baseRDD = pvLog.union(clLog) 
val baseRDD.count()

由于textFile()也是lazy执行的，故本例会进行两次相同的hdfs文件的读取，效率较差。解决办法，是对pvLog和clLog共同的父RDD进行cache。

Partition

一个stage由