近期优化了一个spark流量统计的程序,此程序跑5分钟小数据量日志不到5分钟,但相同的程序跑一天大数据量日志各种失败。经优化,使用160 vcores + 480G memory,一天的日志可在2.5小时内跑完,下面对一些优化的思路方法进行梳理。
优化的目标
保证大数据量下任务运行成功
降低资源消耗
提高计算性能
三个目标优先级依次递减,首要解决的是程序能够跑通大数据量,资源性能尽量进行优化。
基础优化
这部分主要对程序进行优化,主要考虑stage、cache、partition等方面。
提升到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由