Spark On Yarn 资源申请流程
-
Client 模式
- 因为是Client模式，所以当我们 Spark-Submit 提交Spark任务的时候，
会直接走到我们的main方法，进行Spark Context 的初始化,
那么客户端也扮演着 Driver 角色 - Spark Context 初始化的时候会生成两个比较重要的对象
DAGSchedule和TaskSchedule,
TaskSchedule会进行任务资源的申请，因为我们这里是用 Yarn 作为资源调度器，
所以TaskSchedule会向 ResourceManager(RM) 进行资源申请。 - 接下来就是 Yarn 的资源调度了
- Yarn 首先会启动一个 ApplicationMaster(AM) 来管理本次申请，
所以 Yarn 的第一步是选一台空闲的 NodeManager 启动 AM - AM 启动后，会根据我们提交任务时申请的资源向 RM 进行资源申请用来启动 Container，
当然这里用来处理的是Spark任务，实际上启动的是 Excutor. - 当我们的Excutor 启动之后，他们会向Driver 端的 TaskSchedule 进行注册。
- 这个时候我们的 Spark Context 的初始化基本完成。接下来就是根据我们的代码，
生产Task 进行任务调度了。
如果不还是不太清楚各个角色的用途，可以参考下图
资源调度.png - 因为是Client模式，所以当我们 Spark-Submit 提交Spark任务的时候，
到这里我们也基本讲明白了 Yarn-Client 模式的资源申请了，
但是说的比较浅，没有涉及到很多细节，
说来也比较惭愧，Spark 的 Standalone 模式源码倒是看过，
但是到目前为止，都没有深入研究过Yarn的源码，
尽管工作中基本都是用的 Yarn 作为资源管理~~~
所以也只能点到即止了，如果后续有时间，可能会进行补充。
-
Cluster 模式
看明白了Client模式，Cluster 模式就比较简单了。
申请资源的流程基本都差不多，
区别就在于Driver程序所在的位置。- 因为是Cluster模式，所以当我们 Spark-Submit 提交Spark任务的时候，
首先是直接去向 RM 申请启动Driver的资源 - Yarn 还是会首先选一台空闲的 NodeManager 来启动 AM管理本次申请，
不过在AM启动的时候，AM也会对Spark Context 进行初始化，
所以在 Cluster 模式下，AM 还扮演着另外一个角色，那就是 Driver。 - Driver启动之后，那就是开始申请 Excutor的资源了，所以AM 就开始向RM申请资源了，
接下来的就和 Client 模式基本一致，没什么好说的
- 因为是Cluster模式，所以当我们 Spark-Submit 提交Spark任务的时候，
- Cluster 和 Client 的对比
-
Client 模式因为 Driver 是在提交的机器上面启动的，
而我们也知道，Driver 在 Spark 任务运行中是承当着 任务调度 和 任务监控的 任务的。
也就是说 Spark 在运行过程中的所有信息都会向Driver 端进行汇报，
这也就造成了：- 当在Client 端提交的任务过多，会导致 Client 这台机器的负载变大，
主要还是网卡容易成为瓶颈，一旦出现这种问题，就会导致Driver 超时，
而Driver超时会使得任务直接就失败。所以生产环境是不建议这么玩的。 - 同样因为Driver的存在，其监控Spark 任务的全过程，
其绝大部分日志信息都会向Driver汇总，很方便我们进行调试。
所以如果你的程序还在测试阶段，那么果断用 Client模式吧，会方便很多。
- 当在Client 端提交的任务过多，会导致 Client 这台机器的负载变大，
Client 模式 因为是Driver 的宿主，所以整个任务过程 Client的不能关闭的，
但是Cluster模式不一样，当任务提交后，
其实Client在不在已经不影响任务的正常运行了。
