Spark-troubleshooting-yarn-client模式导致的网卡流量激增问题

troubleshooting yarn-client模式导致的网卡流量激增问题

大公司都是通过Yarn来进行调度，mapreduce on yarn、spark on yarn、甚至storm on yarn

Yarn集群分成两种节点：

ResourceManager负责资源的调度

NodeManager负责资源的分配、应用程序执行这些东西

通过Spark-submit脚本来提交，用yarn-client提交模式，这种模式其实会在本地启动起来driver程序

Driver到底是什么？

我们写的spark程序，打成jar包，用spark-submit来提交。jar包中的一个main类，

通过jvm的命令启动起来。

JVM进程，这个进程，其实就是咱们的Driver进程。

Driver进程启动起来以后，执行我们自己写的main函数，从new SparkContext()。。。

1，在客户端给我们启动一个driver

2，去ResourceManager申请启动container

3，通知一个NodeManager在container里面启动ApplicationMaster

4，ApplicationMaster去找ResourceManager申请Executor

5，ResourceManager返回可以启动的NodeManager的地址

6，ApplicationMaster去找NodeManager启动Executor

7，Executor进程会反过来去向Driver注册上去

8，最后Driver接收到了Executor资源之后就可以去进行我们spark代码的执行了

9，执行到某个action就触发一个JOB

10，DAGScheduler会划分JOB为一个个Stage

11，TaskScheduler会划分Stage为一个个Task

12，Task发送到Executor执行

13，Driver就来进行Task的调度

Application-Master？？？

yarn中的核心概念，任何要在yarn上启动的作业类型（mr、spark），都必须有一个。

每种计算框架（mr、spark），如果想要在yarn上执行自己的计算应用，那么就必须自己实现和

提供一个ApplicationMaster

相当于是实现了yarn提供的接口，spark自己开发的一个类

spark在yarn-client模式下，application的注册（executor的申请）和计算task的调度，是分离开来的。

standalone模式下，这两个操作都是driver负责的。

ApplicationMaster(ExecutorLauncher)负责executor的申请；driver负责job和stage的划分，

以及task的创建、分配和调度

yarn-client模式下，会产生什么样的问题呢？

由于咱们的driver是启动在本地机器的，而且driver是全权负责所有的任务的调度的，

也就是说要跟yarn集群上运行的多个executor进行频繁的通信（中间有task的启动消息、

task的执行统计消息、task的运行状态、shuffle的输出结果）。

咱们来想象一下。比如你的executor有100个，stage有10个，task有1000个。每个stage运行的时候，

都有1000个task提交到executor上面去运行，平均每个executor有10个task。接下来问题来了，

driver要频繁地跟executor上运行的1000个task进行通信。通信消息特别多，通信的频率特别高。

运行完一个stage，接着运行下一个stage，又是频繁的通信。

在整个spark运行的生命周期内，都会频繁的去进行通信和调度。所有这一切通信和调度都是从你的

本地机器上发出去的，和接收到的。这是最要人命的地方。你的本地机器，很可能在30分钟内

（spark作业运行的周期内），进行频繁大量的网络通信。那么此时，你的本地机器的网络通信负载

是非常非常高的。会导致你的本地机器的网卡流量会激增！！！

你的本地机器的网卡流量激增，当然不是一件好事了。因为在一些大的公司里面，对每台机器的使用情况，

都是有监控的。不会允许单个机器出现耗费大量网络带宽等等这种资源的情况。运维人员不会允许。

可能对公司的网络，或者其他（你的机器还是一台虚拟机），如果你是一台虚拟机的话，和其他机器

共享网卡的话，可能对其他机器，公司整个网络环境，都会有负面和恶劣的影响。

解决的方法：

实际上解决的方法很简单，就是心里要清楚，yarn-client模式是什么情况下，可以使用的？

yarn-client模式，通常咱们就只会使用在测试环境中，你写好了某个spark作业，打了一个jar包，

在某台测试机器上，用yarn-client模式去提交一下。因为测试的行为是偶尔为之的，

不会长时间连续提交大量的spark作业去测试。还有一点好处，yarn-client模式提交，

可以在本地机器观察到详细全面的log。通过查看log，可以去解决线上报错的故障（troubleshooting）、

对性能进行观察并进行性能调优。

实际上线了以后，在生产环境中，都得用yarn-cluster模式，去提交你的spark作业。

yarn-cluster模式，就跟你的本地机器引起的网卡流量激增的问题，就没有关系了。也就是说，

就算有问题，也应该是yarn运维团队和基础运维团队之间的事情了。

他们去考虑Yarn集群里面每台机器是虚拟机还是物理机呢？网卡流量激增后会不会对其他东西产生影响呢？

如果网络流量激增，要不要给Yarn集群增加一些网络带宽等等这些东西。那就是他们俩个团队的事情了，

和你就没有关系了

使用了yarn-cluster模式以后，

就不是你的本地机器运行Driver，进行task调度了。是yarn集群中，某个节点会运行driver进程，

负责task调度。