Yarn 的基础设施层与原始 map reduce 架构的不同之处如下:
在 YARN 中，作业跟踪器分为两个不同的守护进程，分别称为 Resource Manager 和 Node Manager(特定于节点)。资源管理器只管理资源分配给不同的作业，除了包含一个调度程序，它只负责调度作业而不用担心任何监控或状态更新。不同的资源，如内存、CPU 时间、网络带宽等，被放入一个称为 Resource Container 的单元中。不同的 AppMasters 运行在不同的节点上，它们与这些资源容器中的许多对话，并相应地使用监控/状态详细信息更新节点管理器。
我想知道使用这种方法如何从 map-reduce 的角度提高性能？此外，如果有关于 Yarn 背后的动机及其相对于现有 Map-reduce 实现的优势的任何明确内容，请指出相同的内容。
最佳答案
这里有一些关于 YARN 的文章(1、2、3)。这些讨论了使用 YARN 的好处。
YARN 比 MR 更通用，应该可以运行其他计算模型，如 BSP除了先生。在 YARN 之前，它需要一个单独的集群用于 MR、BSP 和其他。现在它们可以共存于一个集群中，从而提高了集群的使用率。 Here是移植到 YARN 的一些应用程序。
从 MapReduce 的角度来看，在传统 MR 中，Map 和 Reduce 任务有单独的槽，但在 YARN 中，它们不是容器的固定用途。同一容器可用于 Map 任务、Reduce 任务、Hama BSP 任务或其他任务。这样可以提高利用率。
此外，它还可以在同一集群中运行不同版本的 Hadoop，这在传统 MR 中是不可能的，这使得维护起来很容易。
Here是 YARN 的一些附加链接。另外，Hadoop: The Definitive Guide, 3rd Edition有一整节专门介绍 YARN。
仅供引用，有点controversial开发 YARN 而不是使用一些框架，这些框架一直在做类似的事情，并且已经成功运行了很长时间，并消除了错误。
关于hadoop - Yarn 给现有的 map reduce 带来了什么额外的好处？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12992743/