Hadoop MRv2/纱线特性

我正试图了解新API的实际用途，通过互联网阅读，我发现对于我正在处理的相同问题，有不同的答案

我想知道答案的问题是：

1）哪个MRv2/Thread守护进程负责启动应用程序容器和监视应用程序资源使用情况。

2）MRv2/纱线设计用于解决哪两个问题？

我将通过指定我搜索的资源和实际数据，努力使这篇文章对其他读者具有教育意义和建设性，因此我希望我不会提供太多信息，而我可以提问并缩短我的文章

对于第一个问题，阅读文档，我可以找到3个主要的资源：

来自Hadoop文档：

ApplicationMasterNodeManager启动容器。沟通 通过使用NMClientAsync对象处理容器事件来管理节点 通过NmclientSync.CallbackHandler

ApplicationMaster与纱线集群通信，并处理 应用程序执行。它以异步方式执行操作 时尚在应用程序启动期间 应用程序管理员包括：

a） 与资源经理沟通协商和分配资源 用于未来容器的资源，以及

b） 货柜分配后,， 与节点管理器（NMs）通信以启动应用程序容器 在他们身上

来自Hortonworks文档

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

来自Cloudera文档：

MRv2守护进程-

ResourceManager–每个群集一个– 启动应用程序管理员，在从属节点上分配资源

ApplicationMaster–每个作业一个- 请求资源、管理单个映射并减少任务

NodeManager–每个从属节点一个– 管理各个从属节点上的资源

JobHistory–每个集群一个- 归档作业的度量和元数据

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

是节点管理员吗？是应用程序管理员吗

据我所知，应用程序管理员是让节点管理员真正完成工作的人，所以这就像问谁负责从地面上抬起一个盒子，是那些控制身体并让他们抬起的手真正抬起了心灵

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

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

来自Cloudera文档：

MapReduce v2（“MRv2”）—— 建立在纱线之上（又是“另一个资源谈判者”）

–使用ResourceManager/NodeManager体系结构

– 提高集群的可扩展性

–节点资源可用于任何类型的任务

– 提高群集利用率

–对非MR工作的支持

回到问题上来（MRv2/Thread旨在解决哪两个问题？），我知道MRv2做了一些更改，比如防止JobTracker受到资源压力（在MRv1中，集群中的最大节点数可能在4000个左右，而在MRv2中，它是这个数目的2倍以上），我还知道它提供了运行MapReduce以外的框架的能力，比如MPI

从文件：

应用程序主控程序提供了 传统的ResourceManager使整个系统可以扩展 更引人注目的是，在测试中，我们已经成功地模拟了 由现代硬件组成的10000个节点群集，没有显著的 问题

以及：

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

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

在Hadoop 2.0.0之前，NameNode是单点故障 （SPOF）在HDFS集群中。每个集群都有一个名称节点，如果 该计算机或进程变得不可用，集群作为一个整体 将不可用，直到重新启动或删除NameNode 在单独的机器上长大

因此，如果您必须从3个问题中选择2个，那么哪一个是MRv2/纱线设计要解决的两个问题

-求职者面临的资源压力

-能够运行MapReduce以外的框架，如MPI

-NameNode中的单点故障

提前谢谢你！ D

哪个MRv2/s守护进程负责启动应用程序容器和监视应用程序资源使用情况

ResourceManager（RM）负责为特定作业启动ApplicationMaster（AM），一旦启动了AM，AM将负责协商、分配和监视作业资源（容器）

我建议您阅读Ch6中的MapReduce作业剖析，以深入解释如何在MR1和MR2中分配作业资源

MRv2/纱线的设计是哪两个问题