问题描述与分析
题目中的问题大致可以描述为：
由于某个 Executor 没有按时向 Driver 发送心跳，而被 Driver 判断该 Executor 已挂掉，此时 Driver 要把 该 Executor 上执行的任务发送给另外一个 Executor 重新执行；
默认等待时长为 spark.network.timeout=120s
完整报错大概如下
17/01/13 09:13:08 WARN spark.HeartbeatReceiver: Removing executor 5 with no recent heartbeats: 161684 ms exceeds timeout 120000 ms
17/01/13 09:13:08 ERROR cluster.YarnClusterScheduler: Lost executor 5 on slave10: Executor heartbeat timed out after 161684 ms
17/01/13 09:13:08 WARN scheduler.TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, slave10): ExecutorLostFailure (executor 5 exited caused by one of the running tasks) Reason: Executor heartbeat timed out after 161684 ms
17/01/13 09:13:08 INFO scheduler.DAGScheduler: Executor lost: 5 (epoch 0)
17/01/13 09:13:08 INFO cluster.YarnClusterSchedulerBackend: Requesting to kill executor(s) 5
17/01/13 09:13:08 INFO scheduler.TaskSetManager: Starting task 0.1 in stage 0.0 (TID 5, slave06, partition 0,RACK_LOCAL, 8029 bytes)
17/01/13 09:13:08 INFO storage.BlockManagerMasterEndpoint: Trying to remove executor 5 from BlockManagerMaster.
17/01/13 09:13:08 INFO storage.BlockManagerMasterEndpoint: Removing block manager BlockManagerId(5, slave10, 34439)
17/01/13 09:13:08 INFO storage.BlockManagerMaster: Removed 5 successfully in removeExecutor
17/01/13 09:13:08 INFO scheduler.DAGScheduler: Host added was in lost list earlier: slave10
17/01/13 09:13:08 INFO yarn.ApplicationMaster$AMEndpoint: Driver requested to kill executor(s) 5.
17/01/13 09:13:08 INFO scheduler.TaskSetManager: Finished task 0.1 in stage 0.0 (TID 5) in 367 ms on slave06 (5/5)
17/01/13 09:13:08 INFO scheduler.DAGScheduler: ResultStage 0 (saveAsNewAPIHadoopFile at DataFrameFunctions.scala:55) finished in 162.495 s
Executor 没有按时向 Driver 发送心跳，原因可能为
1. 真的挂掉
2. 执行某任务由于资源不够造成死机
3. 其他原因
我们主要解决第二个
解决方案
增加资源---增加 memoryOverhead
简单来解释下
spark.yarn.executor.memoryOverhead 的内存是由 spark tungsten 自己的管理机制去管理，用的时候申请，用完释放，内存利用率高，【鉴于 JVM 的内存管理，GC 效率低，才有了这种管理机制】
而 spark.executor.memory 的内存是由 JVM 管理，分配，回收，涉及多种垃圾回收机制，用不好效率低
原因分析
如果用于存储 RDD 的空间不足，那么后存储的 RDD 的 partition 会覆盖之前的 RDD 的 partition，导致之前的 RDD 丢失，当使用丢失的 RDD partition 时，需要重新计算；
如果 java 堆或者永久代的内存不足，则会产生各种 OOM 情况，executor 会被杀死，spark 会重新申请一个 container 运行 executor，失败的 task 或者丢失的数据都会在这个 executor 上重新执行；
如果实际运行过程中，ExecutorMemory + MemoryOverhead 之和(JVM 进程总内存) 超过 container 容量，yarn 会直接杀死该 container，executor 日志中不会有记录，spark 会重新申请 container 运行 executor；
如果 java 堆以外的 JVM 进程占用内存较多，需要将 MemoryOverhead 设置足够大，否则 executor 将会被杀死
具体操作
spark.yarn.executor.memoryOverhead 的默认配置为 max(executorMemory * 0.10, 384)，单位为 M
我们可以手动设置
--conf spark.yarn.executor.memoryOverhead=512
--conf spark.yarn.driver.memoryOverhead=512
减少资源占用---使用 combineByKey
如 reduceByKey，可以有效的减少内存占用
rdd.repartition(20).map(mymap).groupBy(mygroup).mapValues(len).collect()
rdd.repartition(20).map(mymap).map(mygroup).reduceByKey(lambda x, y: x+y).collect()
另外还有几种较为简单的方法
1. 增加等待时长 spark.network.timeout
2. 在资源不变的情况下，增加 executor 内存，减少 executor 数量，增加 executor cores，这个自己想想，反正就是总的不变，保证每个 task 有足够内存
