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

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

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

通过这个图我们可以看出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的文件。分区数为

但是对于用 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 就够了。