spark task与stage数量过多调优

spark task与stage数量过多调优_第1张图片
图片发自App

昨天群里的一个朋友出现了任务执行过慢。

通过运行过程来看,我们发现task比较多,更值得注意的是这些task都在一个stage之中。

首先要分析这个问题我们应该要清楚task和stage的关系。

spark task与stage数量过多调优_第2张图片
图片发自App

通过这个图我们可以看出job-stage-task的对应关系。首先job的划分是遇到action操作时,被发现后经过sparkcontext的runjob方法来到DAGscheduler,这个类中它会通过依赖关系划分出stage,一个stage是一个taskset,里面的每个task对应着rdd的一个分区。task可以理解为并行的分片。


理解了一个分区对应一个task后,可以分析得出这个问题是分区过多造成的问题。

那么我们再来看看分区数是怎么设定的。

如果在spark-default.conf中没有显示设置的话。会按照不同模式给不同的默认分区数。(spark.default.parallelism)

对于local[N]模式,因为开辟了N个线程,所以有N个core,也就默认分区为N。如果单用local那么只会开起一个分区。

如果是伪分布模式,local-cluster[x,y,z] 那么默认分区是x*y,x代表的是运行的executor数量,y是每个executor有多少个core。

如果是yarn或者是standalone模式。是用的函数max(x*y,2)前者的含义和伪分布一样,后者表示如果x*y<2,分区就取2。

在程序读取创建RDD的时候,一般会用textFile,这个函数可以读取本地或者是hdfs的文件。分区数为

rdd的分区数 = max(本地file的分片数, sc.defaultMinPartitions)
rdd的分区数 = max(hdfs文件的block数目, sc.defaultMinPartitions)


但是对于用 sc.parallelize创建的数据,是用的默认分区,也可以在第二个参数中进行显示的设置。


对于问题本身:task过多,原因是分区的问题。我们应该从分区入手,是输入的小文件太多,还是本来就会有大数据量。在分区过多时,限定分区个数看看性能是否提高,也可以在filter等操作后对分区进行一定缩减。大量使用shuffle操作使task增加(这个应该不是本问题原因,但是我们应该考虑这也是让task增加的原因),这样会完成多个stage串行会降低效率。


当我们真的无法避免这么多task时候,我们应该用最佳的参数进行调优。下面参数是来自浪尖的建议

1) executor_cores*num_executors 不宜太小或太大!一般不超过总队列 cores 的 25%,比如队列总 cores 400,最大不要超过100,最小不建议低于 40,除非日志量很小。

2) executor_cores 不宜为1!否则 work 进程中线程数过少,一般 2~4 为宜。

3) executor_memory 一般 6~10g 为宜,最大不超过 20G,否则会导致 GC 代价过高,或资源浪费严重。

4) spark_parallelism 一般为 executor_cores*num_executors 的 1~4 倍,系统默认值 64,不设置的话会导致 task 很多的时候被分批串行执行,或大量 cores 空闲,资源浪费严重。

5) driver-memory 早前有同学设置 20G,其实 driver 不做任何计算和存储,只是下发任务与yarn资源管理器和task交互,除非你是 spark-shell,否则一般 1-2g 就够了。

你可能感兴趣的:(spark task与stage数量过多调优)