Spark On Yarn的两种模式yarn-cluster和yarn-client深度剖析

转至： >

下面我们从源代码的角度来解释。

首先看下Spark-Shell命令，其中它会调用main方法

在mian方法中，会调用spark-submit 并传入—class的参数(入口类)为orgapachesparkreplMain，设置应用程序名—name “Spark shell” 传入spark-shell接收的所有参数$@。

而在Spark-submit中是通过exec命令启动进程的，如下图：

总结：所用的应用程序最后的提交都是由spark-submit完成的，其他程序的调用只是对spark-submit的参数进行设置后，调用spark-submit来完成应用程序的提交到集群的 *** 作。

发现在2019-01-16 15:53:11,748:

最终executor和driver的心跳失效：

此外还有大量shuffle异常日志：

shuffle异常是否也是失败的根因？

1由于无法获取到driver日志，没法做更多的分析。先排除推测机制的干扰。让客户关闭掉spark推测机制：sparkspeculation

2关闭掉推测机制后，任务运行也失败了。启动executor失败的次数达到上限

并且失败都有大量的socket异常打印,executor和driver网络通信中断：

还是怀疑是网络的问题

1分析AM日志，发现AM日志从15点到之后都没有任何打印：

发现TID 13203 执行了40多min，在stage 31。虽然stage31的某个task执行慢，但是最终是执行成功的。spark的shuffle对网络性能要求比较高，准备进行如下shuffle调优，避免单个task问题：

准备进行如下调整：调优化shuffle参数：

sparkshufflefilebuffer=64k，

sparkreducermaxSizeInFlight=96M

sparknetworktimeout=300s

sparkrpcaskTimeout=300s

sparkshuffleioserverThreads=8

1部分task执行慢，是由于shuffle性能影响，调整shuffle参数规避。

sparkshufflefilebuffer=64k，

sparkreducermaxSizeInFlight=96M

sparknetworktimeout=300s

sparkrpcaskTimeout=300s

sparkshuffleioserverThreads=8

2不排除网络问题的影响，试图调整os参数，但是客户生产

netipv4tcp_keepalive_time= 15

netipv4tcp_keepalive_probes = 10

netipv4tcp_keepalive_intvl= 30

3关闭sasl

sparkauthenticateenableSaslEncryption=false

sparkauthenticate=false

话说不需要吧，spark不是提供java的api吗，直接在web后台引入spark的包然后调用api就能提交东西吧 如果东西多本地放不下，在hdfs上的话，也可以调用得到的，没必要非得打成包。我说的不是本地模式，是吧本地也看成是一个节点，虽然没干过，不过本地压力应该不小。

以上就是关于Spark On Yarn的两种模式yarn-cluster和yarn-client深度剖析全部的内容，包括:Spark On Yarn的两种模式yarn-cluster和yarn-client深度剖析、Spark-shell和Spark-submit提交程序的区别、【2019-01-04】Spark 程序在driver卡住等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！