这两个例外应该分开讨论。
对于metadatafetchfailedexception，通常发生在一个执行器突然被杀死或终止时，但是这个执行器有一些shuffle输出，然后当另一个执行器尝试获取这个shuffle输出的元数据时，就会发生异常。
1） 在大多数情况下，这是由超过内存限制而被Yarn杀死的容器造成的。所以你需要在日志中再次确认。
2） 最常见的修复方法是增加memoryoverhead，默认值是0.1executor内存。这对大多数情况来说太小了。我建议把它设为0.2executor内存。如果有大量的执行者或运行另一个子进程，则需要更大的值。
对于fetchfailedexception，它通常发生在承载某个shuffle输出的一个执行器太忙或暂时死机时。这可能是由于磁盘io或网络io速度慢造成的。当你有超过1000名遗嘱执行人时，这可能很常见。
1） 你首先要检查的是这个遗嘱执行人是否真的死了。你可以在死亡执行者列表中确认这一点。然后检查那个死去的执行者的日志。
2） 当您有1000个执行器时，最坏的情况是一个执行器最多可能有1000个来自其他执行器的tcp连接，这些连接可以获取1000个不同的文件。这可能会很慢。
3） 我们可以增加重试次数和连接等待队列。您可以尝试以下配置

--conf spark.blacklist.enabled=true # blacklist bad machine
--conf spark.reducer.maxReqsInFlight=10 # limit concurrent requests from reducer 
--conf spark.shuffle.io.retryWait=10s # increase retry wait
--conf spark.shuffle.io.maxRetries=10 # increase retry times
--conf spark.shuffle.io.backLog=4096 # increase tcp connection wait queue length

如果所有的洗牌任务都失败了，那么可能的原因是netty的依赖冲突。从spark core中排除网络依赖对我来说很有效。

<dependency>
            <groupId>org.apache.spark</groupId>
            <artifactId>spark-core_2.10</artifactId>
            <version>${spark.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>io.netty</groupId>
                    <artifactId>netty-all</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>io.netty</groupId>
                    <artifactId>netty</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

除了上面描述的内存和网络配置问题之外，值得注意的是，对于大型表（例如，这里有几个tb），org.apache.spark.shuffle.fetchfailedexception可能由于检索shuffle分区超时而发生。要解决此问题，可以设置以下选项：

SET spark.reducer.maxReqsInFlight=1;  -- Only pull one file at a time to use full network bandwidth.
SET spark.shuffle.io.retryWait=60s;  -- Increase the time to wait while retrieving shuffle partitions before retrying. Longer times are necessary for larger files.
SET spark.shuffle.io.maxRetries=10;

通过增加Spark超时时间，我也得到了一些好的结果 spark.network.timeout 更大的值，比如800。默认的120秒会导致很多执行者在重载时超时。

这个错误几乎肯定是由执行器上的内存问题引起的。我可以想出几种方法来解决这类问题。
1） 您可以尝试使用更多分区运行（执行 repartition 在你的 dataframe ). 当一个或多个分区包含的数据超过内存容量时，通常会出现内存问题。
2） 我注意到你没有明确地设定 spark.yarn.executor.memoryOverhead ，因此它将默认为 max(386, 0.10* executorMemory) 在你的情况下是400mb。对我来说这听起来很低。我会尝试将它增加到1gb（注意，如果将memoryoverhead增加到1gb，则需要降低内存） --executor-memory 到3gb）
3） 查看失败节点上的日志文件。你想寻找文本“杀死容器”。如果你看到“运行超出物理内存限制”这段文字，根据我的经验，增加内存将解决问题。

好吧，这是一个旧的线程，在stackoverflow上有很多答案，但我为此错误损失了几天时间，我认为分享这个故事可能会有所帮助。
实际上有几种方法可以做到这一点。正如glennie的回答提到的，这很可能是一个内存问题，所以确保你有足够的内存来处理所有的事情。有容器内存，调幅内存，Map内存，减少内存等配置要注意。阅读本文对于找到正确的配置有很大的帮助。你应该自己选择数字，但这里有一些属性，我设置。
yarn-site.xml文件

<property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>32768</value>
</property>

<property>
    <name>yarn.app.mapreduce.am.resource.mb</name>
    <value>4096</value>
</property>

<property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>4096</value>
</property>

mapred-site.xml文件

<property>
    <name>mapreduce.map.memory.mb</name>
    <value>4096</value>
</property>

<property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>4096</value>
</property>

这些可以修复您可能遇到的其他一些错误，例如pyspark shell在启动时崩溃。但是在我的例子中，虽然一些错误消失了（比如metadatafetchfailed错误），但是问题仍然存在。确切的错误是：
org.apache.spark.shuffle.fetchfailedexception:无法连接到db-eta-c/x.x.x.x:34085
在研究了从spark超时到yarn shuffle服务的所有可能的yarn和spark属性之后，我最终意识到，在错误日志中，失败的容器正在查找 x.x.x.x ，运行时的本地（内部）ip netstat -tulpn | grep <PORT NUM> 返回y.y.y.y:34085，其中y.y.y.y是外部ip地址。这根本不是内存问题，只是网络配置问题。
spark服务仅绑定到外部接口，因为主机名与中的外部ip相关联 /etc/hosts . 在更新 /etc/hosts 文件问题已修复。
一句话：这个错误显然说明某些容器无法到达另一个容器。这通常是由于内存问题导致容器失败，但也可能是网络问题，因此也要注意这些问题，特别是在节点上有多个接口的情况下。