NodeManager 管理一个 YARN 集群中的每个节点。NodeManager 提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1 通过插槽管理 Map 和 Reduce 任务的执行，而 NodeManager 管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。YARN 继续使用 HDFS 层。它的主要 NameNode 用于元数据服务，而 DataNode 用于分散在一个集群中的复制存储服务。
要使用一个 YARN 集群，首先需要来自包含一个应用程序的客户的请求。ResourceManager 协商一个容器的必要资源，启动一个 ApplicationMaster 来表示已提交的应用程序。通过使用一个资源请求协议，ApplicationMaster 协商每个节点上供应用程序使用的资源容器。执行应用程序时，ApplicationMaster 监视容器直到完成。当应用程序完成时，ApplicationMaster 从 ResourceManager 注销其容器，执行周期就完成了。
通过这些讨论，应该明确的一点是，旧的 Hadoop 架构受到了 JobTracker 的高度约束，JobTracker 负责整个集群的资源管理和作业调度。新的 YARN 架构打破了这种模型，允许一个新 ResourceManager 管理跨应用程序的资源使用，ApplicationMaster 负责管理作业的执行。这一更改消除了一处瓶颈，还改善了将 Hadoop 集群扩展到比以前大得多的配置的能力。此外，不同于传统的 MapReduce，YARN 允许使用 Message Passing Interface 等标准通信模式，同时执行各种不同的编程模型，包括图形处理、迭代式处理、机器学习和一般集群计算。
您需要知道的事
随着 YARN 的出现，您不再受到更简单的 MapReduce 开发模式约束，而是可以创建更复杂的分布式应用程序。实际上，您可以将 MapReduce 模型视为 YARN 架构可运行的一些应用程序中的其中一个，只是为自定义开发公开了基础框架的更多功能。这种能力非常强大，因为 YARN 的使用模型几乎没有限制，不再需要与一个集群上可能存在的其他更复杂的分布式应用程序框架相隔离，就像 MRv1 一样。甚至可以说，随着 YARN 变得更加健全，它有能力取代其他一些分布式处理框架，从而完全消除了专用于其他框架的资源开销，同时还简化了整个系统。
为了演示 YARN 相对于 MRv1 的效率提升，可考虑蛮力测试旧版本的 LAN Manager Hash 的并行问题，这是旧版 Windows® 用于密码散列运算的典型方法。在此场景中，MapReduce 方法没有多大意义，因为 Mapping/Reducing 阶段涉及到太多开销。相反，更合理的方法是抽象化作业分配，以便每个容器拥有密码搜索空间的一部分，在其之上进行枚举，并通知您是否找到了正确的密码。这里的重点是，密码将通过一个函数来动态确定（这确实有点棘手），而不需要将所有可能性映射到一个数据结构中，这就使得 MapReduce 风格显得不必要且不实用。
归结而言，MRv1 框架下的问题仅是需要一个关联数组，而且这些问题有专门朝大数据操作方向演变的倾向。但是，问题一定不会永远仅局限于此范式中，因为您现在可以更为简单地将它们抽象化，编写自定义客户端、应用程序主程序，以及符合任何您想要的设计的应用程序。