APACHE HADOOP YARN – 概念和应用_apache yarn container-CSDN博客

APACHE HADOOP YARN – 概念和应用

如前面所描述的, YARN 实质上是管理分布式app的系统。他由一个中心ResourceManager来管理集群所有的可用资源，每个节点有一个 NodeManager, 直接从ResourceManager来负责管理单节点的可用资源。

Resource Manager

在YARN里, the ResourceManager 是一个主要的纯粹的scheduler。从本质上讲，它严格限制系统中可用资源的竞争。他通过能力保证，公平和SLA原则优化了集群利用率（保证所有资源在任何时间都在被使用）。为了允许有不同的策略来执行，ResourceManager有一个插件化的调度器，允许不同的策略算法实现，比如能力，公平调度等。

ApplicationMaster

许多人认为并行在YARN和已有的Hadoop MapReduce系统（Apache Hadoop 1.x里的MR1）。然后，最关键的不同之处在于一个新的概念 ApplicationMaster。

实际上ApplicationMaster是一个特殊的库框架，负责同ResourceManager协商资源，同NodeManager一起执行和监控containers和资源消耗。他负责从ResourceManager那协商获取适当资源的containers，跟踪状态，监控进度。

ApplicationMaster 使 YARN 表现出以下几个特性：

可扩展：Scale: ApplicationMaster提供给传统的ResourceManager很多功能，使整个系统拥有了更好的可扩展性。在测试中，我们已经成功模拟了10，000个节点的由最新硬件组成的集群，并没有出现什么重大问题。这也是为什么我们选择设计ResourceManager为一个纯粹的调度器，即他并不试图提供资源容错的原因。我们转移这些职责给ApplicationMaster的每个实例。更进一步，既然每个app有一个ApplicationMaster实例，ApplicationMaster本身就不会成为集群的瓶颈。
开放：移动所有的app层面框架代码到ApplicationMaster，使我们能够支持多框架，比如MPI和图计算。

下面有一些非常好的YARN设计的关键点：

把所有的复杂性（尽可能的）交给ApplicationMaster，同时提供足够的功能以允许applicaiton-framework的开发者有足够的灵活性和权利。
既然他实际上是用户端代码，所以不必信任ApplicationMasters，即任何ApplicationMaster都不是一个特权服务。
YARN 系统 (ResourceManager 和 NodeManager) 不得不保护他们自己免受错误的或者恶意的ApplicationMasters的影响，他有所有的资源授权。

记住这点是重要的，每个application有它自己的ApplicationMaster实例。然而，ApplicationMaster管理一组applications也是完全可行的（比如Pig或者Hive的ApplicationMaster就管理一系列的MapReduce作业）。此外，这个概念一件延伸到管理长期运行的服务来管理自己的applications（比如通过一个虚拟的的HBaseAppMaster在YARN里启动HBase）。

Resource Model

YARN 给applications提供了一个非常通用的资源模型。一个application（通过ApplicationMaster）可以请求的资源包括如下：

Resource-name (hostname, rackname – 我们正在处理，将来支持更复杂的网络环境拓扑 YARN-18).
Memory (in MB)
CPU (cores, for now)
将来, 我们会添加更多的资源类型比如磁盘/网络I/O，GPU等。

ResourceRequest and Container

YARN 设计为允许独立的applications(通过ApplicationMaster)可以安全的共享的以多用户的形式利用集群资源。同时，他也可以检测集群拓扑为了更有效的调度和优化数据访问，即减少applications的数据移动。

为了实现这些目标，中央调度器（在ResourceManager里）获取了广泛的application的资源需求信息，这样使他能够给集群里所有的applications做出更好的调度决定。这就带给我们了 ResourceRequest 和 Container.

本质上，一个application可以通过ApplicationMaster请求到足够的资源来满足他的资源需求。调度器通过授权一个container响应一个资源请求，满足ApplicationMaster初始化ResourceRequest的请求。

看一下 ResourceRequest – 有如下形式：

<resource-name, priority, resource-requirement, number-of-containers>

来看下ResourceRequest的每个组件，以更好的理解他们。

resource-name 是 hostname, rackname 或者 * 表示没有特别要求。将来我们会支持更复杂的拓扑，比如单机上的多虚拟机，更复杂的网络等。
priority 是application内的请求优先级（强调一下，并不会跨多applications）。
resource-requirement 是性能请求，比如内存，cpu等（目前YARN只支持内存和cpu）。
number-of-containers 是需求这种container的数量。

现在，来看看Container。

本质上讲，Container是ResourceManager授权ResourceRequest成功后的资源分配结果。一个Container给一个application权利使用定量的资源（内存，cpu等）在一个特定的hosts上。

ApplicationMaster使用Container来分配资源，并把它给NodeManager用来管理host，使用资源启动任务。当然，Container分配是可验证的，并在安全模式，确保ApplicationMasters不能在集群中欺骗分配。

Container 启动时的规范

Container正如上述，仅仅是用特定量的资源在一个集群里指定的机器上（NodeManager），ApplicationMaster可以提供给NodeManager更多信息用来启动container。

YARN 允许applications启动任何进程，并不想现在的Hadoop MapReduce（MR1），他不限于Java applications。

YARN Container 的API是平台无关的，包括：

container内命令行启动进程。
环境变量。
预先连接必要的本地资源，比如jars，共享对象，辅助文件等。
安全相关的tokens。

这允许ApplicationMaster和NodeManager一起启动container，范围从简单的shell脚本到 C/Java/Python 进程在Unix/Windows到全面的虚拟机（比如KVMs）。

YARN – 演练

有了上述概念，将对描述applications如何在YARN工作很有帮助。

Application 执行有以下几个步骤构成：

Application 提交。
加载application的ApplicationMaster实例。
ApplicationMaster实例管理Application执行。

让我们来看看一个application执行的步骤（步骤如图所示）：

一个客户端程序提交application，包括必要的信息来启动一个application级别的ApplicationMaster。
ResourceManager承担协商特定container，用来启动ApplicationMaster，然后启动ApplicationMaster。
ApplicationMaster启动后，注册在ResourceManager上 – 之后允许客户端程序查询ResourceManager获得更多细节，允许他直接和他自己的ApplicationMaster进行通信。
在一般操作中ApplicationMaster通过resource-request协议协商适当资源的container。
在container成功分配后，ApplicationMaster通过提供给NodeManager启动参数启动container。启动参数里包括必要信息以允许container和ApplicationMaster通信。
application代码在container内执行，通过一个application-specific协议提供必要的信息（进度，状态等）给他的ApplicationMaster。
在application执行期间，提交任务的客户端通过applicaton-specific协议直接和ApplicaitonMaster通信，获取状态，进度更新等。
一旦application完成，所有必要的工作完成后，ApplicationMaster解开和ResourceManager的注册，关闭，允许他自己的container被重用。