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

转至： >

错误的说法是：Spark运行的基本流程是先初始化程序，然后将数据加载到内存中，最后用户可以使用任何算法对数据进行处理。

Spark的基本流程并不是如此简单，它的流程包括：创建Spark上下文，加载数据集，转换数据，使用算法进行分析，将结果输出，最后释放资源。

首先，在Spark程序中，需要考虑创建一个Spark上下文，它是一个运行Spark程序的基本环境，它能够提供Spark程序所需要的一切资源，包括集群管理器、资源管理器、Scheduler等。

其次，需要加载要处理的数据集，这些数据可以从本地文件系统或者远程的HDFS文件系统中获取，并将其加载到Spark中。

接着，将加载的数据转换成可以被Spark处理的数据，这里可以使用Spark的RDD API或者DataFrame API进行数据转换，将数据转换成可以被Spark处理的形式。

然后，可以使用Spark MLlib中提供的各种机器学习算法进行数据分析，计算出分析结果，并将结果输出到指定的文件中。

最后，在程序完成后，需要释放资源，将Spark上下文中加载的数据及各种资源占用情况清空，以便在下次运行时能够重新使用。

因此，以上错误的说法不能概括Spark的基本流程，Spark的基本流程涉及到更多的步骤，如上所述。

发现在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 On Yarn的两种模式yarn-cluster和yarn-client深度剖析全部的内容，包括:Spark On Yarn的两种模式yarn-cluster和yarn-client深度剖析、Linux里面spark作用是什么、针对spark运行的基本流程哪个说法是错误的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！