Apache Hadoop YARN_的 apache hadoop yarn 资源管理器允许未认证用户创建和执行应用程序-CSDN博客

本文链接：https://blog.csdn.net/mr_hhh/article/details/81133169

Apache Hadoop YARN - 概念和应用程序

本系列的其他文章：
Apache Hadoop简介YARN
Apache Hadoop YARN - 背景和概述
 Apache Hadoop YARN - 概念和应用程序
 Apache Hadoop YARN - ResourceManager
Apache Hadoop YARN - NodeManager

APACHE HADOOP YARN - 概念与应用

如先前描述的，Yarn实质上是用于管理分布式应用的系统。它由一个仲裁所有可用群集资源的中央ResourceManager和一个每个节点的NodeManager组成，它从ResourceManager获取资源，负责管理单个节点上可用的资源。

资源管理

在YARN中，ResourceManager有两个主要组件：Scheduler和ApplicationsManager。从本质上讲，它严格限制在竞争应用程序之间仲裁系统中的可用资源。它针对各种约束（例如容量保证，公平性和SLA）优化集群利用率（始终保持所有资源使用）。为了允许不同的策略约束，ResourceManager具有可插拔 调度程序，允许根据需要使用不同的算法，如容量和公平调度。

ApplicationMaster

许多人将在YARN和现有的Hadoop MapReduce系统（Apache Hadoop 1.x中的MR1）之间取得平行。但是，关键的区别是新概念的的ApplicationMaster。

ApplicationMaster实际上是一个特定于框架的库的实例，负责协商来自ResourceManager的资源，并与NodeManager一起执行和监视容器及其资源消耗。它负责从ResourceManager协商适当的资源容器，跟踪其状态并监控进度。

ApplicationMaster允许YARN展示以下关键特征：

Scale：Application Master提供了传统ResourceManager的大部分功能，因此整个系统可以更加大规模地扩展。在测试中，我们已经成功地模拟了由现代硬件组成的10,000个节点集群而没有重大问题。这是我们选择将ResourceManager设计为纯调度程序的主要原因之一，即它不会尝试为资源提供容错。我们将其转变为ApplicationMaster实例的主要职责。此外，由于每个应用程序都有一个ApplicationMaster实例，因此ApplicationMaster本身不是群集中的常见瓶颈。
Open：将所有特定于应用程序框架的代码移动到ApplicationMaster中，对系统进行了概括，以便我们现在可以支持多个框架，如MapReduce，MPI和Graph Processing。

插入一些关键的YARN设计决策是一个很好的观点：

将所有复杂性（尽可能）移至ApplicationMaster，同时提供足够的功能以允许应用程序框架作者具有足够的灵活性和功能。
由于它本质上是用户代码，因此不要信任ApplicationMaster，即任何ApplicationMaster都不是特权服务。
YARN系统（ResourceManager和NodeManager）必须不惜一切代价保护自己免受错误或恶意的ApplicationMaster和资源的影响。

记住，实际上，每个应用程序都有自己的ApplicationMaster实例，这很有用。但是，实现ApplicationMaster来管理一组应用程序（例如，ApplicationMaster for Pig或Hive来管理一组MapReduce作业）是完全可行的。此外，这个概念已被扩展到管理长期运行的服务，这些服务管理自己的应用程序（例如，通过假设的HBaseAppMaster在YARN中启动HBase）。

资源模型

YARN支持应用程序的非常通用的资源模型。应用程序（通过ApplicationMaster）可以请求具有高度特定要求的资源，例如：

资源名称（主机名，机架名称 - 我们正在进一步概括这一点，以支持使用YARN-18的更复杂的网络拓扑）。
内存（以MB为单位）
CPU（核心，现在）
将来，我们希望能够添加更多资源类型，例如磁盘/网络I / O，GPU等。

ResourceRequest和Container

YARN旨在允许各个应用程序（通过ApplicationMaster）以共享，安全和多租户方式利用群集资源。此外，它仍然了解群集拓扑，以便有效地调度和优化数据访问，即尽可能减少应用程序的数据运动。

为了实现这些目标，中央调度程序（在ResourceManager中）具有有关应用程序资源需求的大量信息，这使其能够跨集群中的所有应用程序做出更好的调度决策。这将我们引向ResourceRequest和生成的Container。

本质上，应用程序可以通过ApplicationMaster 请求特定的资源请求，以满足其资源需求。Scheduler通过授予容器来响应资源请求，该容器满足ApplicationMaster在初始ResourceRequest中规定的要求。

让我们看一下ResourceRequest - 它有以下形式：

<resource-name，priority，resource-requirement，container-of-container>

让我们来看看ResourceRequest的每个组件，以便更好地理解它。

resource-name是hostname，rackname或*表示没有首选项。将来，我们希望在主机，更复杂的网络等上支持更复杂的虚拟机拓扑。
优先级是此请求的应用程序内优先级（强调，这不是跨多个应用程序）。
资源需求是必需的功能，如内存，CPU等。（在编写时，YARN仅支持内存和CPU）。
容器数量只是这种容器的倍数。

现在，进入Container。

本质上，Container是资源分配，这是ResourceManager授予特定ResourceRequest 的成功结果。Container授予应用程序在特定主机上使用特定数量资源（内存，CPU等）的权限。

ApplicationMaster必须获取Container并将其呈现给NodeManager，管理分配容器的主机，以使用资源启动其任务。当然，在安全模式下验证Container分配，以确保ApplicationMaster 不能伪造集群中的分配。

集装箱发射期间的集装箱规

虽然如上所述，Container仅仅是在群集中的特定机器（NodeManager）上使用指定数量的资源的权利，但ApplicationMaster必须向NodeManager提供更多信息以实际启动容器。

YARN允许应用程序启动任何进程，与hadoop-1.x（又名MR1）中的现有Hadoop MapReduce不同，它不仅限于Java应用程序。

YARN Container启动规范API与平台无关，包含：

命令行在容器内启动进程。
环境变量。
启动前机器上所需的本地资源，如jar，共享对象，辅助数据文件等。
与安全相关的tokens。

这允许ApplicationMaster与NodeManager一起启动容器，范围从简单的shell脚本到Unix / Windows上的C / Java / Python进程，再到成熟的虚拟机（例如KVM）。

YARN - Walkthrough

有了上述概念的知识，概述应用程序在YARN中的概念性工作方式将非常有用。

应用程序执行包括以下步骤：

申请提交。
引导应用程序的ApplicationMaster实例。
由ApplicationMaster实例管理的应用程序执行。

让我们来看看应用程序执行顺序（步骤如图所示）：

客户端程序提交应用程序，包括启动特定于应用程序的ApplicationMaster本身的必要规范。
ResourceManager承担协商指定容器的责任，在该容器中启动ApplicationMaster。
该ApplicationMaster，在启动时，向ResourceManager注册，允许客户端程序来查询ResourceManager的详细信息，这允许它可以直接与自己的ApplicationMaster通信。
在正常操作期间，ApplicationMaster通过资源请求协议协商适当的资源容器。
在成功的容器分配中，ApplicationMaster通过向NodeManager提供容器启动规范来启动容器。通常，启动规范包括允许容器与ApplicationMaster本身通信的必要信息。
然后，在容器内执行的应用程序代码通过特定于应用程序的协议向其ApplicationMaster提供必要的信息（进度，状态等）。
在应用程序执行期间，提交程序的客户端直接与ApplicationMaster通信，以通过特定于应用程序的协议获取状态，进度更新等。
一旦应用程序完成，并且所有必要的工作都已完成，ApplicationMaster将使用ResourceManager取消注册并关闭，从而允许自己的容器重新调整用途。