解读 spark on yarn

 / 为什么需要 Yarn？ / 

Yarn 的全称是 Yet Anther Resource Negotiator（另一种资源协商者）。它作为 Hadoop 的一个组件，官方对它的定义是一个工作调度和集群资源管理的框架。

Yarn 最早出现于 Hadoop 0.23 分支中，0.23 分支是一个实验性分支，之后经过了几次迭代，最后发布于 2014 年 6 月的 0.23.11 版本(该分支的最后一个版本)。在 0.23.0 发布后不久的 2011 年 12 月，Hadoop 的 0.20 分支发展成了 Hadoop1.0，一直到 1.0 的最后一个版本 1.2.1-stable 都没有出现 Yarn 的身影，而在 Hadoop2.0 的第一个版本 2.0.0-alpha，Yarn 已经作为一个正式组件加入。在 2.0.2-alpha 版本，它已经支持了 2k 台机器的集群，接着在 2.0.3-alpha 版本中已经可以支持 30k 台机器的集群。在 2.0.3-alpha 版本中同时还支持了多种资源，如 cpu&memory 的调度和 ResourceManager restart。

 

图 1，via https://blog.csdn.net/suifeng3051/article/details/49364677

如图 1 所示， Hadoop1.0 的运作流程如下：

1.客户端提交任务给集群；

2.JobTracker 接收 Job 请求；

3.JobTracker 根据 Job 的输入参数向 NameNode 请求包含这些文件数据块的 DataNode 节点列表；

4.JobTracker 确定 Job 的执行计划：确认 Map、Reduce 的 Task 数量，并分配 Task 到离数据块最近的节点上执行。

最初，Hadoop1.0 能够很好地支撑大数据计算，但是随着计算规模的扩大和计算模型的多样化，它逐渐力不从心。众所周知当集群性能不足的时候可以简单粗暴地加机器，但 JobTracker 同时部署多个时只有一个是处于 active 状态，因此受限于这个 active JobTracker 的负载上限，整个集群能够容纳的机器也有限，有数据显示整个集群的管理上限约为 4k 台机器。同时应用程序相关和资源管理相关的逻辑全部放在 JobTracker中，当集群规模扩大的时候，会存在一个瓶颈。除此之外，Map-Reduce 计算模型与 JobTracker 的耦合过高，其他计算模型难以在 Hadoop1.0 上运行。

Yarn 是 Hadoop 基于这些问题的一个解决方案，接下来通过了解 Yarn 的组件、架构以及运作机制来分析 Yarn 是如何解决这些问题的。

 

 / Yarn 是什么？ / 

Yarn 的组件&基本架构

如图 2 所示 Yarn 采用 Master/Slave 结构，整体采用双层调度架构。在第一层的调度是 ResourceManager 和 NodeManager：ResourceManager 是 Master 节点，相当于 JobTracker，包含 Scheduler 和App Manager 两个组件࿰