Spark On Yarn 资源申请流程
-
Client 模式
- 因为是Client模式,所以当我们 Spark-Submit 提交Spark任务的时候,
会直接走到我们的main
方法,进行Spark Context 的初始化。 - 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 进行任务调度了。
如果不还是不太清楚各个角色的用途,可以参考下图
- 因为是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在不在已经不影响任务的正常运行了。