共计 2542 个字符，预计需要花费 7 分钟才能阅读完成。
本篇内容介绍了“Spark on yarn 执行流程是怎样的”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
很多公司都是通过 Yarn 来进行调度，mapreduce on yarn、spark on yarn、甚至 storm on yarn。
Yarn 集群分成两种节点：
ResourceManager 负责资源的调度；
NodeManager 负责资源的分配、应用程序执行这些东西。
通过 Spark-submit 脚本来提交，用 yarn-client 提交模式，这种模式其实会在本地启动起来 driver 程序
Spark on yarn 执行流程
我们写的 spark 程序，打成 jar 包，用 spark-submit 来提交。jar 包中的一个 main 类，通过 jvm 的命令启动起来。JVM 进程，这个进程，其实就是咱们的 Driver 进程。Driver 进程启动起来以后，执行我们自己写的 main 函数，从 new SparkContext()。。。
在客户端给我们启动一个 driver
去 ResourceManager 申请启动 container(资源)
通知一个 NodeManager 在 container 里面启动 ApplicationMaster
ApplicationMaster 去找 ResourceManager 申请 Executor
ResourceManager 返回可以启动的 NodeManager 的地址
ApplicationMaster 去找 NodeManager 启动 Executor
Executor 进程会反过来去向 Driver 注册上去
最后 Driver 接收到了 Executor 资源之后就可以去进行我们 spark 代码的执行了
执行到某个 action 就触发一个 JOB
DAGScheduler 会划分 JOB 为一个个 Stage
TaskScheduler 会划分 Stage 为一个个 Task
Task 发送到 Executor 执行
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 调度。
“Spark on yarn 执行流程是怎样的”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
