大数据最佳实践-yarn

最新推荐文章于 2024-01-18 20:35:47 发布

猿与禅

最新推荐文章于 2024-01-18 20:35:47 发布

阅读量617

点赞数

分类专栏：大数据文章标签： hadoop yarn 调优最佳实践

原文链接：https://docs.cloudera.com/documentation/enterprise/5-9-x/topics/cm_mc_resource_pools.html

版权

大数据专栏收录该内容

93 篇文章 1 订阅

订阅专栏

概述

YARN群集由主机组成。主机提供内存和CPU资源。甲VCORE或虚拟核心，是主机CPU的使用份额。YARN ResourceManager分配内存和vcore以尽可能最有效的方式使用所有可用资源。理想情况下，很少或没有资源处于空闲状态。一个应用程序是由一个或多个任务YARN客户端程序。通常，任务使用容器中的所有可用资源。任务的消耗不能超过其指定的分配，从而确保它不能使用所有主机CPU周期或超过其内存分配。通过配置容器以使用开销和其他服务所需资源以外的所有可用资源，调整YARN主机以优化vcore和内存的使用。
YARN调整分为三个阶段。这些阶段对应于YARN调整电子表格中的选项卡。
群集配置，您可以在其中配置主机。
YARN配置，您可以在其中量化内存和vcore。
MapReduce配置，您可以在其中为特定地图分配最小和最大资源，并减少任务。
YARN和MapReduce具有许多可配置的属性。有关完整列表，请参阅《Cloudera Manager配置属性》。YARN调整电子表格列出了这些属性的基本子集，这些子集最有可能提高常见MapReduce应用程序的性能。

在“群集配置”选项卡中，为YARN实施定义工作程序主机配置和群集大小。

与任何系统一样，可用的内存和CPU资源越多，群集处理大量数据的速度就越快。一台具有4个具有超线程功能的CPU的计算机，每个CPU具有6个内核，每个主机提供48个vcore。

两单元服务器安装中的3 TB硬盘驱动器在JBOD（仅磁盘捆绑）配置中具有12个可用插槽，在创建电子表格时，性能和价格之间是合理的平衡。存储成本会随着时间的推移而降低，因此您可以考虑使用4 TB磁盘。较大的磁盘很昂贵，并且并非所有用例都需要。

在发布电子表格时，两个1 Gb以太网端口提供了足够的吞吐量，但是10 Gb以太网端口是一个选择，其中价格与速度无关紧要。

至少从8 GB（对于您的操作系统）和1 GB（对于Cloudera Manager）开始。如果CDH之外的服务需要其他资源，请在“其他服务”下添加这些号码。

HDFS DataNode至少使用1个内核和大约1 GB的内存。相同的要求适用于YARN NodeManager。

电子表格列出了一些可选服务：
Impala守护程序至少需要16 GB的守护程序。
HBase区域服务器需要12-16 GB的内存。
Solr服务器至少需要1 GB的内存。
Kudu Tablet服务器至少需要1 GB的内存。
其余所有资源均可用于YARN应用程序（Spark和MapReduce）。

在此示例中，有44个CPU内核可用。为每个物理核心上想要的vcore设置乘数，以计算总可用vcore。

在为集群中的每个主机定义了规范之后，输入支持您的业务案例所需的辅助主机数量。要查看并行计算的好处，请将主机数量设置为最少10个。

验证可用资源并为每个容器设置最小和最大限制。
步骤4向前拉出步骤2中的内存和vcore编号。步骤5显示了群集的总内存和vcore。
在步骤6中，您可以更改影响容器大小的值。

vcore的最小数量应为1。当需要其他vcore时，一次加1将导致最有效的分配。将vcore保留的最大数量设置为节点的大小。

设置最小和最大保留空间。增量应该是可以影响性能的最小量。在这里，最小值约为1 GB，最大值约为8 GB，增量为512 MB。
您可以根据输入的数量来验证集群中容器的最小和最大数量。

您可以增加ApplicationMaster的内存分配，映射任务，并减少任务。任何任务的最小vcore分配始终为1。溢出/排序内存分配400应该足够，如果您确定频繁溢出到磁盘会损害工作性能，则应该（很少）增加该值。

在CDH 5.5及更高版本中，常见的MapReduce参数 mapreduce.map.java.opts， mapreduce.reduce.java.opts，和 yarn.app.mapreduce.am.command-opts会根据“堆与容器大小之比”自动为您配置。
，您可以一目了然地验证所有最小和最大资源分配都在您设置的参数之内。
yarn.nodemanager.resource.cpu-vcores 容器虚拟CPU内核
yarn.nodemanager.resource.memory-mb 容器内存
yarn.scheduler.minimum-allocation-vcores 容器虚拟CPU内核最低要求
yarn.scheduler.maximum-allocation-vcores 容器虚拟CPU核心数上限
yarn.scheduler.increment-allocation-vcores 容器虚拟CPU内核增量
yarn线调度器最小分配MB 容器内存最小
yarn.scheduler.maximum-allocation-mb 容器内存最大
yarn线计划程序增量分配mb 容器内存增量
yarn.app.mapreduce.am.resource.cpu-vcores ApplicationMaster虚拟CPU内核
yarn.app.mapreduce.am.resource.mb 应用程序主存储器
mapreduce.map.cpu.vcores Map Task CPU虚拟核心
mapreduce.map.memory.mb 地图任务记忆
mapreduce.reduce.cpu.vcores 减少任务CPU虚拟核心
mapreduce.reduce.memory.mb 减少任务记忆
mapreduce.task.io.sort.mb I / O排序存储器

yarn预热

在开始新会话之后提交第一个查询时，您可能会遇到稍长的延迟，然后才能看到查询开始。您可能还会注意到，如果再次运行相同的查询，它的完成速度将比第一个查询快得多。

Spark执行者需要额外的时间来启动和初始化YARN群集上的Spark，这会导致更长的延迟。另外，Spark在开始作业之前不会等待所有执行者准备就绪，因此在将作业提交到集群后，某些执行者可能仍在启动。但是，对于在Spark上运行的作业，提交作业时可用执行程序的数量部分决定了减速器的数量。当准备好的执行程序的数量未达到最大时，作业可能不会具有最大的并行度。这可能会进一步影响第一份工作的性能。

在寿命长的用户会话中，这多余的时间不会造成任何问题，因为它仅在第一次查询执行时发生。但是，短暂的会话（例如Oozie发起的Hive职位）可能无法达到最佳性能。

为了减少启动时间，可以在作业开始之前启用容器预热。仅当请求的执行程序准备就绪时，作业才开始运行。这样，在减少方面不会减少短暂的会话并行性。
hive.prewarm.enabled=true
hive.prewarm.numcontainers=10

要预热的执行程序的实际数量由以下两者之一的值限制 spark.executor.instances （静态分配）或 spark.dynamicAllocation.maxExecutors（动态分配）
hive.prewarm.numcontainers 不得超过分配给用户会话的数量

预热需要几秒钟，对于短暂的会话来说是一个好习惯，特别是在查询涉及reduce 阶段的情况下。但是，如果hive.prewarm.numcontainers高于群集中的可用容量，该过程最多需要30秒。谨慎使用预热

静态分配

在这里插入图片描述

可以通过单个静态服务池向导配置使用cgroups静态分配资源。您将服务分配为总资源的百分比，然后向导将配置cgroup。
例如，下图说明了HBase，HDFS，Impala和YARN服务的静态池，它们分别分配了20％，30％，20％和30％的群集资源。

动态资源池

是一种资源命名的配置和yarn线的应用，并在池中运行Impala的查询之间调度资源的政策。动态资源池使您可以根据用户对特定池的访问权限以及这些池可用的资源来调度资源并将其分配给YARN应用程序和Impala查询。如果未使用池的分配，则可以抢占该分配并将其分配给其他池。否则，池将根据池的权重接收一部分资源。访问控制列表（ACL）限制了谁可以将工作提交到动态资源池并进行管理。

甲配置集定义跨越池，可以在给定时间是活动的资源的分配。例如，您可以定义“ daytime”和“ off hour”配置集，您可以在白天和一周的剩余时间内为它们指定不同的资源分配。

甲调度规则当定义配置集是有效的。根据计划的要求，配置集中的配置将传播到公平的计划程序分配文件。更新的文件存储在YARN ResourceManager配置目录中/ var / run / cloudera-scm-agent / process / nn -yarn-RESOURCEMANAGER在运行ResourceManager角色的主机上。请参阅服务器和客户端配置。

如果强制使用静态服务池（cgroup），则可用于共享的资源取决于为每个服务进行的分配。例如，如果YARN的静态池为群集资源总数的75％，则资源池将仅使用75％的资源。

创建或编辑动态资源池设置后，将显示“ 刷新动态资源池”和“ 放弃更改”按钮。单击刷新动态资源池以将设置传播到公平调度程序分配文件（默认情况下，fair-scheduler.xml）。更新的文件存储在YARN ResourceManager配置目录中/ var / run / cloudera-scm-agent / process / nn -yarn-RESOURCEMANAGER在运行ResourceManager角色的主机上。请参阅服务器和客户端配置。

有关确定如何使用分配的资源的信息，请参阅《集群利用率报告》。

泳池层级
YARN资源池可以嵌套，其子池受其父池的设置限制。这使您可以指定一组池，这些池的资源受父资源限制。每个子池可以有其自己的资源限制。如果这些限制在父池的配置之内，则子池的限制生效。如果子池的限制超出了父池的限制，则以父池限制为准。

您可以通过配置它作为家长或通过任一创建父池创建子池下池。一旦池成为父池，就无法将作业提交到该池。它们必须提交到子池。

继续阅读：

管理动态资源池
YARN池状态和配置选项
使用配置集定义资源分配
计划配置集
将应用程序和查询分配给资源池
管理动态资源池
在Cloudera Manager中使用动态资源池的主要入口点是“ 集群” >“ 集群名称” >“ 动态资源池配置”菜单项。

继续阅读：

查看动态资源池配置
创建YARN动态资源池
为Impala启用和禁用动态资源池
创建Impala动态资源池
为Impala动态资源池选择设置
克隆资源池
删除资源池
编辑动态资源池
查看动态资源池配置
根据有效的Cloudera Manager资源管理中描述的资源管理方案，动态资源池配置概述显示以下选项卡：
yarn -重量，虚拟核心，最小和最大内存，最大正在运行的应用程序以及计划策略
Impala 准入控制 -最大内存，最大运行查询，最大排队查询，队列超时和默认查询内存限制
要查看动态资源池配置：
选择集群 > 集群名称 > 动态资源池配置。如果群集具有YARN服务，则显示YARN > 资源池选项卡。如果集群为动态资源池启用了Impala服务，则显示“ Impala准入控制” >“ 资源池”选项卡。
点击YARN或Impala入场控制选项卡。
创建YARN动态资源池
始终有一个名为 root.default。默认情况下，所有YARN应用程序都在此池中运行。当工作负载包含具有自己需求的可识别应用程序组（例如来自特定应用程序或组织中的特定组）时，可以创建其他池。
选择集群 > 集群名称 > 动态资源池配置。如果群集具有YARN服务，则显示YARN > 资源池选项卡。如果集群为动态资源池启用了Impala服务，则显示“ Impala准入控制” >“ 资源池”选项卡。
单击“ yarn线”选项卡。
单击创建资源池。显示“创建资源池”对话框，其中显示“配置集”选项卡。
指定池的名称和资源限制：
在“ 资源池名称”字段中，指定一个仅包含字母数字字符的唯一池名称。如果引用包含“。”的用户名或组名，请替换“。” 与“ dot”。
要将池设为父池，请选中“ 父池”复选框。
选择一个配置集。指定一个权重，该权重指示该池相对于其他池的资源份额，虚拟核心和内存的最小和最大值，以及在池中可以同时运行的应用程序数量的限制。
单击“ 调度策略”选项卡，然后选择一个策略：
主导资源公平性（DRF）（默认） -对多个资源公平调度的扩展。DRF根据这些资源的可用性和作业要求来确定CPU和内存资源的份额。
公平（FAIR） -根据内存确定资源份额。
先进先出（FIFO） -根据添加作业的时间确定资源份额。
如果已启用Fair Scheduler抢占，请单击“ 抢占”选项卡并选择设置抢占超时，以指定此池中的作业必须等待多长时间才能抢占其他池中的作业的资源。要启用抢占，请按照启用和禁用公平调度程序抢占中的过程进行操作。
如果已启用ACL和指定的用户或组，则可以选择单击“ 提交”和“ 管理访问控制”选项卡，以指定哪些用户和组可以提交应用程序，哪些用户可以查看全部并杀死应用程序。默认情况下，任何人都可以提交，查看所有应用程序并杀死它们。要限制这些权限，请选择“ 允许这些用户和组”，并分别在“用户”和“组”字段中提供用逗号分隔的用户和组列表。
点击创建。
单击刷新动态资源池。

YARN -YARN管理虚拟核心，内存，正在运行的应用程序，未声明的子代（对于父池）的最大资源以及每个池的调度策略。在上图中，为YARN定义了三个动态资源池（分别为权重3、2和1的Dev，Product和Mktg）。如果启动了一个应用程序并将其分配给产品池，而其他应用程序正在使用Dev和Mktg池，则产品资源池将获得总群集资源的30％x 2/6（或10％）。如果没有应用程序在使用Dev和Mktg池，则YARN产品池将分配30％的群集资源。
Impala -Impala管理正在运行的查询的池的内存，并限制每个池中正在运行的查询和排队查询的数量。

最低要求角色：配置器（也由Cluster Administrator， Full Administrator提供）
一个动态资源池是一种资源命名的配置和yarn线的应用，并在池中运行Impala的查询之间调度资源的政策。动态资源池使您可以根据用户对特定池的访问权限以及这些池可用的资源来调度资源并将其分配给YARN应用程序和Impala查询。如果未使用池的分配，则可以抢占该分配并将其分配给其他池。否则，池将根据池的权重接收资源份额。访问控制列表（ACL）限制了谁可以将工作提交到动态资源池并进行管理。
配置集定义可以在给定时间处于活动状态的池之间的资源分配。例如，您可以定义“ daytime”和“ off hour”配置集，您可以在白天和一周的剩余时间内为它们指定不同的资源分配。
甲调度规则当定义配置集是有效的。根据计划的要求，配置集中的配置会传播到公平的计划程序分配文件中。更新的文件存储在YARN ResourceManager配置目录中/ var / run / cloudera-scm-agent / process / nn -yarn-RESOURCEMANAGER在运行ResourceManager角色的主机上。请参阅服务器和客户端配置。
如果强制使用静态服务池（cgroup），则可用于共享的资源取决于为每个服务进行的分配。例如，如果YARN的静态池为群集资源总数的75％，则资源池将仅使用75％的资源。
创建或编辑动态资源池设置后，将显示“刷新动态资源池”和“放弃更改”按钮。单击刷新动态资源池以将设置传播到公平调度程序分配文件（默认情况下，fair-scheduler.xml）。更新的文件存储在YARN ResourceManager配置目录中/ var / run / cloudera-scm-agent / process / nn -yarn-RESOURCEMANAGER在运行ResourceManager角色的主机上。请参阅服务器和客户端配置。
有关确定如何使用分配的资源的信息，请参阅《集群利用率报告》。
泳池层级
YARN资源池可以嵌套，其子池受其父池的设置限制。这使您可以指定一组池，这些池的资源受父资源限制。每个子池可以有其自己的资源限制。如果这些限制在父池的配置之内，则子池的限制生效。如果子池的限制超出了父池的限制，则以父池限制为准。
您可以通过配置它作为家长或通过任一创建父池创建子池下池。一旦池成为父池，就不能将作业提交到该池。它们必须提交到子池。
继续阅读：
管理动态资源池
YARN池状态和配置选项
定义配置集
计划配置集
将应用程序和查询分配给资源池
管理动态资源池
在Cloudera Manager中使用动态资源池的主要入口点是“集群” >“集群名称” >“动态资源池配置”菜单项。
继续阅读：
查看动态资源池配置
创建YARN动态资源池
在Cloudera Manager中启用或禁用Impala准入控制
创建Impala动态资源池
Impala动态资源池的配置设置
克隆资源池
删除资源池
编辑动态资源池
查看动态资源池配置
根据有效的Cloudera Manager资源管理中描述的资源管理方案，动态资源池配置概述显示以下选项卡：
yarn-重量，虚拟核心，最小和最大内存，最大正在运行的应用程序，未声明子代的最大资源以及计划策略
Impala 准入控制-最大内存，最大运行查询，最大排队查询，队列超时，最小查询内存限制，最大查询内存限制，钳位MEM_LIMIT查询选项和默认查询内存限制
要查看动态资源池配置：
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
点击YARN或Impala入场控制选项卡。
创建YARN动态资源池
始终有一个名为 root.default。默认情况下，所有YARN应用程序都在此池中运行。当工作负载包含具有自己需求的可识别应用程序组（例如来自特定应用程序或组织中的特定组）时，可以创建其他池。
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
单击“yarn线”选项卡。
单击创建资源池。显示“创建资源池”对话框，其中显示“资源限制”选项卡。
指定池的名称和资源限制：
在“资源池名称”字段中，指定仅包含字母数字字符的唯一池名称。如果引用包含“。”的用户名或组名，请替换“。” 与“ dot”。
要将池设为父池，请选中“父池”复选框。
通过将值分配给列出的属性来定义配置集。指定一个权重，该权重指示该池相对于其他池的资源份额，虚拟核心和内存的最小和最大值，以及在该池中可以同时运行的应用程序数量的限制。如果这是父池，则还可以设置未声明子代的最大资源。
单击“调度策略”选项卡，然后选择一个策略：
主导资源公平性（DRF）（默认） -对多个资源的公平调度的扩展。DRF根据这些资源的可用性和作业要求来确定CPU和内存资源的份额。
公平（FAIR） -根据内存确定资源份额。
先进先出（FIFO） -根据添加作业的时间确定资源份额。
如果已启用Fair Scheduler抢占，请单击“抢占”选项卡，并可以选择设置抢占超时，以指定此池中的作业必须等待多长时间才能抢占其他池中的作业的资源。要启用抢占，请按照启用和禁用公平调度程序抢占中的过程进行操作。
如果已启用ACL和指定的用户或组，则可以选择单击“提交”和“管理访问控制”选项卡，以指定哪些用户和组可以提交应用程序，哪些用户可以查看全部并杀死应用程序。默认情况下，任何人都可以提交，查看所有应用程序并终止其应用程序。要限制这些权限，请选择“ 允许这些用户和组”，并分别在“用户”和“组”字段中提供用逗号分隔的用户和组列表。
点击创建。
单击刷新动态资源池。
在Cloudera Manager中启用或禁用Impala准入控制
我们建议在所有生产集群上启用准入控制，以缓解可能的容量问题。容量问题可能是由于大量并发查询，由于需要大量内存的重型联接和聚合查询，或者因为将Impala与其他Hadoop数据管理组件一起使用，并且Impala的资源使用必须是受限于在多租户部署中很好地工作。
重要的：
在CDH 5.8和更高版本中，默认情况下启用准入控制和动态资源池。但是，在您配置动态资源池的设置之前，进入控制功能实际上不会启用，因为默认情况下，每个动态池都将允许在池中执行任何内存需求的所有查询。
转到Impala服务。
在“配置”选项卡中，选择“类别” >“准入控制”。
选择或清除“启用Impala准入控制”复选框和“启用动态资源池” 复选框。
输入更改原因，然后单击“保存更改”以提交更改。
重新启动Impala服务。
完成此任务后，要进行进一步的配置设置，请自定义动态资源池的配置设置，如下所述。
创建Impala动态资源池
始终有一个资源池指定为 root.default。默认情况下，为Impala启用动态资源池功能后，所有Impala查询都将在此池中运行。当您的工作负载包含可查询的组（例如来自特定应用程序或组织中的特定组）时，您会创建其他池，这些查询对并发性，内存使用或服务级别协议（SLA）都有自己的要求。每个池都有其自己的设置，这些设置与内存，查询数量和超时间隔有关。
选择集群>集群名称>动态资源池配置。如果群集具有Impala服务，则“ Impala准入控制”选项卡下将显示“资源池”选项卡。
单击“ Impala准入控制”选项卡。
单击创建资源池。
指定池的名称和资源限制：
在“资源池名称”字段中，键入仅包含字母数字字符的唯一名称。
（可选）单击“提交访问控制”选项卡以指定哪些用户和组可以提交查询。默认情况下，任何人都可以提交查询。要限制此权限，请选择“允许这些用户和组”选项，并分别在“用户”和“组”字段中提供用逗号分隔的用户和组列表。
点击创建。
单击刷新动态资源池。
Impala动态资源池的配置设置
Impala动态资源池支持以下设置。
最大记忆体
整个群集可用于此池中执行的所有查询的最大聚合内存量。这应该是Impala守护程序的已配置总内存的一部分，为方便起见，将在此选项旁边的设置对话框中显示该内存。将此值设置为非零值将启用基于内存的准入控制。
Impala确定池中所有查询使用的预期最大内存，并保留可能导致超出“最大内存”的所有其他查询。
如果指定Max Memory，则应指定要分配给该池中每个查询的内存量。您可以通过两种方式执行此操作：
通过设置最大查询内存限制和最小查询内存限制。在CDH 6.1和更高版本中，这是首选方法，它为Impala带来了灵活性，可以为预期会占用大量内存的查询留出更多内存。
通过将“默认查询内存限制”设置为Impala应为该池中的查询预留的确切内存量。
请注意，如果您未设置上述任何选项，或者未将“默认查询内存限制”设置为0，则Impala将完全依靠内存估计来确定为每个查询留出多少内存。不建议这样做，因为如果估计不正确，这可能会导致查询不运行或内存不足。
例如，请考虑以下情形：
集群正在运行刺穿五台主机上的守护程序。
动态资源池的“最大内存”设置为100 GB。
池的最大查询内存限制为10 GB，最小查询内存限制为2 GB。因此，在该池中运行的任何查询都可能使用多达50 GB的内存（最大查询内存限制* Impala节点数）。
Impala将同时执行不同数量的查询，因为根据估算的内存需求，可能会给查询提供2 GB到10 GB之间的内存限制。例如，Impala最多可以执行10个具有2 GB内存限制的小型查询，或者执行两个具有10 GB内存限制的大型查询，因为在五台主机上执行时，这符合100 GB群集范围的限制。
如果执行中的查询不需要那么多的内存，则它们使用的内存可能会少于每个主机的内存限制或“最大内存”群集范围的限制。通常，只要您能够同时执行足够的查询以满足您的需求，这就不成问题。
最小查询内存限制和最大查询内存限制
这两个选项确定了Impala Admission控件将为此资源池中的查询选择的每主机内存的最小和最大限制。如果设置，则Impala准入控制将根据查询的每个主机内存估计值，在最小值和最大值之间选择一个内存限制。选择的内存限制决定了运行查询的每个主机上，Impala准入控制将为此查询留出的内存量。运行查询的所有主机上的总内存将计入池的“ 最大内存”中。
最小查询内存限制必须小于或等于最大查询内存限制和最大内存。
您可以通过设置 MEM_LIMIT查询选项。如果选择了Clamp MEM_LIMIT查询选项，并且用户进行了设置MEM_LIMIT 的值超出这两个选项所指定的范围，则有效内存限制将为最小值或最大值，具体取决于是否 MEM_LIMIT 低于或高于范围。
默认查询内存限制
没有显式时，应用于在此池中执行的查询的默认内存限制 MEM_LIMIT查询选项已设置。选择的内存限制决定了运行查询的每个主机上，Impala Admission控件将为此查询保留的内存量。运行查询的所有主机上的总内存将计入池的“最大内存”中。
CDH 6.1和更高版本不建议使用此选项，并由“最大查询内存限制”和“最小查询内存限制”代替。如果设置了“最大查询内存限制”或“最小查询内存限制”，则不要设置此字段。
最大运行查询
此池中并发运行的查询的最大数量。对于CDH 5.7或更高版本，默认值是无限的。（可选的）
在该池中可以并发运行的最大查询数。默认值为无限制。该池的所有超出“最大运行查询数”的查询都将添加到准入控制队列中，直到其他查询结束。当您没有关于查询内存使用的大量数据时，可以在资源管理的早期阶段使用“最大运行查询”来确定如果将限制应用于Impala查询，则群集在整体上的性能是否更好。
对于具有许多小查询的工作负载，通常会为此设置指定一个较高的值，或者保留默认设置“ unlimited”。对于具有昂贵查询的工作负载，其中一定数量的并发查询会使集群的内存，I / O，CPU或网络容量饱和，请将值设置得足够低，以使不会为Impala过度使用集群资源。
使用其他池设置启用基于内存的准入控制后，仍然可以使用“最大运行查询”作为保护措施。如果查询超过估计的总内存或并发查询的最大数量，则会将它们添加到队列中。
最大排队查询
可以在此池中排队的最大查询数。对于CDH 5.3或更高版本，默认值为200；对于先前版本的Impala，默认值为50。（可选的）
队列超时
在取消之前，查询在准入控制队列中等待该池的时间（以毫秒为单位）。默认值为60,000毫秒。
在以下情况下，“队列超时”并不重要，可以指定一个较高的值以避免意外取消查询：
在低并发工作负载中，几乎没有查询排队或没有查询排队
在没有严格的SLA的环境中，查询是否偶尔会比平常花费更长的时间无关紧要，因为它们被保留在准入控制中
您可能还需要增加价值，才能将Impala与某些具有自己的查询超时间隔的商业智能工具一起使用。
在高并发工作负载中，尤其是对于具有严格SLA的查询，准入控制中的长时间等待会导致严重的问题。例如，如果查询需要在10秒内运行，并且您已经对其进行了调整，以使其在8秒内运行，那么如果它在准入控制队列中等待的时间超过2秒，则会违反其SLA。在这种情况下，请设置较低的超时值并监视由于超时而取消的查询数。此技术可帮助您及早发现容量，调整和扩展问题，并通过运行已经错过SLA的昂贵查询来避免浪费资源。
如果您确定某些查询可能具有较高的超时值，而另一些查询则可以从较低的超时值中受益，则可以为此设置创建具有不同值的单独的池。
钳位MEM_LIMIT查询选项
如果未选择此字段，则 MEM_LIMIT查询选项将不受为此资源池指定的最大查询内存限制和最小查询内存限制值的限制。默认情况下，在CDH 6.1及更高版本中选择了此字段。如果未同时设置“最小查询内存限制”和“最大查询内存限制”，则该字段将被禁用。
克隆资源池
要创建具有与现有池相同属性的新池，可以克隆一个池：
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
点击YARN或Impala入场控制选项卡。
单击资源池行右侧的，然后选择克隆。
为池指定名称，然后根据需要编辑池属性。
点击创建。
单击刷新动态资源池。
删除资源池
删除池：
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
点击YARN或Impala入场控制选项卡。
单击资源池行右侧的，然后选择删除。
单击确定。
单击刷新动态资源池。
编辑动态资源池
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
点击YARN或Impala入场控制选项卡。
单击资源池行右侧的“编辑”。编辑属性。
如果已启用ACL和指定的用户或组，则可以选择单击“提交”和“管理访问控制”选项卡，以指定哪些用户和组可以提交应用程序，哪些用户可以查看全部并杀死应用程序。默认情况下，任何人都可以提交，查看所有应用程序并终止其应用程序。要限制这些权限，请选择“允许这些用户和组”，并分别在“用户”和“组”字段中提供用逗号分隔的用户和组列表。
点击保存。
单击刷新动态资源池。
YARN池状态和配置选项
继续阅读：
查看动态资源池状态
配置默认的YARN Fair Scheduler属性
创建资源子池
设置YARN用户限制
配置ACL
启用ACL
查看动态资源池状态
请执行以下任一操作：
集群菜单
选择集群>集群名称>动态资源池配置。将显示“ YARN” >“资源池”选项卡。
单击查看动态资源池状态。
yarn服务
转到YARN服务。
单击资源池选项卡。
有关更多信息，请参见监视动态资源池。
配置默认的YARN Fair Scheduler属性
有关默认属性的信息，请参阅“配置Fair Scheduler”。
选择集群>集群名称>动态资源池配置。将显示“ YARN” >“资源池”选项卡。
单击“yarn线”选项卡。
单击默认设置按钮。
指定默认的调度策略，最大应用程序数和抢占超时属性。
点击保存。
单击刷新动态资源池。
创建资源子池
YARN资源池可以形成嵌套的层次结构。手动创建子池：
选择集群>集群名称>动态资源池配置。将显示“ YARN” >“资源池”选项卡。
单击资源池行右侧的，然后选择创建子池。配置子池属性。
点击创建。
单击刷新动态资源池。
设置YARN用户限制
池属性确定可以在池中运行的应用程序的最大数量。要限制特定用户可以同时运行的应用程序数量，请执行以下操作：
选择集群>集群名称>动态资源池配置。将显示“ YARN” >“资源池”选项卡。
单击用户限制选项卡。该表显示用户列表以及每个用户可以提交的最大作业数。
点击添加用户限制。
指定一个用户名。仅包含字母数字字符。如果引用包含“。”的用户名或组名，请替换“。” 与“ dot”。
指定正在运行的应用程序的最大数量。
点击创建。
单击刷新动态资源池。
配置ACL
要配置哪些用户和组可以提交和终止任何资源池中的应用程序，请执行以下操作：
启用ACL。
在Cloudera Manager中，选择YARN服务。
单击配置选项卡。
搜索“管理员ACL”属性，并指定哪些用户和组可以提交和终止应用程序。注意： YARN Resource Manager ACL中的组名区分大小写。因此，如果在ACL中指定了大写的组名，则它将与从Active Directory解析的组名不匹配，因为Active Directory组名是小写的。
输入更改原因，然后单击“保存更改”以提交更改。
通过单击Cloudera Manager徽标返回主页。
单击任何旧服务旁边的图标以调用群集重新启动向导。
单击重新启动旧服务。
单击立即重新启动。
点击完成。
启用ACL
要指定是否检查ACL，请执行以下操作：
在Cloudera Manager中，选择YARN服务。
单击配置选项卡。
搜索启用ResourceManager ACL属性，然后选择YARN服务。
输入更改原因，然后单击“保存更改”以提交更改。
通过单击Cloudera Manager徽标返回主页。
单击任何旧服务旁边的图标以调用群集重新启动向导。
单击重新启动旧服务。
单击立即重新启动。
点击完成。
定义配置集
配置集定义可以在给定时间处于活动状态的池之间的资源分配。例如，您可以定义“ daytime”和“ off hour”配置集，您可以在白天和一周的剩余时间内为它们指定不同的资源分配。
您可以通过创建计划规则来定义配置集活动。定义配置集后，就可以配置限制，例如权重，最小和最大内存以及虚拟核心以及最大运行的应用程序。
指定资源限制属性
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
单击资源池选项卡。
对于每个资源池，点击编辑。
选择配置集名称。
编辑配置集属性，然后单击“保存”。
单击刷新动态资源池。
示例配置集
在白天的配置集分配生产池中的五倍资源开发池：
在这里插入图片描述

“非工作时间”配置集为生产和开发池分配了相等数量的资源：
在这里插入图片描述

请参阅这些配置集的示例调度规则。
查看配置集的属性
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
在“配置集”下拉列表中，选择一个配置集。将显示该配置集的每个池的属性。
计划配置集
甲调度规则当定义配置集是有效的。根据计划的要求，配置集中的配置会传播到公平的计划程序分配文件中。更新的文件存储在YARN ResourceManager配置目录中/ var / run / cloudera-scm-agent / process / nn -yarn-RESOURCEMANAGER在运行ResourceManager角色的主机上。请参阅服务器和客户端配置。
调度规则示例
考虑示例“白天”和“非工作时间”配置集。要指定“白天”配置集在每个工作日的上午8:00至下午5:00处于活动状态，而“下班时间”配置在所有其他时间（晚上和周末）都处于活动状态，请定义以下规则：
在这里插入图片描述

添加计划规则
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
单击“调度规则”选项卡。
单击创建计划规则。
在“配置集”字段中，选择规则适用的配置集。选择“创建新的”或“使用现有的”。
如果创建新的配置集，请在“名称”字段中键入一个名称。
如果使用现有配置集，请从下拉列表中选择一个。

将规则配置为重复或不重复：
要重复该规则，请保持选中“重复”字段并指定重复频率。如果频率是每周一次，请指定重复的天数。
如果规则不重复，请清除“重复”字段，单击“打开”字段的左侧以显示一个下拉日历，您可以在其中设置开始日期和时间。当您指定日期和时间时，在打开字段的右侧会设置两个小时的默认时间窗口。单击右侧以调整日期和时间。
点击创建。
单击刷新动态资源池。
重新排序计划规则
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
单击“调度规则”选项卡。
单击重新排序计划规则。
在规则行中单击上移或下移。
点击保存。
单击刷新动态资源池。
编辑计划规则
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
单击计划规则。
单击规则右侧的“编辑”。
编辑规则。
点击保存。
单击刷新动态资源池。
删除调度规则
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
单击计划规则。
点击规则右侧的，然后选择删除。
单击确定。
单击刷新动态资源池。
将应用程序和查询分配给资源池
您可以在运行时指定应用程序或查询应在命名资源池中运行：
要在运行时为YARN应用程序指定池，请在 mapreduce.job.queuename 财产。
要在运行时为Impala查询指定池，请在 REQUEST_POOL 选项。
Cloudera Manager允许您指定一组有序规则，以将应用程序和查询分配给池。您还可以直接在YARN公平调度程序配置中指定默认池设置。
某些规则允许您指定在动态资源池配置中创建该池（如果尚不存在）。允许创建池是可选的。如果满足规则并且您没有创建池，则YARN在未分配或管理资源的池中运行作业“临时”。
如果在运行应用程序或查询时不满足任何规则，则拒绝YARN应用程序或Impala查询。
展示位置规则的排序和评估
池放置规则按照它们在放置规则列表中出现的顺序进行评估。提交作业后，将评估规则，并使用第一个匹配规则来确定在其中运行作业的池。
如果始终满足规则，则不评估后续规则。永远不会评估的规则以粗线显示为灰色文本。有关示例，请参见示例放置规则。
默认情况下，池放置规则的添加顺序与添加时相反。最后添加的规则显示在最前面。您可以轻松地对规则进行重新排序。
创建池放置规则
放置规则确定将应用程序和查询分配到的池。在安装时，Cloudera Manager提供了一组默认规则和规则顺序。
要创建展示位置规则，请执行以下操作：
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
点击YARN或Impala入场控制选项卡。
点击展示位置规则标签。
点击创建展示位置规则。在“类型”下拉列表中，选择一个规则，该规则指定池的名称及其在池层次结构中的位置：
yarn
在运行时指定-使用根。[池名称]，在哪里池名是在运行时指定的池的名称。
root.users。[用户名] -使用父池超级用户在提交应用程序的用户命名的池中。这超级用户父池和此规则是默认创建的。但是，从Cloudera Manager 5.7升级时，不会添加池或放置规则。
root.default-使用root.default 水池。
root。[池名称] -使用root.pool名称，在哪里池名是您在选择规则后显示的“池名称”字段中指定的名称。
root。[primary group] -使用与提交应用程序的用户的主要组匹配的池。
root。[secondary group] -使用与提交应用程序的用户的次级组之一匹配的池。
root。[用户名] -使用与提交应用程序的用户名匹配的池。
root。[primary group]。[username] -使用与提交了应用程序的用户的主要组匹配的父池，然后使用与用户名匹配的子池。
root。[次要组]。[用户名] -使用与提交应用程序的用户的次要组之一匹配的父池，然后再匹配与用户名匹配的子池。
黑斑羚
在运行时指定-使用REQUEST_POOL查询选项。例如，SET REQUEST_POOL =根。[池名称]。
root。[池名称] -使用root.pool名称，在哪里池名是您在选择规则后显示的“池名称”字段中指定的名称。
root。[用户名] -使用与提交查询的用户名匹配的池。不建议这样做。
root。[primary group] -使用与提交查询的用户的主要组匹配的池。
root。[secondary group] -使用与提交查询的用户的次级组之一匹配的池。
root.default-使用root.default 水池。
注意：当前，无法将用户名映射到具有不同名称的资源池。例如，您无法映射用户1 用户到 root.pool1 资源池。
例如，考虑以下三个Impala用户。

用户名：test1，secondarygroupname：testgroup

用户名：test2，secondarygroupname：testgroup

用户名：test3，secondarygroupname：testgroup

该集群具有2个动态池： root.default 和根测试组
此群集具有3个放置规则，按以下顺序列出。
根。[用户名]
根。[主要组]
根。[第二组]
根据上述放置规则，所有三个用户提交的查询都将映射到根测试组资源池。
有关这些规则的更多信息，请参见 queuePlacementPolicy分配文件格式中的元素。
（仅适用于YARN）要指示在应用程序运行时如果不存在则应创建池，请选中如果不存在则创建池复选框。
点击创建。该规则将添加到放置规则列表的顶部，并成为第一个评估的规则。
单击刷新动态资源池。
默认放置规则和顺序
YARN的默认放置规则和顺序为：
使用运行时指定的池，如果不存在则创建该池。
使用池root.users。[用户名]。
使用池root.default。
另请参阅示例放置规则。
Impala的默认规则和顺序为：
仅在运行时使用运行时指定的池。
使用池root.default。
重新排序池放置规则
要更改评估池放置规则的顺序，请执行以下操作：
选择集群>集群名称>动态资源池配置。如果群集具有YARN服务，则显示YARN >资源池选项卡。如果群集具有如上述的使能服务帕拉启用或禁用帕拉接纳控制中的Cloudera管理器中，帕拉准入控制>资源池选项卡显示。
点击YARN或Impala入场控制选项卡。
点击展示位置规则标签。
点击重新排序放置规则。
在规则行中单击上移或下移。
点击保存。
单击刷新动态资源池。
放置规则示例
下图显示了YARN的默认池放置规则设置：
在这里插入图片描述

如果在运行时指定了池，则该池将用于作业，如果不存在该池，则会创建该池。如果在运行时未指定池，则根据提交作业的用户命名的池超级用户使用父池。如果无法使用该池（例如，因为超级用户池是叶池），池 root.default 用来。
如果将规则2向下移动（它指定要在池中运行该作业，该池以嵌套在父池中的用户运行该作业的用户命名）超级用户），则规则2被禁用，因为前一个规则（使用池 root.default）总是很满意。
在这里插入图片描述

调度策略

一个调度器确定哪些作业的运行，在那里，他们跑的时候，并分配给作业的资源。YARN（MRv2）和MapReduce（MRv1）计算框架支持以下调度程序：

FIFO -基于到达时间分配资源

在这里插入图片描述

先进先出，但不适合资源公平性
FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
从图中可以看出，在FIFO 调度器中，小任务会被大任务阻塞。

上图为FIFO调度器的执行过程示意图。FIFO调度器也就是平时所说的先进先出（First In First Out）调度器。FIFO调度器是Hadoop最早应用的一种调度策略，可以简单的将其理解为一个Java队列，它的含义在于集群中同时只能有一个作业在运行。将所有的Application按照提交时候的顺序来执行，只有当上一个Job执行完成之后后面的Job才会按照队列的顺序依次被执行。FIFO调度器以集群资源独占的方式来运行作业，这样的好处是一个作业可以充分利用所有的集群资源，但是对于运行时间短，重要性高或者交互式查询类的MR作业就要等待排在序列前的作业完成才能被执行，这也就导致了如果有一个非常大的Job在运行，那么后面的作业将会被阻塞。因此，虽然单一的FIFO调度实现简单，但是对于很多实际的场景并不能满足要求。这也就催发了Capacity调度器和Fair调度器的出现。

容量调度程序

在这里插入图片描述

而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
独立的专门队列保证小作业也可以提交后就启动，队列容量是专门保留的
以整个集群的利用率为代价，与FIFO比，大作业执行的时间要长

多个组织共享集群，每个组织配置一个队列，一个队列分配一定的集群资源
同一个队列可以进一步划分，同一个组织不同用户共享队列所分配的资源，使用FIFO调度
队列资源不足时，可以等待其他队列释放的资源或者使用集群中其他空闲资源，这可能会使得实际使用的队列容量超出配置的容量，这叫做“弹性队列”
4)为队列设置一个最大容量限制，可以防止队列过多侵占其他队列资源
capacity-scheduler.xml配置yarn.scheduler.capacity..

上图是Capacity调度器的执行过程示意图。Capacity调度器也就是日常说的容器调度器。可以将它理解成一个个的资源队列。这个资源队列是用户自己去分配的。例如因为工作所需要把整个集群分成了AB两个队列，A队列下面还可以继续分，比如将A队列再分为1和2两个子队列。那么队列的分配就可以参考下面的树形结构：

—A[60%]

|—A.1[40%]

|—A.2[60%]

—B[40%]

上述的树形结构可以理解为A队列占用整个资源的60%，B队列占用整个资源的40%。A队列里面又分了两个子队列，A.1占据40%，A.2占据60%，也就是说此时A.1和A.2分别占用A队列的40%和60%的资源。虽然此时已经具体分配了集群的资源，但是并不是说A提交了任务之后只能使用它被分配到的60%的资源，而B队列的40%的资源就处于空闲。只要是其它队列中的资源处于空闲状态，那么有任务提交的队列可以使用空闲队列所分配到的资源，使用的多少是依据配来决定。参数的配置会在后文中提到。

Capacity调度器具有以下的几个特性：

层次化的队列设计，这种层次化的队列设计保证了子队列可以使用父队列设置的全部资源。这样通过层次化的管理，更容易合理分配和限制资源的使用。

2.容量保证，队列上都会设置一个资源的占比，这样可以保证每个队列都不会占用整个集群的资源。

安全，每个队列又严格的访问控制。用户只能向自己的队列里面提交任务，而且不能修改或者访问其他队列的任务。

4.弹性分配，空闲的资源可以被分配给任何队列。当多个队列出现争用的时候，则会按照比例进行平衡。

5.多租户租用，通过队列的容量限制，多个用户就可以共享同一个集群，同事保证每个队列分配到自己的容量，提高利用率。

6.操作性，Yarn支持动态修改调整容量、权限等的分配，可以在运行时直接修改。还提供给管理员界面，来显示当前的队列状况。管理员可以在运行时，添加一个队列；但是不能删除一个队列。管理员还可以在运行时暂停某个队列，这样可以保证当前的队列在执行过程中，集群不会接收其他的任务。如果一个队列被设置成了stopped，那么就不能向他或者子队列上提交任务了。

7.基于资源的调度，协调不同资源需求的应用程序，比如内存、CPU、磁盘等等。

Fair Scheduler

在这里插入图片描述上图是Fair调度器在一个队列中的执行过程示意图。Fair调度器也就是日常说的公平调度器。Fair调度器是一个队列资源分配方式，在整个时间线上，所有的Job平均的获取资源。默认情况下，Fair调度器只是对内存资源做公平的调度和分配。当集群中只有一个任务在运行时，那么此任务会占用整个集群的资源。当其他的任务提交后，那些释放的资源将会被分配给新的Job，所以每个任务最终都能获取几乎一样多的资源。

在这里插入图片描述
公平调度器也可以在多个队列间工作，如上图所示，例如有两个用户A和B，他们分别拥有一个队列。当A启动一个Job而B没有任务提交时，A会获得全部集群资源；当B启动一个Job后，A的任务会继续运行，不过队列A会慢慢释放它的一些资源，一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个Job并且其它任务也还在运行时，那么它将会和B队列中的的第一个Job共享队列B的资源，也就是队列B的两个Job会分别使用集群四分之一的资源，而队列A的Job仍然会使用集群一半的资源，结果就是集群的资源最终在两个用户之间平等的共享。

DRF（Dominant Resource Fairness）

Max-min fairness算法：如果每一个用户都有足够地请求，会给予每个用户一份均等的资源。尽量不让任何用户被“饿死”。
- DRF：让所有application的“主要资源占比”尽量均等，包括CPU及内存。

公平-将资源分配给加权池，并在每个池内公平共享。在配置池的调度策略时，域资源公平（DRF）是一种公平的调度程序。
在Mesos和YARN中，都用到了dominant resource fairness算法(DRF)，它不同于hadoop基于slot-based实现的fair scheduler和capacity scheduler，论文阅读：Dominant Resource Fairness: Fair Allocation of Multiple Resource Types 。
考虑在一个包括多种资源类型(主要考虑CPU和MEM)的系统的公平资源分配问题，其中不同用户对资源有不同的需求。为了解决这个问题，伯克利的几位大牛提出了Dominant Resource Fairness(DRF)，一种针对不同资源类型的max-min fairness。并且在Mesos的设计和实现中评估了DRF，显示了它可以比slot-based 公平调度算法得到更好的吞吐量。

DRF是一种通用的多资源的max-min fairness分配策略。在多环境下一个用户的资源分配应该由用户的dominant share（主导份额的资源）决定，dominant share是在所有已经分配给用户的多种资源中，占据最大份额的一种资源。简而言之，DRF试图最大化所有用户中最小的dominant share。

举个例子，假如用户A运行CPU密集的任务而用户B运行内存密集的任务，DRF会试图均衡用户A的CPU资源份额和用户B的内存资源份额。在单个资源的情形下，那么DRF就会退化为max-min fairness。

DRF有四种主要特性，分别是：sharing incentive、strategy-proofness、Pareto efficiency和envy-freeness。
DRF是通过确保系统的资源在用户之间是静态和均衡地进行分配来提供sharing incentive，用户不能获得比其他用户更多的资源。此外，DRF是strategy-proof，用户不能通过谎报其资源需求来获得更多的资源。DRF是Pareto-efficient，在满足其他特性的同时，分配所有可以利用的资源，不用取代现有的资源分配。最后，DRF是envy-free，用户不会更喜欢其他用户的资源分配。

考虑一个有9个cpu和18GB的系统，有两个用户：用户A的每个任务都请求（1CPU，4GB）资源；用户B的每个任务都请求（3CPU，1GB）资源。如何为这种情况构建一个公平分配策略？

对于用户A，每个任务需要消耗的资源为<1/9,4/18>=<1/9,2/9>,所以A的dominant shares为内存，比例为2/9

对于用户B，每个任务需要消耗的资源为<3/9,1/18>=<1/3,1/18>,所以B的dominant shares为cpu，比例为1/3

YARN中用的作业调度算法：DRF（Dominant Resource Fairness）

通过列不等式方程可以解得给用户A分配3份资源，用户B分配2份资源是一个很好的选择。

DRF的算法伪代码为：

YARN中用的作业调度算法：DRF（Dominant Resource Fairness）

使用DRF的思路，分配的过程如下表所示，注意，每一次选择为哪个资源分配的决定，取决于上次分配之后，目前dominant share最小的那个用户可以得到下一次的资源分配。

每次迭代都要选择一个用户为其分配资源，用户的选择办法：选择当前Si最小的用户。

Si：已经分配给用户i的主资源占这种资源总量的比例

在这个例子中，用户A的CPU占总CPU 1/9，MEM占总MEM的 2/9，而用户B的CPU占1/3，MEM占2/9，所以A的主资源为内存，B的主资源为CPU。基于这点，DRF会最大化A的内存的最小化分配，并会最大化B的CPU的最小分配。

Max-min Fair
分配过程是每次先把资源平分，如果有用户分到多余的资源就拿出来继续给其他的平分，这样保证申请者都可以公平分到资源。举个例子：

假设有10G内存，四个用户要申请的资源为：<u1, 1G> <u2, 2G> <u3, 4G> <u4, 6G>

先把10G内存平分，每个用户分到2.5内存，即<u1, 2.5G> <u2, 2.5G> <u3, 2.5G> <u4, 2.5G>
u1只要1G，剩下的1.5G给u2 u3 u4平分，各分到0.5G，这个时候变成：<u1, 1G> <u2, 3G> <u3, 3G> <u4, 3G>
u2只需要2G，多出来的1G给u3 u4分，各分到0.5G，变成<u1, 1G> <u2, 2G> <u3, 3.5G> <u4, 3.5G>
这个时候u3 u4都资源都不够，分配到此结束，最终结果：<u1, 1G> <u2, 2G> <u3, 3.5G> <u4, 3.5G>

Max-min Fair策略的不足是只能使用于一种资源的场景，对于有多种资源的场景无能为力。参考 http://www.ece.rutgers.edu/~marsic/Teaching/CCN/minmax-fairsh.html

Dominant Resource Fairness (DRF)
DRF可以看到多资源分配的Max-min，如果将DRF应用到一种资源，那就等价于Max-min。其主要概念是Dominant Resource。

比如有CPU和内存两种资源需要分配，总共有<20, 100>（这里单位都是1，即有20单位CPU，100单位内存，分配的最小单位是1单位），假如一个用户的要申请<2,5>的资源，这个时候CPU占总量的0.1，内存占总量的0.05，因此对这个用户来说CPU就是主资源。
DRF要求各个用户分配到的主资源占总量的比例相等，举个例子：

CPU和内存资源总量为<10, 100>，3个用户资源申请量为：<u1, <1,2>> <u2, <1,20>> <u3, <4,25>>，则u1 u2 u3的主资源分别为CPU 内存 CPU，假设分配的量分别为x y z则要满足下面的条件：
x + y + 4z <= 10
2x + 20y + 25z <= 100
x/10 = 20y/100 = 4z/10
满足这个条件的最大值为x=4, y=2, z=1。如果没有用户的每次申请都是用来运行任务，则u1可以运行4个任务，u2可以运行2个，u3可以运行1个。
参考 https://stackoverflow.com/questions/39347670/explanation-of-yarns-drf

CDH Yarn资源队列划分管理
场景：根据不同项目或不同用户，对yarn资源队列进行划分，达到资源管控，任务管控的目的
CDH版本：5.x
配置：
1 yarn资源队列参数设置：
(1)yarn.scheduler.fair.user-as-default-queue false

解释：当设置为 true 时，如果未指定池名称，Fair Scheduler 将会使用用户名作为默认的池名称。当设置为 false 时，所有应用程序都在一个名为 default 的共享池中运行。设置成false是为了不根据用户名而自动分配资源池。

Fair Scheduler：yarn的公平调度器，对全局资源和对所有的应用作业都均匀分配的资源分配方法。默认情况下，它是基于内存来安排公平调度策略，也可以配置成为同时基于内存和CPU来进行调度。总的来说，它是一种基于内存，给集群中所提交的应用程序分配资源的调度器。

(2)yarn.scheduler.fair.allow-undeclared-pools false

解释：设置为 true 时，将使用默认设置创建在应用程序中指定但未明确配置的池。设置为 false 时，将在名为 default 的池中运行应用程序指定的未明确配置的池。此设置适用于应用程序明确指定某个池时以及应用程序运行所在的池的名称为与该应用程序关联的用户名的情况。

默认是true，允许创建未定义的资源池。当用户提交了一个作业，指定的队列不存在的时候，会自动创建出这个不存在的队列。设置成false，如果任务中指定了一个未定义的资源池，那么这个资源池将不会被创建，该任务会被分配到默认的资源池中，default。

修改完配置重启服务
2 CDH 动态资源队列配置

如图，第一步我们划分了2个资源池：、
(1)root.default:默认池，没有划分资源池的用户会提交到default资源池

权重定义了资源池之间分配资源的比例，目前集群中的default资源池和users资源池的权重各为1,那么集群中的资源会将50%分配给default，50%分配给users，但是这里的资源分配不是一个静态的概念，假如users中没有任务在运行，那么default资源池是允许使用超过50%的资源的，且资源池配置允许在线修改，修改后不需要重启yarn，因为RM会周期性的读取资源池的配置信息

设置default资源池的调度算法：使用DRF，即根据内存和CPU进行资源调度

yarn.scheduler.fair.preemption解释：启用后，如果在某些时间段未达到池的最小共享，Fair Scheduler 可以优先选取其他池中的应用程序。优先权可保证生产应用程序不缺乏资源，同时还可使群集用于实验和研究应用程序。为尽量减少计算资源浪费，Fair Scheduler 会优先选取最近启动的应用程序。

该项不建议开启。
Yarn的资源抢占本身就具有一定的资源开销，并且如果开启了资源抢占，对于长时间运行的任务容易出现延迟的情况。所以在此也建议配置队列时，要将长时间运行任务和执行时间较短的任务放在不同的队列中。同时对于队列的maxResource，可以适当的配置大些，这样即使不打开抢占，RM也是可以将一个队列的已经运行完成的资源回收分配给别的队列。从而达到提高资源的利用率。

解释：
yarn.acl.enable：指定是否应检查管理 ACL 中指定的用户和组执行管理操作的授权。
yarn.admin.acl：确定哪些用户和组可在任何池中提交和中止应用程序以及可以对 ResourceManager 角色发出命令的 ACL。

重启服务

添加was用户资源池

资源池的提交控制访问和管理控制访问的配置会自动继承到子队列中，比如在root资源池下的提交控制访问中配置了用户was，那么即使root.test的提交用户访问中配置是空，用户was也可以向队列test中提交yarn应用程序。

计划模式：可以根据不同时间段使用不同的资源池配置，合理使用集群的纵向资源

创建新的计划规则：

配置完计划模式，资源池会有多套配置，如下

配置完不同时间段使用的配置集后，修改各配置集的资源分配。例如streaming资源池在默认的配置集下，权重是2，使用的集群的资源占50%,但是在night配置集下配置的权重是1，使用的集群的资源占33%。而nigth配置集是在每天晚上8点到第二天早上六点时间段生效的。

放置规则：控制任务使用资源池的规则，即任务会根据以下的规则放到对应的资源池中执行，不需要自定义配置，在提交任务的时候显示的指定队列即可

用户限制：控制用户可以提交的最大应用程序数量，可以统一配置，也可以单独给某个用户配置

在这里插入图片描述

抢占任务

在资源调度器中，每个队列可设置一个最小资源量和最大资源量，其中，最小资源量是资源紧缺情况下每个队列需保证的资源量，而最大资源量则是极端情况下队列也不能超过的资源使用量。
开启资源抢占后当某个队列资源不足时，调度器会杀死其他队列的container以释放资源，分给这个队列。这个特性默认是关闭的。关键点有两个：1.启动抢占式调度的条件？2.选择哪些container去杀掉？
每个队列都有minShare、fairShare属性。这两个属性是抢占式调度的阈值。当一个队列使用的资源小于fairShare*X（defaultFairSharePreemptionThreshold）、或者小于minShare，并且持续超过一定时间（这两种情况的超时时间不同，可以设置），就会开始抢占式调度。
Schedulabe的fairShare是会不断变化的（minShare一般不会变化）。如果队列的minResource、maxResource、权重等属性变化，fairShare都要重新计算。application开始或结束，也都要重新计算fairShare。FairScheduler中有一个线程UpdateThread，默认每0.5秒调用一次update方法，就会重新计算fairShare。（具体算法：https://blog.csdn.net/zhanyuanlin/article/details/72667293#1-steady-fair-share-%E5%8E%9F%E7%90%86%E5%92%8C%E8%AE%A1%E7%AE%97%E6%96%B9%E5%BC%8F）。
当FairScheduler决定开始抢占时，首先会计算要抢得的资源量。对于使用资源量小于minShare的，要恢复到minShare；对于使用量小于fairShare*X的，需要恢复到fairShare。将所有要恢复的资源量相加，得出要抢的的资源总量。然后遍历所有LeafQueue，找到所有资源用量大于fairShare的app，将他们在运行的container加入一个List，按优先级升序排列。然后遍历，优先杀死优先级低的container。当释放足够的资源后，抢占停止。（具体的筛选过程：http://bigdatadecode.club/YARN%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E4%B9%8BFair%20Scheduler%20part2.html）
总结一下筛选过程，计算出需要抢占的资源总数之后就是找出抢哪些container。找哪些container的流程是从root队列一层一层的查找可以抢占的队列，然后从队列中找到Application，最后找到可以抢占的container。筛选被抢占队列原则：选择超过fairShare最多的队列；在app中选择container是根据container的优先级，抢占优先级最低的container，container的优先级是由数字标识的，数字越大优先级越低。
在YARN中，队列是按照树形结构组织的，一个队列当前实际可以使用的资源量R取决于最小资源量A（由管理员配置）、队列资源需求量（处于等待或者运行状态的应用程序尚需的资源总量）和同父兄弟队列的空闲资源量C（多余资源可共享给其他队列），这意味着R在不同时间点的取值是不同的，可以按照递归算法求出R=F(A, B, C)，这样，如果一个队列当前正在使用资源量U>R，则需从该队列中抢占(U-R)资源。
为了尽可能避免资源浪费，YARN优先选择优先级低的Container作为资源抢占对象，且不会立刻杀死Container，而是将释放资源的任务留给应用程序自己：ResourceManager将待杀死的Container列表发送给对应的ApplicationMaster，以期望它采取一定的机制自行释放这些Container占用的资源，比如先进行一些状态保存工作后，再将对应的Container杀死，以避免计算浪费，如果一段时间后，ApplicationMaster尚未主动杀死这些Container，则ResourceManager再强制杀死这些Container。

CDH版本开启资源抢占参数分析：

Fair Share Preemption Threshold：介于0-1之间，代表一个比重，可以得到一个临界值，当队列使用资源小于这个比重X*fairShare时开始抢占。
FairSharePreemptionTimeout：如果队列在minimum share preemption timeout指定的时间内未获得被承诺的最小共享资源，调度器就会抢占其他容器。
MinSharePreemptionTimeout：如果队列在fair share preemption timeout指定的时间内获得的资源仍然地域其公平共享份额的一半，那么调度器就会抢占其他容器。

抢占任务可精简队列中的job运行并提高资源利用率，由ResourceManager的capacity scheduler实现，其简易流程如下：

假设存在两个队列A和B。其中队列A的capacity为25%，队列B的capacity为75%。
初始状态下，任务1发送给队列A，此任务需要75%的集群资源。之后任务2发送到了队列B，此任务需要50%的集群资源。
任务1将会使用队列A提供的25%的集群资源，并从队列B获取的50%的集群资源。队列B保留25%的集群资源。
启用抢占任务特性，则任务1使用的资源将会被抢占。队列B会从队列A中获取25%的集群资源以满足任务2的执行。
当任务2完成后，集群中存在足够的资源时，任务1将重新开始执行。

yarn.resourcemanager.scheduler.monitor.enable
根据“yarn.resourcemanager.scheduler.monitor.policies”中的策略，启用新的scheduler监控。设置为“true”表示启用监控，并根据scheduler的信息，启动抢占的功能。设置为“false”表示不启用。

yarn.resourcemanager.scheduler.monitor.policies
设置与scheduler配合的“SchedulingEditPolicy”的类的清单。
org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy

yarn.resourcemanager.monitor.capacity.preemption.observe_only
设置为“true”，则执行策略，但是不对集群资源进程抢占操作。
设置为“false”，则执行策略，且根据策略启用集群资源抢占的功能。

yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval
根据策略监控的时间间隔，单位为毫秒。如果将该参数设置为更大的值，容量检测将不那么频繁地运行。

yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill
应用发送抢占需求到停止container（释放资源）的时间间隔，单位为毫秒。取值范围大于等于0。
默认情况下，若ApplicationMaster15秒内没有终止container，ResourceManager等待15秒后会强制终止。

yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round
在一个周期内能够抢占资源的最大的比例。可使用这个值来限制从集群回收容器的速度。计算出了期望的总抢占值之后，策略会伸缩回这个限制。

yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity

集群中资源总量乘以此配置项的值加上某个队列（例如队列A）原有的资源量为资源抢占盲区。当队列A中的任务实际使用的资源超过该抢占盲区时，超过部分的资源将会被抢占。取值范围：0~1。
设置的值越小越有利于资源抢占。

yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor
设置抢占目标，Container只会抢占所配置比例的资源。
示例，如果设置为0.5，则在5*“yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill”的时间内，任务会回收所抢占资源的近95%。即接连抢占5次，每次抢占待抢占资源的0.5，呈几何收敛，每次的时间间隔为“yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill”。取值范围：0~1。

Yarn-site.xml
yarn.scheduler.fair.allow-undeclared-pools
设置为true时，如果未指定池名称，Fair Scheduler将使用用户名作为默认池名称。当设置为false时，所有应用程序都在一个称为default的共享池中运行。

yarn.scheduler.fair.user-as-default-queue
如果设置为true，则在运行时使用默认设置创建应用程序中指定但未显式配置的池。当设置为false时，指定未显式配置的池的应用程序将在名为default的池中运行。当应用程序显式指定池时，以及当应用程序在使用与应用程序关联的用户名命名的池中运行时，将应用此设置。

yarn.scheduler.fair.preemption
启用时，在某些条件下，公平调度程序会抢占其他池中的应用程序。抢占保证了生产应用程序不被耗尽，同时也允许集群用于实验和研究应用程序。为了最小化浪费的计算，公平调度器抢占最近启动的应用程序。

yarn.scheduler.fair.preemption.cluster-utilization-threshold
触发抢占的群集利用率阈值。如果群集利用率低于此阈值，则即使存在饥饿队列，也不会触发抢占。利用率计算为所有资源中使用率与容量的最大比率。

 <property>
    <name>yarn.scheduler.fair.allow-undeclared-pools</name>
    <value>true</value>
  </property>
  <property>
    <name>yarn.scheduler.fair.user-as-default-queue</name>
    <value>true</value>
  </property>
  <property>
    <name>yarn.scheduler.fair.preemption</name>
    <value>true</value>
  </property>
  <property>
    <name>yarn.scheduler.fair.preemption.cluster-utilization-threshold</name>
    <value>0.8</value>
  </property>

fair-scheduler.xml
queuePlacementPolicy用于将作业分配给资源池的策略。在Cloudera Manager中，此属性是使用放置规则配置的。
userMaxAppsDefault未另行指定限制的用户的默认运行应用程序限制。在Cloudera Manager中，此属性是使用用户限制配置的。
queueMaxAppsDefault池的默认运行应用限制；由池中的等效元素重写。
queueMaxAMShareDefault池的默认ApplicationMaster资源限制；由池中的等效元素重写。
DefaultFairSharePreemption池的Reshold FairShare抢占阈值；由池中的等效元素重写。阈值介于0和1之间。如果设置为x且池的公平份额为F，则如果分配小于（x*F），则资源将从其他池中抢占。
defaultFairSharePreemptionTimeout资源池在其公平共享下抢占容器以从其他资源池获取资源之前的默认秒数；由池中的等效元素重写。如果未设置此参数，并且未为给定队列或其祖先队列设置fairSharePreemptionTimeout，则即使启用了抢占，也不会发生此队列的抢占。默认超时为2^64毫秒。
DefaultMinSharePremptionTimeout资源池在抢占容器以从其他资源池获取资源之前，处于其最小共享下的默认秒数；由池中的等效元素重写。
defaultQueueSchedulingPolicy池的默认调度策略；由池中的等效元素重写。
动态资源池的队列名称。
权重在确定如何相对于其他资源池分配资源时赋予资源池的权重。在Cloudera Manager中，此属性是使用配置集配置的。
schedulingPolicy确定如何将资源分配到资源池的策略：fair、fifo或drf。
aclsubmitaps可以向池提交作业的用户和组。
ACLAdministrateApps可以管理池的用户和组。

minResources，maxResources可以以X mb，Y vcores的形式分配给资源池的最小和最大资源共享。由权重设置计算的值受最小值和最大值的限制（或约束）。

maxAMShare资源池公平共享的一部分，可用于运行ApplicationMasters。例如，如果设置为1.0，则池中的应用程序管理员最多可以占用100%的内存和CPU公平共享。值-1.0将禁用此功能，并且不会选中ApplicationMaster共享。默认值为0.5。

maxRunningApps查看默认元素。
FairSharePreemptionReshold请参阅默认元素。
fairSharePreemptionTimeout请参阅默认元素。
MinSharePremptionTimeout请参阅默认元素。

<allocations>
    <queue name="root">
        <weight>1.0</weight>
        <schedulingPolicy>drf</schedulingPolicy>
        <aclSubmitApps> </aclSubmitApps>
        <aclAdministerApps>*</aclAdministerApps>
        <queue name="production">
            <minResources>1024 mb, 10 vcores</minResources>
            <maxResources>5120 mb, 20 vcores</maxResources>
            <weight>4.0</weight>
            <schedulingPolicy>drf</schedulingPolicy>
            <aclSubmitApps>*</aclSubmitApps>
            <aclAdministerApps>*</aclAdministerApps>
        </queue>
        <queue name="development">
            <weight>1.0</weight>
            <schedulingPolicy>drf</schedulingPolicy>
            <aclSubmitApps>*</aclSubmitApps>
            <aclAdministerApps>*</aclAdministerApps>
        </queue>
    </queue>
    <defaultQueueSchedulingPolicy>drf</defaultQueueSchedulingPolicy>
    <queuePlacementPolicy>
        <rule name="specified" create="true"/>
        <rule name="user" create="true"/>
    </queuePlacementPolicy>
</allocations>

任务优先级

提交两个低优先级的应用Job 1和Job 2。
正在运行中的Job 1和Job 2有部分task处于running状态，但由于集群或队列资源容量有限，仍有部分task未得到资源而处于pending状态。
提交一个较高优先级的应用Job 3，此时会出现如下资源分配情况：当Job 1和Job 2中running状态的task运行结束并释放资源后，Job 3中处于pending状态的task将优先得到这部分新释放的资源。
Job 3完成后，资源释放给Job 1、Job 2继续执行。
用户可以在YARN中配置任务的优先级。任务优先级是通过ResourceManager的Capacity Scheduler实现的。

操作步骤
设置参数“mapreduce.job.priority”，使用命令行接口或API接口设置任务优先级。

命令行接口。
提交任务时，添加“-Dmapreduce.job.priority=”参数。

可以设置为：

VERY_HIGH
HIGH
NORMAL
LOW
VERY_LOW
API接口。
用户也可以使用API配置对象的优先级。

设置优先级，可通过Configuration.set(“mapreduce.job.priority”, )或Job.setPriority(JobPriority priority)设置。

节点配置调优

可用内存
除了分配给操作系统、其他服务的内存外，剩余的资源应尽量分配给YARN。通过如下配置参数进行调整。
例如，如果一个container默认使用512M，则内存使用的计算公式为：512M*container数。
默认情况下，Map或Reduce container会使用1个虚拟CPU内核和1024MB内存，ApplicationMaster使用1536MB内存。

yarn.nodemanager.resource.memory-mb
设置可分配给容器的物理内存数量。单位：MB，取值范围大于0。
建议配置成节点物理内存总量的75%~90%。若该节点有其他业务的常驻进程，请降低此参数值给该进程预留足够运行资源。
MRS 3.x及之后：16384
MRS 3.x之前：8192

CPU虚拟核数
建议将此配置设定在逻辑核数的1.5～2倍之间。如果上层计算应用对CPU的计算能力要求不高，可以配置为2倍的逻辑CPU。

yarn.nodemanager.resource.cpu-vcores
表示该节点上YARN可使用的虚拟CPU个数，默认是8。
目前推荐将该值设值为逻辑CPU核数的1.5～2倍之间。
物理CPU使用百分比
建议预留适量的CPU给操作系统和其他进程（数据库、HBase等）外，剩余的CPU核都分配给YARN。可以通过如下配置参数进行调整。

yarn.nodemanager.resource.percentage-physical-cpu-limit
表示该节点上YARN可使用的物理CPU百分比。默认是90，即不进行CPU控制，YARN可以使用节点全部CPU。该参数只支持查看，可通过调整YARN的RES_CPUSET_PERCENTAGE参数来修改本参数值。注意，目前推荐将该值设为可供YARN集群使用的CPU百分数。
例如：当前节点除了YARN服务外的其他服务（如HBase、HDFS、Hive等）及系统进程使用CPU为20%左右，则可以供YARN调度的CPU为1-20%=80%，即配置此参数为80。

本地磁盘
由于本地磁盘会提供给MapReduce写job执行的中间结果，数据量大。因此配置的原则是磁盘尽量多，且磁盘空间尽量大，单个达到百GB以上规模最好。简单的做法是配置和data node相同的磁盘，只在最下一级目录上不同即可。

说明：
多个磁盘之间使用逗号隔开。

yarn.nodemanager.log-dirs
日志存放地址（可配置多个目录）。

容器日志的存储位置。默认值为%{@auto.detect.datapart.nm.logs}。如果有数据分区，基于该数据分区生成一个类似/srv/BigData/hadoop/data1/nm/containerlogs,/srv/BigData/hadoop/data2/nm/containerlogs的路径清单。如果没有数据分区，生成默认路径/srv/BigData/yarn/data1/nm/containerlogs。除了使用表达式以外，还可以输入完整的路径清单，比如/srv/BigData/yarn/data1/nm/containerlogs或/srv/BigData/yarn/data1/nm/containerlogs,/srv/BigData/yarn/data2/nm/containerlogs。这样数据就会存储在所有设置的目录中，一般会是在不同的设备中。为保证磁盘IO负载均衡，最好提供几个路径且每个路径都对应一个单独的磁盘。应用程序的本地化后的日志目录存在于相对路径/application_%{appid}中。单独容器的日志目录，即container_{$contid}，是该路径下的子目录。每个容器目录都含容器生成的stderr、stdin及syslog文件。要新增目录，比如新增/srv/BigData/yarn/data2/nm/containerlogs目录，应首先删除/srv/BigData/yarn/data2/nm/containerlogs下的文件。之后，为/srv/BigData/yarn/data2/nm/containerlogs赋予跟/srv/BigData/yarn/data1/nm/containerlogs一样的读写权限，再将/srv/BigData/yarn/data1/nm/containerlogs修改为/srv/BigData/yarn/data1/nm/containerlogs,/srv/BigData/yarn/data2/nm/containerlogs。可以新增目录，但不要修改或删除现有目录。否则，NodeManager的数据将丢失，且服务将不可用。

【默认值】%{@auto.detect.datapart.nm.logs}

【注意】请谨慎修改该项。如果配置不当，将造成服务不可用。当角色级别的该配置项修改后，所有实例级别的该配置项都将被修改。如果实例级别的配置项修改后，其他实例的该配置项的值保持不变。

%{@auto.detect.datapart.nm.logs}

yarn.nodemanager.local-dirs

本地化后的文件的存储位置。默认值为%{@auto.detect.datapart.nm.localdir}。如果有数据分区，基于该数据分区生成一个类似/srv/BigData/hadoop/data1/nm/localdir,/srv/BigData/hadoop/data2/nm/localdir的路径清单。如果没有数据分区，生成默认路径/srv/BigData/yarn/data1/nm/localdir。除了使用表达式以外，还可以输入完整的路径清单，比如/srv/BigData/yarn/data1/nm/localdir或/srv/BigData/yarn/data1/nm/localdir,/srv/BigData/yarn/data2/nm/localdir。这样数据就会存储在所有设置的目录中，一般会是在不同的设备中。为保证磁盘IO负载均衡，最好提供几个路径且每个路径都对应一个单独的磁盘。应用程序的本地化后的文件目录存在于相对路径/usercache/%{user}/appcache/application_%{appid}中。单独容器的工作目录，即container_%{contid}，是该路径下的子目录。要新增目录，比如新增/srv/BigData/yarn/data2/nm/localdir目录，应首先删除/srv/BigData/yarn/data2/nm/localdir下的文件。之后，为/srv/BigData/hadoop/data2/nm/localdir赋予跟/srv/BigData/hadoop/data1/nm/localdir一样的读写权限，再将/srv/BigData/yarn/data1/nm/localdir修改为/srv/BigData/yarn/data1/nm/localdir,/srv/BigData/yarn/data2/nm/localdir。可以新增目录，但不要修改或删除现有目录。否则，NodeManager的数据将丢失，且服务将不可用。

【默认值】%{@auto.detect.datapart.nm.localdir}

HA

在这里插入图片描述

FAQ

为什么执行任务时AppAttempts重试次数超过2次还没有运行失败
系统默认的AppAttempts运行失败的次数为2，为什么在执行任务时，AppAttempts重试次数超过2次还没有运行失败？
在执行任务过程中，若ContainerExitStatus的返回值为ABORTED、PREEMPTED、DISKS_FAILED、KILLED_BY_RESOURCEMANAGER这四种状态之一时，系统不会将其计入failed attempts中，因此出现上面的问题，只有当真正失败尝试2次之后才会运行失败。

为什么YARN资源池的所有节点都被加入黑名单，而YARN却没有释放黑名单，导致任务一直处于运行状态
为什么YARN资源池的所有节点都被加入黑名单，而YARN却没有释放黑名单，导致任务一直处于运行状态？
在YARN中，当一个APP的节点被AM（ApplicationMaster）加入黑名单的数量达到一定比例（默认值为节点总数的33%）时，该AM会自动释放黑名单，从而不会出现由于所有可用节点都被加入黑名单而任务无法获取节点资源的现象。

在资源池场景下，假设该集群上有8个节点，通过NodeLabel特性将集群划分为两个资源池，pool A和pool B，其中pool B包含两个节点。用户提交了一个任务App1到pool B，由于HDFS空间不足，App1运行失败，导致pool B的两个节点都被App1的AM加入了黑名单，根据上述原则，2个节点小于8个节点的33%，所以YARN不会释放黑名单，使得App1一直无法得到资源而保持运行状态，后续即使被加入黑名单的节点恢复，App1也无法得到资源。

由于上述原则不适用于资源池场景，所以目前可通过调整客户端参数“yarn.resourcemanager.am-scheduling.node-blacklisting-disable-threshold”为：(nodes number of pool / total nodes )* 33%解决该问题。

安全模式下，为什么作业执行失败时会抛出HDFS_DELEGATION_TOKEN到期的异常？
HDFS_DELEGATION_TOKEN到期的异常是由于token没有更新或者超出了最大生命周期。
在token的最大生命周期内确保下面的参数值大于作业的运行时间。
“dfs.namenode.delegation.token.max-lifetime”=“604800000”（默认是一星期）
参考修改集群服务配置参数，进入HDFS“全部配置”页面，在搜索框搜索该参数。
建议在token的最大生命周期内参数值为多倍小时数。

任务完成后Container挂载的文件目录未清除
使用了CGroups功能的场景下，任务完成后Container挂载的文件目录未清除。
即使任务失败，Container挂载的目录也应该被清除。

上述问题是由于删除动作超时导致的。完成某些任务所使用的时间已远超过删除时间。
为避免出现这种场景，您可以参考修改集群服务配置参数，进入Yarn“全部配置”页面。在搜索框搜索“yarn.nodemanager.linux-container-executor.cgroups.delete-timeout-ms”配置项来修改删除时间的时长。参数值的单位为毫秒。

大量YARN工作负载的较大群集（超过75个节点）
yarn.scheduler.fair.continuousscheduling-enabled =false
yarn.scheduler.fair.assignmultiple=true

yarn.nodemanager.resource.cpu-vcores 容器虚拟CPU内核
yarn.nodemanager.resource.memory-mb 容器内存
yarn.scheduler.minimum-allocation-vcores 容器虚拟CPU内核最低要求
yarn.scheduler.maximum-allocation-vcores 容器虚拟CPU核心数上限
yarn.scheduler.increment-allocation-vcores 容器虚拟CPU内核增量
yarn线调度器最小分配MB 容器内存最小
6 yarn.scheduler.maximum-allocation-mb 容器内存最大
6 yarn线计划程序增量分配mb 容器内存增量
7 yarn.app.mapreduce.am.resource.cpu-vcores ApplicationMaster虚拟CPU内核
7 yarn.app.mapreduce.am.resource.mb 应用程序主存储器
7 mapreduce.map.cpu.vcores Map Task CPU虚拟核心
7 mapreduce.map.memory.mb 地图任务记忆
7 mapreduce.reduce.cpu.vcores 减少任务CPU虚拟核心
7 mapreduce.reduce.memory.mb 减少任务记忆
7 mapreduce.task.io.sort.mb I / O排序存储器

从图中可以看到整个集群的一些监控信息：

应用信息：9个等待，7个执行，51个完成，总结67个；其中有15个 container 正在执行。
内存信息：总共36G，使用了30G，保留10G。
虚拟核信息：总共20个，使用了15个，保留5个。
节点信息：可用节点5个，退服0个，丢失节点0个，不健康节点0个，重启节点0个。
调度器信息：使用 Fair Scheduler（公平调度器），最大最小的内存和 CPU 分配信息。
其中 Application Queues 栏包含了集群的任务队列信息（以 root.hadoop 队列为例）：

使用的资源：内存30720M（30G），虚拟核15个。
正在执行的应用7个。
等待的应用9个。
占用最小资源：0M，0核。
占用最大资源：36860M，20核。
队列资源的稳定的公共共享。
队列的瞬时公平共享资源。
该队列占用资源的比例为83.3%。

HA

在这里插入图片描述

猿与禅

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
大数据最佳实践-yarn

目录yarn预热参数调优抢占任务调度策略yarn预热在开始新会话之后提交第一个查询时，您可能会遇到稍长的延迟，然后才能看到查询开始。您可能还会注意到，如果再次运行相同的查询，它的完成速度将比第一个查询快得多。Spark执行者需要额外的时间来启动和初始化YARN群集上的Spark，这会导致更长的延迟。另外，Spark在开始作业之前不会等待所有执行者准备就绪，因此在将作业提交到集群后，某些执行者可能仍在启动。但是，对于在Spark上运行的作业，提交作业时可用执行程序的数量部分决定了减速器的数量。当准备好的
复制链接

扫一扫