有关Hadoop中的资源分配和高可用性的全部信息

> YARN Architecture

架构与工作

YARN或"另一个资源谈判者"的名称恰好如其名，它为运行工作进行资源协商。

与其他任何Hadoop应用程序一样，YARN遵循"主从"架构，其中资源管理器是主服务器，节点管理器是从服务器。 主站向从站分配作业和资源，并监视整个周期。 从站接收作业，并请求（其他）资源以完成作业，并实际执行作业。

· 客户端将作业（大多数情况下为jar文件）发送到资源管理器（RM）。

· RM包含两部分，即调度程序和应用程序管理器（AM）。 调度程序接收作业请求，并请求AM搜索可用的节点管理器（NM）。 选定的NM产生应用程序主控（App Master）。 请注意，RM Scheduler仅计划作业。 它无法监视或重新启动失败的作业。 AM监视作业的端到端生命周期，如果NM发生故障，则AM可以重新分配资源。 它还可以重新启动App Master中失败的作业。

· App Master会检查容器中为作业提供的资源。 现在，该作业驻留在App Master中。 请注意，它会将作业状态传达给AM。

· 重要的是要注意，仅当App Master提供了容器启动上下文（CLC）证书时，才能使用Yarn容器。 它就像一把钥匙，可以用来解锁容器的资源。 这是YARN内部的。 现在，将在容器中执行App Master作业。 但是，如果提供的资源不足，则

· App Master会创建请求列表，并

· 此列表直接发送到RM Scheduler（而不是通过NM）。 RM再次请求AM提供更多资源。

· 通过不带App Master的新NM启动新容器。 作业成功执行，资源被释放。

RM是一个主流程，这是一个单点故障，因此让我们在GCP上的Cloudera Manager设置中为YARN的Resource Manager添加高可用性。

YARN调度程序

> Different types of YARN Schedulers

FIFO调度

顾名思义，先进先出或FIFO是YARN中提供的最基本的调度方法。 当前（最有可能）在Hadoop 3.x中已终止，FIFO将客户端提交的作业放入队列中，并以先到先得的顺序顺序执行。

> FIFO Scheduling

作业1、2和3具有不同的存储和内存要求。 尽管我们可以一起运行多个作业，但是在FIFO中，它们将顺序运行。 这就是浪费。 因此，这种调度方法在生产/共享群集上不是首选，因为它遭受资源利用率低的困扰。

由于FIFO是按顺序工作的，因此存在大量的资源未充分利用。 现实生活中的一个缺点是，由于客户端/用户不必等待，因此由于顺序排队，因此违反了关键客户端SLA。 这导致在组织内创建私有集群，其中每个部门都与中央系统（数据湖）断开连接以避免等待。 这进一步降低了利用率，并显着增加了运营成本，而这些成本本可以节省下来。

引入了容量调度程序以最大程度地利用利用率。

容量调度

> Capacity Scheduling

中心思想是，由多个部门资助中央集群或"根"，如上图所示，表示为可用资源的100％。 保证每个部门或"叶子"有特定的能力范围，可在需要时随时执行任务。 这可以是百分比或绝对数字。 这是层次结构中的第二行，其中，根据整个群集中可用的可用资源，保证了最小值，并限制和分配了最大值。 因此，在每个层次级别上，最小范围始终等于100％。 自然，每个叶子的最大值也不能超过100％。 此外，我们始终将每片叶子的最大值限制在100％以下。 80％似乎是生产中的首选最大选择。

通过在层次结构中创建新的子级别，我们可以隔离叶以更准确地划分资源。 这样可以进行详细的容量规划，例如，上图中的" ETL"可获得60％的根，即所有资源的36％作为保证的最小值。 同样在此级别，最小总和为100％。 最后，如果有2个" ETL"作业，则优先级基于FIFO。 优先功能（视情况而定）是容量调度的一个缺点。

公平调度

您需要了解公平和容量调度的工作原理，因为公平调度是基于其缺点而建立的。

如果运行单个作业，则公平调度（FS）会将所有资源投入其中。 如果添加了另一个作业，它将确保添加"相当"数量的资源来完成该作业。 因此，这里解决了FIFO调度问题。 基本上，它可以防止新工作耗尽资源。

FS也可以进行容量调度（如果已配置），它将自动在叶子/部门级别添加资源。 此外，它可以根据"权重"或可以在叶级或作业级别添加的优先级对作业进行优先级排序，从而实现最大的容量利用率。

中心思想是确保所有作业都能随着时间的推移获得"相当数量"的资源以成功执行。 当有两个工作并且其中一个很小时，尤其如此。 小型工作还获得足够的资源来执行，而不是搁置直到大型工作完成为止，即使它属于同一叶子/队列/部门。 可以将其视为动态资源平衡。

最后，您也许还应该在HDFS上启用高可用性：

Zookeeper

动物园管理员是在动物园管理动物的人。 您可能已经注意到，大多数Hadoop应用程序图标都以某种方式与动物相关。 无论如何，Apache Zookeeper同样是在"动物园"（读取Hadoop生态系统）中管理"动物"（读取应用程序）的应用程序。

那么，它的真正作用是什么？

协调

任何大规模分布式应用程序的痛点之一就是规模上的协调。 例如，如果您有100个节点并希望在所有节点上实施配置更改，则必须在所有节点上手动进行配置。您能想象在100个节点上编写配置更改吗？ 可以吗 是？

怎么样呢？Yahoo在某个时候有40,000个Hadoop节点。 您能想象为所有人编写配置更改吗？ 你会做吗？

您可能正在考虑编写一段在所有节点上部署配置更改的代码。 尽管这是一个好主意，但仍有很多顾虑可以解决，例如乏味且频繁的更新/针对每一个小的更改对脚本进行自定义等，我们不会赘述，但是请确保您理解了这一点。 。

这是Zookeeper出现的地方，其中更改/更新可以轻松地应用于所有节点，而不会产生任何开销。 它是无缝的，必须在主节点上完成一次，然后才能在所有节点上自动应用。

Zookeeper的主要用途不是协调。 它保持着高可用性。

维持高可用性

> Apache Zookeeper Basic Architecture

它通过一个简单的反馈循环来实现。 Zookeeper通过其故障转移控制器监视领导者和关注者/备用节点。

它接收每个节点的当前运行状况/状态的心跳或即时通知。 领导失效后，Zookeeper几乎立即将其中一个备用节点选为新领导。 选举完成，新领导者将消息发送到基础应用程序，该应用程序"报告"给新领导者。

这使我结束了Apache YARN和Zookeeper的学习。

有问题吗？ 别问了！

参考文献：

[1] Apache Hadoop YARN（2019），Apache Hadoop，ASF

[2]项目描述-Apache Zookeeper，Apache Hadoop，ASF

(本文翻译自Prathamesh Nimkar的文章《Apache YARN & Zookeeper》，参考：)