Yarn为现有地图带来的额外好处减少了多少？

Question

Yarn的基础设施层与原始地图缩减架构的区别在于以下方式：

在YARN中，作业跟踪器被拆分为两个不同的守护进程，称为Resource Manager和Node Manager（特定于节点）。除了包括仅处理调度作业的调度程序而不担心任何监视或状态更新之外，资源管理器仅管理对不同作业的资源分配。内存，CPU时间，网络带宽等不同资源被放入一个称为Resource Container的单元中。在不同节点上运行的是不同的AppMasters，它们与许多这些资源容器进行通信，并相应地使用监视/状态详细信息更新节点管理器。

我想知道使用这种方法如何从map-reduce角度提高性能？此外，如果纱线背后的动机及其对现有Map-reduce实施的好处有任何明确的内容，请指出我的相同内容。

Answer 1

以下是有关YARN的一些文章（1，2，3）。这些讨论了使用YARN的好处。

YARN比MR更通用，除了MR之外，应该可以运行其他计算模型，如BSP。在YARN之前，它需要为MR，BSP和其他人提供单独的集群。现在，他们可以在一个集群中共存，从而提高集群的使用率。 Here是移植到YARN的一些应用程序。

从传统MR中的MapReduce角度来看，Map和Reduce任务有单独的插槽，但在YARN中，它们不是容器的固定用途。同一个容器可用于Map任务，Reduce任务，Hama BSP Task或其他东西。这样可以更好地利用。

此外，它可以在同一个集群中运行不同版本的Hadoop，这是传统MR无法实现的，从维护点来看很容易。

Here是YARN的一些额外链接。此外，Hadoop: The Definitive Guide, 3rd Edition还有专门针对YARN的整个部分。

仅供参考，开发YARN有点controversial而不是使用一些类似的框架，并且已经成功运行了多年的错误。

Answer 2

我认为Yarn不会加速现有的MR框架。展望架构，我们可以看到系统现在更加模块化 - 但模块化通常与更高的性能相矛盾。
可以说YARN与MapReduce无关。 MapReduce刚刚成为YARN应用程序之一。你可以看到它是从一些嵌入式程序转移到嵌入式操作系统中的程序 同时，Yarn为具有不同框架的不同 MR实现打开了大门。例如，如果我们假设我们的数据集小于集群内存，那么我们可以获得更好的性能。我认为http://www.spark-project.org/就是这样一个例子 总结一下：Yarn不会改进现有的MR，但会使其他MR实现在各个方面都更好。

Answer 3

以上所有答案都涵盖了大量信息：我正在简化以下所有信息：

MapReduce:                          YARN:

1. It is Platform plus Application  It is a Platform in Hadoop 2.0 and 
in Hadoop 1. 0 and it is only of    doesn't exist in Hadoop 1.0
the applications in Hadoop 2.0

2. It is single use system i.e.,    It is multi purpose system, We can run
We can run MapReduce jobs only.     MapReduce, Spark, Tez, Flink, BSP, MPP,
                                    MPI, Giraph etc... (General Purpose)

3. JobTracker scalability i.e.,     Both Resource Management and
Both Resource Management and        Application Management gets separated & 
Job Management                      managed by RM+NM, Paradigm specific AMs
                                    respectively.

4. Poor Resource Management         Flexible Resource Management i.e., 
system i.e., slots (map/reduce)     containers.

5. It is not highly available       High availability and reliability.

6. Scaled out up to 5000 nodes      Scaled out 10000 plus nodes.

7. Job->tasks                        Application -> DAG of Jobs -> tasks

8. Classical MapReduce = MapReduce  Yarn MapReduce = MapReduce API +      
   API + MapReduce FrameWork        MapReduce FrameWork + YARN System
   + MapReduce System               So MR programs which were written over
                                    Hadoop 1.0 run over Yarn also with out
                                    changing a single line of code i.e.,
                                    backward compatibility.

Answer 4

让我们看看Hadoop 1.0的缺点，Hadoop 2.0已经通过添加Yarn来解决这个问题。

1. 可伸缩性问题：即使您在Hadoop集群中有数千个节点，Job Tracker也可以在一台计算机上运行。工作跟踪器的职责：资源管理，工作和任务计划和监控。由于所有这些进程都在单个节点上运行，因此该模型不可扩展。
2. 可用性问题（单点故障）：作业跟踪器是单点故障。
3. 资源利用率：由于预定义的Map＆amp;减少任务槽，资源使用不当。当所有Mapper节点都忙时，Reducer节点处于空闲状态，不能用于处理Mapper任务。
4. 与Map Reduce框架紧密集成：Hadoop 1.x只能运行Map reduce作业。不存在对Map Reduce作业以外的作业的支持。

现在，在Hadoop 2.x中使用YARN架构删除了单个Job Tracker瓶颈

YARN 的基本思想是将资源管理和作业调度/监控的功能分解为单独的守护进程。我们的想法是拥有一个全局 ResourceManager（RM）和每个应用程序 ApplicationMaster（AM）。应用程序可以是单个作业，也可以是作业DAG。

ResourceManager 有两个主要组件：计划程序和 ApplicationsManager 。

调度程序负责根据熟悉的容量，队列等约束将资源分配给各种正在运行的应用程序。调度程序是不执行监视的意义上的纯调度程序或跟踪应用程序的状态。

ApplicationsManager 负责接受作业提交，协商第一个容器以执行特定应用程序ApplicationMaster and provides the service for restarting the ApplicationMaster container on failure.

每个应用程序ApplicationMaster 负责从调度程序协商适当的资源容器，跟踪其状态并监控进度。

现在 YARN的优势

1. 可伸缩性问题已得到解决
2. 没有单点故障。所有组件都是高度可用的
3. 资源利用率已得到改善，并正确使用了Map并减少了广告位。
4. 非地图减少工作可以提交

Answer 5

看起来这个链接可能就是您要找的内容：http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/。

我的理解是，YARN应该更通用。您可以创建自己的YARN应用程序，直接与资源管理器协商资源（1），而MapReduce只是已存在的几个应用程序管理器之一（2）。