Spark系列——Spark On Yarn 资源申请流程

Spark On Yarn 资源申请流程

• Client 模式

  1. 因为是Client模式，所以当我们 Spark-Submit 提交Spark任务的时候，
     会直接走到我们的main方法，进行Spark Context 的初始化,
     那么客户端也扮演着 Driver 角色
  2. Spark Context 初始化的时候会生成两个比较重要的对象DAGSchedule 和 TaskSchedule,
     TaskSchedule 会进行任务资源的申请，因为我们这里是用 Yarn 作为资源调度器，
     所以 TaskSchedule 会向 ResourceManager(RM) 进行资源申请。
  3. 接下来就是 Yarn 的资源调度了
  4. Yarn 首先会启动一个 ApplicationMaster(AM) 来管理本次申请，
     所以 Yarn 的第一步是选一台空闲的 NodeManager 启动 AM
  5. AM 启动后，会根据我们提交任务时申请的资源向 RM 进行资源申请用来启动 Container，
     当然这里用来处理的是Spark任务，实际上启动的是 Excutor.
  6. 当我们的Excutor 启动之后，他们会向Driver 端的 TaskSchedule 进行注册。
  7. 这个时候我们的 Spark Context 的初始化基本完成。接下来就是根据我们的代码，
     生产Task 进行任务调度了。

  如果不还是不太清楚各个角色的用途，可以参考下图

  资源调度.png

到这里我们也基本讲明白了 Yarn-Client 模式的资源申请了，
但是说的比较浅，没有涉及到很多细节，
说来也比较惭愧，Spark 的 Standalone 模式源码倒是看过，
但是到目前为止，都没有深入研究过Yarn的源码，
尽管工作中基本都是用的 Yarn 作为资源管理~~~
所以也只能点到即止了，如果后续有时间，可能会进行补充。

• Cluster 模式
  看明白了Client模式，Cluster 模式就比较简单了。
  申请资源的流程基本都差不多，
  区别就在于Driver程序所在的位置。

  1. 因为是Cluster模式，所以当我们 Spark-Submit 提交Spark任务的时候，
     首先是直接去向 RM 申请启动Driver的资源
  2. Yarn 还是会首先选一台空闲的 NodeManager 来启动 AM管理本次申请，
     不过在AM启动的时候，AM也会对Spark Context 进行初始化，
     所以在 Cluster 模式下，AM 还扮演着另外一个角色，那就是 Driver。
  3. Driver启动之后，那就是开始申请 Excutor的资源了，所以AM 就开始向RM申请资源了，
     接下来的就和 Client 模式基本一致，没什么好说的

• Cluster 和 Client 的对比

1. Client 模式因为 Driver 是在提交的机器上面启动的，
   而我们也知道，Driver 在 Spark 任务运行中是承当着 任务调度 和 任务监控的 任务的。
   也就是说 Spark 在运行过程中的所有信息都会向Driver 端进行汇报，
   这也就造成了：

   • 当在Client 端提交的任务过多，会导致 Client 这台机器的负载变大，
     主要还是网卡容易成为瓶颈，一旦出现这种问题，就会导致Driver 超时，
     而Driver超时会使得任务直接就失败。所以生产环境是不建议这么玩的。
   • 同样因为Driver的存在，其监控Spark 任务的全过程，
     其绝大部分日志信息都会向Driver汇总，很方便我们进行调试。
     所以如果你的程序还在测试阶段，那么果断用 Client模式吧，会方便很多。

2. Client 模式 因为是Driver 的宿主，所以整个任务过程 Client的不能关闭的，
   但是Cluster模式不一样，当任务提交后，
   其实Client在不在已经不影响任务的正常运行了。