问MRv2 /纱线特征

EN

我试图对新API的实际用途深信不疑，在互联网上，我发现了我所处理的相同问题的不同答案。

我想知道的问题是：

1)在MRv2 2/纱线守护进程中，哪个是负责启动应用程序容器和监视应用程序资源使用情况的.

2) MRv2 2/纱线设计要解决的两个问题是什么？

我将通过指定我的搜索中的资源和实际数据来使这个线程对其他读者具有教育意义和建设性，所以我希望它不会看起来像我提供了太多的信息，而我只需要问问题和缩短我的文章。

关于第一个问题，即阅读文档，我可以找到3种主要的资源可依赖：

来自Hadoop文档：

ApplicationMaster<->NodeManager启动容器。使用NodeManagers对象与NMClientAsync通信，通过NMClientAsync.CallbackHandler处理容器事件 ApplicationMaster与纱线集群通信，并处理应用程序执行。它以异步方式执行操作。在应用程序启动期间，ApplicationMaster的主要任务是： ( a)与ResourceManager通信，为未来的容器协商和分配资源，以及 ( b)集装箱分配后，通信纱线NodeManagers (NMs)在其上启动应用程序容器。

来自Hortonworks文档

实际上，ApplicationMaster是特定于框架的库的一个实例，它负责协商来自ResourceManager的资源，并与NodeManager一起执行和监视容器及其资源消耗。它有责任从ResourceManager谈判合适的资源容器，跟踪它们的状态并监测进展情况。

来自Cloudera文件：

MRv2守护进程- ResourceManager -每个集群- Starts ApplicationMasters分配资源在从节点上。 ApplicationMaster -每个作业- Requests资源一个，管理单个地图和减少任务 NodeManager -每个从节点在单个从节点上的- Manages资源为一个 JobHistory -每个集群- Archives作业的度量和元数据一个

回到问题(哪个守护进程负责启动应用程序容器和监视应用程序资源使用情况)，我问自己：

是NodeManager？吗？是ApplicationMaster吗？

据我所知，ApplicationMaster是那个让NodeManager真正完成任务的人，所以这就像问谁负责从地上举起一个盒子，是不是那些实际举起心灵的手控制着身体，让他们去做……

这是一个棘手的问题，我想，但必须只有一个答案。

关于第二个问题，即在线阅读，我可以从许多资源中找到不同的答案，从而产生困惑，但我的主要来源是：

来自Cloudera文件：

MapReduce v2 (“MRv2”)纱线上的- Built(又称“另一资源NegoGator”) -使用ResourceManager/NodeManager架构 集群的- Increases可伸缩性 -节点资源可用于任何类型的任务 - Improves集群利用 -对非乔布斯的支持

回到这个问题( MRv2 2/YARN设计要解决的两个问题？)，我知道MRv2做了一些更改，比如防止JobTracker上的资源压力(在MRv1中，集群中的最大节点数可能是4000个，而在MRv2中，这个数目是这个数目的2倍多)，而且我还知道它提供了运行除MapReduce以外的框架的能力，比如MPI。

来自文件：

Application提供了传统ResourceManager的许多功能，以便整个系统能够更显着地扩展。在测试中，我们已经成功地模拟了10,000个由现代硬件组成的节点集群，没有明显的问题。

以及：

将所有特定于应用程序框架的代码迁移到ApplicationMaster中可以概括系统，以便我们现在可以支持多个框架，如MapReduce、MPI和图形处理。

但我也认为它处理的是NameNode是一个单一故障点的事实，在新版本中，通过高可用性模式提供了备用NameNode (我可能会混淆旧API和新API的特性，以及MRv1与MRv2的特性，这可能是我提出问题的原因)：

在Hadoop2.0.0之前，NameNode是HDFS集群中的单个故障点(SPOF)。每个集群都有一个NameNode，如果该机器或进程不可用，则整个集群将不可用，直到NameNode重新启动或在单独的机器上启动为止。

所以，如果你必须选择其中的2个，那么MRv2 2/ serve设计的两个问题将是哪一个呢？

-Resource对JobTracker的压力

-Ability来运行MapReduce以外的其他框架，如MPI。

-Single故障点在NameNode中。

提前谢谢你！D