转自: http://book.51cto.com/art/201409/453045.htm
| 问题1：reduce task数目不合适 解决方式： 需根据实际情况调节默认配置，调整方式是修改参数spark.default.parallelism。通常，reduce数目设置为core数目的2到3倍。数量太大，造成很多小任务，增加启动任务的开销；数目太少，任务运行缓慢。 |
| 问题2：shuffle磁盘IO时间长 解决方式： 设置spark.local.dir为多个磁盘，并设置磁盘为IO速度快的磁盘，通过增加IO来优化shuffle性能； |
| 问题3：map|reduce数量大，造成shuffle小文件数目多 解决方式： 默认情况下shuffle文件数目为map tasks * reduce tasks 通过设置spark.shuffle.consolidateFiles为true，来合并shuffle中间文件，此时文件数为reduce tasks数目； |
| 问题4：序列化时间长、结果大 解决方式： Spark默认使.用JDK.自带的ObjectOutputStream，这种方式产生的结果大、CPU处理时间长，可以通过设置spark.serializer为org.apache.spark.serializer.KryoSerializer。 另外如果结果已经很大，可以使用广播变量； |
| 问题5：单条记录消耗大 解决方式： 使用mapPartition替换map，mapPartition是对每个Partition进行计算，而map是对partition中的每条记录进行计算； |
| 问题6 : collect输出大量结果时速度慢 解决方式： collect源码中是把所有的结果以一个Array的方式放在内存中，可以直接输出到分布式?文件系统，然后查看文件系统中的内容； |
| 问题7: 任务执行速度倾斜 解决方案： 如果数据倾斜，一般是partition key取得不好，可以考虑其他的并行处理方式，并在中间加上aggregation操作；如果是Worker倾斜，例如在某些Worker上的executor执行缓慢，可以通过设置spark.speculation=true 把那些持续慢的节点去掉； 使用场景: 一个stage有10个task：task0~task9，分别分配到了worker0~worker9上去执行计算，其中task0~task8都只用了5s就运行成功返回了，而由于worker9本身可能由于CPU资源长期被别的线程占用、磁盘IO缓慢等缘故，造成了task9执行缓慢，迟迟不返回，于是这个stage只能慢慢等待task9的返回。也就是整个stage的运行时间被这个task9给拖后腿了。 而如果调度端如果引入了speculatable策略，那么上述事件的实际情况被改善为： step1：TaskSetManager在task0~task8成功返回后，过了一段时间检测到task9迟迟没有返回，于是认定task9：你他妈的是个speculatableTask； step2：TaskSetManager此时没有task需要调度，而且此时有speculatableTask，所以调度器决定再次调度一下task9，利用和普通task一样的调度策略将task9分发到某台机器上，不过这次不会让task9在worker9上调度了。假设新的task9调度到了worker0。 step3：这时，计算集群上就有了两个同时运行的task9。在worker0上的task9运行了5s成功返回了，这时候TaskSetManager接收到task9的成功状态，由于10个task都运行完了taskSetManager自己标识为运行完成。 PS：而那个在worker9上依然慢慢运行的task9就没什么用了，worker上的Executor会用Failed的形式。 |
| 问题8: 通过多步骤的RDD操作后有很多空任务或者小任务产生 解决方案： 使用coalesce或者repartition去减少RDD中partition数量； |
| 问题9: 通过多步骤的RDD操作后有很多空任务或者小任务产生 解决方式： 使用coalesce或repartition去减少RDD中partition数量； |
| 问题10：Spark Streaming吞吐量不高 解决方式： 可以设置spark.streaming.concurrentJobs |