本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 在 Amazon EMR 中使用托管扩展
托管扩展

**重要**  
我们强烈建议您使用最新的亚马逊 EMR 版本（亚马逊 EMR 7.12.0）进行托管扩展。在某些早期的发行版中，您可能会遇到间歇性的应用程序故障或扩展延迟。Amazon EMR 已通过 5.x 发行版 5.30.2、5.31.1、5.32.1、5.33.1 及更高版本，以及 6.x 发行版 6.1.1、6.2.1、6.3.1 及更高版本解决了此问题。有关区域和发行版可用性的更多信息，请参阅 [托管式自动扩缩功能的可用性](#emr-managed-scaling-availability)。

## 概述


使用 Amazon EMR 版本 5.30.0 及更高版本（Amazon EMR 6.0.0 除外），您可以启用 Amazon EMR 托管式自动扩缩功能。托管扩展让您根据工作负载自动增加或减少集群中实例或单元的数量。Amazon EMR 会持续评估集群指标，以便做出扩展决策，从而优化集群的成本和速度。托管扩展适用于由实例组或实例队列组成的集群。

## 托管式自动扩缩功能的可用性
可用性
+ 在下文中 Amazon Web Services 区域，亚马逊 EMR 6.14.0 及更高版本支持亚马逊 EMR 托管扩展：
  + 亚太地区（台北）（ap-east-2）
  + 亚太地区（墨尔本）(ap-southeast-4)
  + 亚太地区（马来西亚）（ap-southeast-5）
  + 亚太地区（新西兰）（ap-southeast-6）
  + 亚太地区（泰国）（ap-southeast-7）
  + 加拿大西部（卡尔加里）（ca-west-1）
  + 欧洲（西班牙）(eu-south-2)
  + 墨西哥（中部）（mx-central-1）
+ 在下文中 Amazon Web Services 区域，亚马逊 EMR 托管扩展适用于亚马逊 EMR 5.30.0 和 6.1.0 及更高版本：
  + 美国东部（弗吉尼亚州北部）（us-east-1）
  + 美国东部（俄亥俄州）(us-east-2)
  + 美国西部（俄勒冈州）(us-west-2)
  + 美国西部（北加利福尼亚）(us-west-1)
  + 非洲（开普敦）(af-south-1)
  + 亚太地区（香港）(ap-east-1)
  + 亚太地区（孟买）(ap-south-1)
  + 亚太地区（海得拉巴）(ap-south-2)
  + 亚太地区（首尔）(ap-northeast-2)
  + 亚太地区（新加坡）(ap-southeast-1)
  + 亚太地区（悉尼）(ap-southeast-2)
  + 亚太地区（雅加达）（ap-southeast-3）
  + 亚太地区（东京）(ap-northeast-1)
  + 亚太地区（大阪）(ap-northeast-3)
  + 加拿大（中部）(ca-central-1)
  + 南美洲（圣保罗）（sa-east-1）
  + 欧洲地区（法兰克福）(eu-central-1)
  + 欧洲（苏黎世）(eu-central-2)
  + 欧洲地区（爱尔兰）(eu-west-1)
  + 欧洲地区（伦敦）(eu-west-2)
  + 欧洲地区（米兰）(eu-south-1)
  + 欧洲（巴黎）（eu-west-3）
  + 欧洲地区（斯德哥尔摩）(eu-north-1)
  + 以色列（特拉维夫）（il-central-1）
  + 中东（阿联酋）(me-central-1)
  + 中国（北京）（cn-north-1）
  + 中国（宁夏）（cn-northwest-1）
  + Amazon GovCloud (美国东部) (us-gov-east-1)
  + Amazon GovCloud (美国西部) (us-gov-west-1)
+ Amazon EMR 托管扩展仅适用于 YARN 应用程序，如 Spark、Hadoop、Hive 和 Flink。它不支持不基于 YARN 的应用程序，例如 Presto 和。 HBase

## 托管扩展参数
参数

您必须为托管扩展配置以下参数。该限制仅适用于核心节点和任务节点。初始配置后，无法扩展主节点。
+ **Minimum (最小)**（`MinimumCapacityUnits`）：集群中允许的 EC2 容量的下限。其衡量方式为通过虚拟中央处理单位（vCPU）核心或实例组中的实例进行衡量。其衡量方式为通过实例集单位进行衡量。
+ **Maximum (最大)**（`MaximumCapacityUnits`）：集群中允许的 EC2 容量的上限。其衡量方式为通过虚拟中央处理单位（vCPU）核心或实例组中的实例进行衡量。其衡量方式为通过实例集单位进行衡量。
+ **On-Demand limit (按需限制)**（`MaximumOnDemandCapacityUnits`）（可选）：集群中按需市场类型允许的 EC2 容量的上限。如果未指定此参数，则默认为 `MaximumCapacityUnits` 的值。
  + 此参数用于在按需实例和竞价型实例之间拆分容量分配。例如，如果您将最小参数设置为 2 个实例，最大参数设置为 100 个实例，按需限制设置为 10 个实例，则 Amazon EMR 托管扩展将纵向扩展到 10 个按需型实例，并将剩余容量分配给竞价型实例。有关更多信息，请参阅 [节点分配方案](managed-scaling-allocation-strategy.md#node-allocation-scenarios)。
+ **Maximum core nodes (最大核心节点)**（`MaximumCoreCapacityUnits`）（可选）：集群中核心节点类型允许的 EC2 容量的上限。如果未指定此参数，则默认为 `MaximumCapacityUnits` 的值。
  + 此参数用于在核心节点和任务节点之间分配容量。例如，如果您将最小参数设置为 2 个实例，最大参数设置为 100 个实例，最大核心节点设置为 17 个实例，则 Amazon EMR 托管扩展将纵向扩展到 17 个核心节点，并将剩余的 83 个实例分配给任务节点。有关更多信息，请参阅 [节点分配方案](managed-scaling-allocation-strategy.md#node-allocation-scenarios)。

有关托管式扩展参数的更多信息，请参阅 [https://docs.amazonaws.cn/emr/latest/APIReference/API_ComputeLimits.html](https://docs.amazonaws.cn/emr/latest/APIReference/API_ComputeLimits.html)。

## Amazon EMR 托管式自动扩缩功能注意事项
注意事项
+ 有限版本 Amazon Web Services 区域 和 Amazon EMR 版本支持托管扩展。有关更多信息，请参阅 [托管式自动扩缩功能的可用性](#emr-managed-scaling-availability)。
+ 您必须为 Amazon EMR 托管扩展配置所需参数。有关更多信息，请参阅 [托管扩展参数](#emr-managed-scaling-parameters)。
+ 要使用托管式扩展，指标收集器进程必须能够连接到公有 API 端点，以便在 API Gateway 中进行托管式扩展。如果您将私有 DNS 名称与一起使用 Amazon Virtual Private Cloud，则托管扩展将无法正常运行。为确保托管式扩展正常运行，我们建议您执行以下操作之一：
  + 从您的 Amazon VPC 中删除 API Gateway 接口 VPC 终端节点。
  + 请按照[为什么从 VPC 连接我的 API Gateway 时会出现 HTTP 403 禁止错误？ APIs 中的说明进行](https://www.amazonaws.cn/premiumsupport/knowledge-center/api-gateway-vpc-connections/)操作 禁用私有 DNS 名称设置。
  + 在您的私有子网中启动集群。有关更多信息，请参阅 [私有子网](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet) 中的主题。
+ 如果您的 YARN 作业在缩减过程中出现间歇性运行缓慢的情况，并且 YARN 资源管理器日志显示在此期间您的大多数节点都被列入拒绝列表，则可以调整停用超时阈值。

  将 `spark.blacklist.decommissioning.timeout` 从 1 小时减少到 1 分钟，以使节点可供其他待处理容器继续进行任务处理。

  您还应将 `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` 设置为更大的值，以确保当时间最长的“Spark 任务”仍在节点上运行时，Amazon EMR 不会强制终止该节点。当前默认值为 60 分钟，这意味着一旦节点进入停用状态，YARN 将在 60 分钟后强制终止容器。

  以下 YARN 资源管理器日志行示例显示了已添加到停用状态的节点：

  ```
  2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []
  ```

  查看 [details on how Amazon EMR integrates with YARN deny listing during decommissioning of nodes](https://www.amazonaws.cn/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/)（有关 Amazon EMR 如何在节点停用期间与 YARN 拒绝名单集成的详细信息）、[拒绝列出的节点](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html)以及[配置节点停用行为](https://docs.amazonaws.cn/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning)的更多信息。
+ 对于 Spark 工作负载，通过将 Spark 属性 **spark.dynamicAllocation.enabled** 更改为 `FALSE` 来禁用 Spark 动态资源分配器 (DRA) 可能会导致托管扩展问题，在这种情况下，集群可能会扩展到超出工作负载所需的量（直至达到最大计算量）。当对这些工作负载使用托管扩展时，建议您保持启用 Spark DRA，这是此属性的默认状态。
+ 过度使用 EBS 卷可能会导致托管扩展问题。我们建议您将 EBS 卷的利用率保持在 90％ 以下。有关更多信息，请参阅 [Amazon EMR 中的实例存储选项和行为](emr-plan-storage.md)。
+ 亚马逊 CloudWatch 指标对于 Amazon EMR 托管扩展的运作至关重要。我们建议您密切监控 Amazon CloudWatch 指标，确保数据不会丢失。有关如何配置 CloudWatch 警报以检测缺失指标的更多信息，请参阅[使用 Amazon CloudWatch 警报](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。
+ 在未安装 Presto 的 5.30.0 和 5.30.1 的集群上进行托管扩展操作可能会导致应用程序故障或导致统一的实例组或实例集处于 `ARRESTED` 状态，尤其是在缩减操作之后快速执行扩展操作时。

  解决方法是即使您的任务不需要 Presto，也可以在使用 Amazon EMR 发行版 5.30.0 和 5.30.1 创建集群时，将 Presto 选为要安装的应用程序。
+ 在为 Amazon EMR 托管扩展设置最大核心节点和按需限制时，请考虑实例组和实例集之间的差异。每个实例组包含相同的实例类型和相同的实例购买选项：按需或 Spot。对于每个实例集，您可以指定最多 5 个实例类型，这些类型可预配置为按需实例和竞价型实例。有关更多信息，请参阅[使用集或统一实例组创建集群](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-instance-group-configuration.html)、[集选项](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options)和 [节点分配方案](managed-scaling-allocation-strategy.md#node-allocation-scenarios)。
+ 对于 Amazon EMR 5.30.0 及更高版本，如果您移除主安全组默认的**允许所有**出站规则 0.0.0.0/，则必须添加一条规则，以允许与您的安全组建立出站 TCP 连接，从而在端口 9443 上访问服务。您的服务访问安全组应允许来自主安全组端口 9443 上的入站 TCP 流量。有关配置安全组的更多信息，请参阅[适用于主实例（私有子网）的 Amazon EMR 托管安全组](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private)。
+ 您可以使用 Amazon CloudFormation 来配置 Amazon EMR 托管扩展。有关更多信息，请参阅《Amazon CloudFormation 用户指南》**中的 [AWS::EMR::Cluster](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html)。
+ 如果您使用的是竞价型节点，请考虑使用节点标签来防止 Amazon EMR 在 Amazon EMR 删除竞价型节点时删除应用程序进程。有关节点标签的更多信息，请参阅[任务节点](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task)。
+ Amazon EMR 6.15 或更低版本默认不支持节点标签。有关更多信息，请参阅[了解节点类型：主节点、核心节点和任务节点。](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)。
+ 如果您使用的是 Amazon EMR 6.15 或更低版本，则只能按节点类型分配节点标签，比如核心节点和任务节点。但是，如果您使用的是 Amazon EMR 7.0 或更高版本，则可以按节点类型和市场类型配置节点标签，比如按需型和竞价型。
+ 如果将应用程序进程限制为核心节点时，应用程序进程需求增加而执行程序需求减少，则可以在同一调整大小操作中重新添加核心节点并删除任务节点。有关更多信息，请参阅[了解节点分配策略和场景](https://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)。
+ Amazon EMR 不会标记任务节点，所以您不能设置 YARN 属性来限制应用程序进程仅用于任务节点。但如果要使用市场类型作为节点标签，则可以使用 `ON_DEMAND` 或 `SPOT` 标签来放置应用程序进程。建议不要在应用程序主进程中使用竞价型节点。
+ 使用节点标签时，当 Amazon EMR 停用某些实例时，集群中的总运行单位可能会暂时超过托管扩展策略中设置的最大计算量。请求的总单位数将始终保持在或低于策略的最大计算量。
+ 托管扩展仅支持节点标签 `ON_DEMAND` 和 `SPOT` 或 `CORE` 和 `TASK`。不支持自定义节点标签。
+ Amazon EMR 会在创建集群和预置资源时创建节点标签。Amazon EMR 不支持在重新配置集群时添加节点标签。启动集群后配置托管扩展时，您也不能修改节点标签。
+ 托管扩展可根据应用程序进程和执行程序需求独立扩展核心节点和任务节点。为防止核心节点缩减时出现 HDFS 数据丢失问题，请遵循核心节点的标准做法。要了解有关核心节点和 HDFS 复制的最佳实践的更多信息，请参阅[注意事项和最佳实践](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-plan-ha-considerations.html)。
+ 不能将应用程序进程和执行程序都放置在 `core` 或 `ON_DEMAND` 节点上。如果要在其中一个节点上同时添加应用程序进程和执行程序，请不要使用 `yarn.node-labels.am.default-node-label-expression` 配置。

  例如，要将应用程序进程和执行程序都放置在 `ON_DEMAND` 节点中，请将最大计算量设置为与 `ON_DEMAND` 节点中的最大计算量相同。同时删除 `yarn.node-labels.am.default-node-label-expression` 配置。

  要在 `core` 节点上同时添加应用程序进程和执行程序，请删除 `yarn.node-labels.am.default-node-label-expression` 配置。
+  当您在节点标签中使用托管扩展时，如果计划并行运行多个应用程序，请设置属性 `yarn.scheduler.capacity.maximum-am-resource-percent: 1`。这样可确保您的应用程序进程充分利用可用的 `CORE` 或 `ON_DEMAND` 节点。
+  当您在节点标签中使用托管扩展时，请将属性 `yarn.resourcemanager.decommissioning.timeout` 设置为比集群中运行时间最长的应用程序更长的值。这样减少了 Amazon EMR 托管扩展需要重新安排应用程序以重新调试 `CORE` 或 `ON_DEMAND` 节点的可能性。
+ 为了降低因随机数据丢失而导致应用程序失败的风险，Amazon EMR 会从集群收集指标，以确定哪些节点具有来自当前阶段和上一阶段的现有瞬态随机排序数据。在极少数情况下，指标可能会继续报告已完成或已终止的应用程序的过时数据。这可能会影响集群中实例的及时缩减。对于拥有大量随机排序数据的集群，请考虑使用 EMR 6.13 及更高版本。

## 功能历史记录


此表列出了对 Amazon EMR 托管扩展功能的更新。


| 发行日期 | 能力 | Amazon EMR 版本 | 
| --- | --- | --- | 
| 2024 年 11 月 20 日 | 托管扩展在 il-central-1 以色列（特拉维夫）、me-central-1 中东（阿联酋）和 ap-northeast-3 亚太地区（大阪）区域可用。 | 5.30.0 和 6.1.0 及更高版本 | 
| 2024 年 11 月 15 日 | 托管扩展在 eu-central-2 欧洲（苏黎世）区域可用。 | 5.30.0 和 6.1.0 及更高版本 | 
| 2024 年 8 月 20 日 | 节点标签现已在托管扩展中可用，您可以根据市场类型或节点类型为实例添加标签，以改善自动扩展。 | 7.2.0 及更高版本 | 
| 2024 年 3 月 31 日 | 托管扩展在 ap-south-2 亚太地区（海得拉巴）区域推出。 | 6.14.0 及更高版本 | 
| 2024 年 2 月 13 日 | 托管扩展在 eu-south-2 欧洲（西班牙）区域推出。 | 6.14.0 及更高版本 | 
| 2023 年 10 月 10 日 | 托管式自动扩缩功能已在 ap-southeast-3 亚太地区（雅加达）区域开放。 | 6.14.0 及更高版本 | 
| 2023 年 7 月 28 日 | 增强了托管扩展，以便在 Amazon EMR 在纵向扩展当前实例组的过程中遇到延迟时，可以在纵向扩展时切换到不同的任务实例组。 | 5.34.0 及更高版本，6.4.0 及更高版本 | 
| 2023 年 6 月 16 日 | 增强了托管扩展，以了解运行应用程序主节点的节点，这样这些节点就不会被缩减。有关更多信息，请参阅 [了解 Amazon EMR 节点分配策略和场景](managed-scaling-allocation-strategy.md)。 | 5.34.0 及更高版本，6.4.0 及更高版本 | 
| 2022 年 3 月 21 日 | 添加了在缩减集群时使用的 Spark 随机排序数据感知。对于启用了 Apache Spark 和托管式扩展功能的 Amazon EMR 集群，Amazon EMR 会持续监控 Spark 执行程序和中间随机排序数据位置。利用这些信息，Amazon EMR 只能缩减不包含积极使用的随机排序数据的未充分利用的实例。这可以防止重新计算丢失的随机排序数据，从而有助于降低成本和提高任务性能。有关更多信息，请参阅 [Spark Programming Guide](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations)（Spark 编程指南）。 | 5.34.0 及更高版本，6.4.0 及更高版本 | 

# 为 Amazon EMR 配置托管扩展
配置托管扩展

以下各节介绍如何启动使用托管扩展的 EMR 集群 Amazon Web Services 管理控制台 适用于 Java 的 Amazon SDK、或。 Amazon Command Line Interface

**Topics**
+ [

## 使用 Amazon Web Services 管理控制台 来配置托管扩展
](#managed-scaling-console)
+ [

## 使用 Amazon CLI 来配置托管扩展
](#managed-scaling-cli)
+ [

## 用于配置 适用于 Java 的 Amazon SDK 托管扩展
](#managed-scaling-sdk)

## 使用 Amazon Web Services 管理控制台 来配置托管扩展
Amazon Web Services 管理控制台

您可以在创建集群时使用 Amazon EMR 控制台配置托管式扩缩，也可更改正在运行的集群的托管式扩缩策略。

------
#### [ Console ]

**使用控制台创建集群时配置托管扩展**

1. [登录 Amazon Web Services 管理控制台，然后在 /emr 上打开亚马逊 EMR 控制台。https://console.aws.amazon.com](https://console.amazonaws.cn/emr)

1. 在左侧导航窗格中的 **EMR on EC2** 下，选择 **Clusters**（集群），然后选择 **Create cluster**（创建集群）。

1. 选择 Amazon EMR 发行版 **emr-5.30.0** 或更高版本（**emr-6.0.0** 版本除外）。

1. 在 **Cluster scaling and provisioning option**（集群扩展和预置选项）下，选择 **Use EMR-managed scaling**（使用 EMR 托管扩展）。指定**最小**和**最大**实例数、**最大核心节点**实例数和**最大按需型**实例数。

1. 选择适用于集群的任何其他选项。

1. 要启动集群，选择 **Create cluster**（创建集群）。

**使用控制台在现有集群上配置托管扩展**

1. [登录 Amazon Web Services 管理控制台，然后在 /emr 上打开亚马逊 EMR 控制台。https://console.aws.amazon.com](https://console.amazonaws.cn/emr)

1. 在左侧导航窗格中的 **EMR on EC2** 下，选择 **Clusters**（集群），然后选择要更新的集群。

1. 在集群详细信息页面的 **Instances**（实例）选项卡上，找到 **Instance group settings**（实例组设置）部分。选择**编辑集群扩展**，为**最小**和**最大**实例数以及**按需**限制指定新值。

------

## 使用 Amazon CLI 来配置托管扩展
Amazon Command Line Interface

创建集群时，您可以使用 Amazon EMR Amazon CLI 命令配置托管扩展。您可以使用速记语法 (可在相关命令中指定内联 JSON 配置)。也可以引用包含配置 JSON 的文件。您也可以将托管扩展策略应用于现有集群，并删除以前应用的托管扩展策略。此外，您可以从正在运行的集群中检索扩展策略配置的详细信息。

**在集群启动期间启用托管扩展**

您可以在集群启动期间启用托管扩展，如以下示例所示。

```
aws emr create-cluster \
 --service-role EMR_DefaultRole \
 --release-label emr-7.12.0 \
 --name EMR_Managed_Scaling_Enabled_Cluster \
 --applications Name=Spark Name=Hbase \
 --ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \
 --instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \
 --region us-east-1 \
 --managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}'
```

使用时，也可以使用--managed-scaling-policy 选项指定托管策略配置`create-cluster`。

**将托管扩展策略应用于现有集群**

您可以将托管扩展策略应用于现有集群，如以下示例所示。

```
aws emr put-managed-scaling-policy  
--cluster-id j-123456  
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1,
MaximumCapacityUnits=10,  MaximumOnDemandCapacityUnits=10, UnitType=Instances}'
```

也可以使用 `aws emr put-managed-scaling-policy` 命令将托管扩展策略应用于现有集群。以下示例使用对 JSON 文件 `managedscaleconfig.json` 的引用，该文件指定托管扩展策略配置。

```
aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json
```

以下示例显示 `managedscaleconfig.json` 文件的内容，该文件定义托管扩展策略。

```
{
    "ComputeLimits": {
        "UnitType": "Instances",
        "MinimumCapacityUnits": 1,
        "MaximumCapacityUnits": 10,
        "MaximumOnDemandCapacityUnits": 10
    }
}
```

**检索托管扩展策略配置**

`GetManagedScalingPolicy` 命令检索策略配置。例如，以下命令检索集群 ID 为 `j-123456` 的集群的配置。

```
aws emr get-managed-scaling-policy --cluster-id j-123456
```

该命令生成以下示例输出。

```
 1. {
 2.    "ManagedScalingPolicy": { 
 3.       "ComputeLimits": { 
 4.          "MinimumCapacityUnits": 1,
 5.          "MaximumOnDemandCapacityUnits": 10,
 6.          "MaximumCapacityUnits": 10,
 7.          "UnitType": "Instances"
 8.       }
 9.    }
10. }
```

有关在中使用 Amazon EMR 命令的更多信息 Amazon CLI，请参阅。[https://docs.amazonaws.cn/cli/latest/reference/emr](https://docs.amazonaws.cn/cli/latest/reference/emr)

**删除托管扩展策略**

`RemoveManagedScalingPolicy` 命令可删除策略配置。例如，以下命令删除集群 ID 为 `j-123456` 的集群的配置。

```
aws emr remove-managed-scaling-policy --cluster-id j-123456
```

## 用于配置 适用于 Java 的 Amazon SDK 托管扩展
适用于 Java 的 Amazon SDK

以下程序摘要说明如何使用 适用于 Java 的 Amazon SDK配置托管扩展：

```
package com.amazonaws.emr.sample;

import java.util.ArrayList;
import java.util.List;

import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.profile.ProfileCredentialsProvider;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder;
import com.amazonaws.services.elasticmapreduce.model.Application;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimits;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType;
import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig;
import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig;
import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult;

public class CreateClusterWithManagedScalingWithIG {

	public static void main(String[] args) {
		AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here");
		
		/**
		 * Create an Amazon EMR client with the credentials and region specified in order to create the cluster
		 */
		AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard()
			.withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile))
			.withRegion(Regions.US_EAST_1)
			.build();
		
		/**
		 * Create Instance Groups - Primary, Core, Task
		 */
		InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig()
				.withInstanceCount(1)
				.withInstanceRole("MASTER")
				.withInstanceType("m4.large")
				.withMarket("ON_DEMAND"); 
				
		InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig()
			.withInstanceCount(4)
			.withInstanceRole("CORE")
			.withInstanceType("m4.large")
			.withMarket("ON_DEMAND");
			
		InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig()
			.withInstanceCount(5)
			.withInstanceRole("TASK")
			.withInstanceType("m4.large")
			.withMarket("ON_DEMAND");

		List<InstanceGroupConfig> igConfigs = new ArrayList<>();
		igConfigs.add(instanceGroupConfigMaster);
		igConfigs.add(instanceGroupConfigCore);
		igConfigs.add(instanceGroupConfigTask);
		
        /**
         *  specify applications to be installed and configured when Amazon EMR creates the cluster
         */
		Application hive = new Application().withName("Hive");
		Application spark = new Application().withName("Spark");
		Application ganglia = new Application().withName("Ganglia");
		Application zeppelin = new Application().withName("Zeppelin");
		
		/** 
		 * Managed Scaling Configuration - 
         * Using UnitType=Instances for clusters composed of instance groups
		 *
         * Other options are: 
         * UnitType = VCPU ( for clusters composed of instance groups)
         * UnitType = InstanceFleetUnits ( for clusters composed of instance fleets)
         **/
		ComputeLimits computeLimits = new ComputeLimits()
				.withMinimumCapacityUnits(1)
				.withMaximumCapacityUnits(20)
				.withUnitType(ComputeLimitsUnitType.Instances);
		
		ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy();
		managedScalingPolicy.setComputeLimits(computeLimits);
		
		// create the cluster with a managed scaling policy
		RunJobFlowRequest request = new RunJobFlowRequest()
	       		.withName("EMR_Managed_Scaling_TestCluster")
	       		.withReleaseLabel("emr-7.12.0")          // Specifies the version label for the Amazon EMR release; we recommend the latest release
	       		.withApplications(hive,spark,ganglia,zeppelin)
	       		.withLogUri("s3://path/to/my/emr/logs")  // A URI in S3 for log files is required when debugging is enabled.
	       		.withServiceRole("EMR_DefaultRole")      // If you use a custom IAM service role, replace the default role with the custom role.
	       		.withJobFlowRole("EMR_EC2_DefaultRole")  // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role.
	       		.withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs)
	       	   		.withEc2SubnetId("subnet-123456789012345")
	           		.withEc2KeyName("my-ec2-key-name") 
	           		.withKeepJobFlowAliveWhenNoSteps(true))    
	       		.withManagedScalingPolicy(managedScalingPolicy);
	   RunJobFlowResult result = emr.runJobFlow(request); 
	   
	   System.out.println("The cluster ID is " + result.toString());
	}
	
	public static AWSCredentials getCredentials(String profileName) {
		// specifies any named profile in .aws/credentials as the credentials provider
		try {
			return new ProfileCredentialsProvider("AWS-Profile-Name-Here")
					.getCredentials(); 
        } catch (Exception e) {
            throw new AmazonClientException(
                    "Cannot load credentials from .aws/credentials file. " +
                    "Make sure that the credentials file exists and that the profile name is defined within it.",
                    e);
        }
	}
	
	public CreateClusterWithManagedScalingWithIG() { }
}
```

# Amazon EMR 的高级扩展
EMR 的高级扩展

从 Amazon EMR on EC2 版本 7.0 开始，您可以利用高级扩展来控制集群的资源利用率。Advanced Scaling 引入了利用率-性能量表，用于根据业务需求调整资源利用率和性能级别。您设置的值决定了您的集群是更多地考虑资源节约还是向上扩展以处理 service-level-agreement (SLA) 敏感的工作负载，其中快速完成至关重要。当调整扩展值时，托管扩展会解释您的意图并智能地进行扩展以优化资源。有关托管扩展的更多信息，请参阅[为 Amazon EMR 配置托管扩展](https://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-configure.html)。

## 高级缩放设置
高级缩放设置

您为高级扩展设置的值会根据您的需求优化集群。值范围为 **1**-**100**。可能的值为 **1**、**25**、**50**、**75** 和 **100**。如果将索引设置为除这些值之外的其他值，则会导致验证错误。

扩展值与资源利用率策略相对应。以下列表定义了其中几个：
+ **利用率优化 [1]**：此设置可防止资源过度预置。当您希望降低成本并优先考虑高效的资源利用率时，请使用较低的值。它会导致集群纵向扩展不太激进。这对于经常出现工作负载峰值并且您不希望资源增长过快的使用案例非常有效。
+ **平衡 [50]**：这可以平衡资源利用率和作业性能。此设置适用于大多数阶段都有稳定运行时的稳定工作负载。它也适用于混合了短期和长期运行阶段的工作负载。如果不确定要选择哪个设置，建议从此设置开始。
+ **性能优化 [100]** - 此策略优先考虑性能。集群会积极纵向扩展，以确保作业快速完成并达到性能目标。性能优化适用于对快速运行时间至关重要的 service-level-agreement (SLA) 敏感工作负载。

**注意**  
可用的中间值在各种策略之间提供中间地带，以便微调集群的高级扩展行为。

## 高级缩放的好处
高级缩放的好处

由于您的环境和要求存在变化（例如，更改数据量、成本目标调整和 SLA 实施等），集群扩展可以帮助您调整集群配置以实现目标。主要优势包括：
+ **增强的精细控制**：引入利用率-性能设置使您能够根据要求轻松调整集群的扩展行为。您可以根据自己的使用模式纵向扩展以满足对计算资源的需求，也可以缩减以节省资源。
+ **改善成本优化**：您可以根据要求选择低利用率值，以便更轻松地实现成本目标。

## 开始使用优化
开始使用优化

**设置和配置**

按照以下步骤设置性能指标并优化扩展策略。

1. 以下命令使用利用率优化的 `[1]` 扩展策略更新现有集群：

   ```
   aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \
    --managed-scaling-policy '{
     "ComputeLimits": {
       "UnitType": "Instances",
       "MinimumCapacityUnits": 1,
       "MaximumCapacityUnits": 2,
       "MaximumOnDemandCapacityUnits": 2,
       "MaximumCoreCapacityUnits": 2
     },
     "ScalingStrategy": "ADVANCED",
     "UtilizationPerformanceIndex": "1"
   }' \
    --region "region-name"
   ```

   属性 `ScalingStrategy` 和 `UtilizationPerformanceIndex` 是新增的，与扩展优化相关。您可以通过在托管扩展策略中为 `UtilizationPerformanceIndex` 属性设置相应的值（1、25、50、75 和 100）来选择不同的扩展策略。

1. 要恢复到默认托管扩展策略，请运行 `put-managed-scaling-policy` 命令，但不要包含 `ScalingStrategy` 和 `UtilizationPerformanceIndex` 属性。（这是可选的。） 以下示例展示了如何执行此操作：

   ```
   aws emr put-managed-scaling-policy \
   --cluster-id 'cluster-id' \
   --managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \
   --region "region-name"
   ```

**使用监控指标跟踪集群利用率**

从 EMR 版本 7.3.0 开始，Amazon EMR 发布了四个与内存和虚拟 CPU 相关的新指标。您可以使用这些指标来衡量各个扩展策略的集群利用率。这些指标适用于任何使用案例，但您可以使用此处提供的详细信息来监控高级扩展。

可用的有用指标包括：
+ **YarnContainersUsedMemoryGBSeconds**— 由 YARN 管理的应用程序消耗的内存量。
+ **YarnContainersTotalMemoryGBSeconds**— 集群内分配给 YARN 的总内存容量。
+ **YarnNodesUsedVCPUSeconds**— 由 YARN 管理的每个应用程序的 VCPU 总秒数。
+ **YarnNodesTotalVCPUSeconds**— 消耗的内存总计 VCPU 秒数，包括 yarn 未准备就绪的时间窗口。

您可以使用 Logs Insight Amazon CloudWatch s 分析资源指标。功能包括一种专门构建的查询语言，可帮助您提取与资源使用和扩展相关的指标。

以下查询可以在 Amazon CloudWatch 控制台中运行，它使用度量数学计算平均内存利用率 (e1)，方法是将消耗内存的运行总和 (e2) 除以总内存的运行总和 (e3)：

```
{
    "metrics": [
        [ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ],
        [ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ],
        [ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ],
        [ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ],
        [ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ]
    ],
    "view": "timeSeries",
    "stacked": false,
    "region": "region",
    "period": 60,
    "stat": "Sum",
    "title": "Memory Utilization"
}
```

要查询日志，可以在 Amazon 控制台 CloudWatch 中选择。有关为编写查询的更多信息 CloudWatch，请参阅 Amazon Logs 用户指南中的[使用 Lo CloudWatch gs Insights 分析 CloudWatch 日志数据](https://docs.amazonaws.cn/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)。

下图显示了示例集群的这些指标：

![\[显示利用率统计数据的图表。\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/images/scaling_graph_EMR.png)


## 注意事项和限制
注意事项和限制
+ 扩展策略的有效性可能因您的工作负载特性和集群配置而异。我们建议您尝试不同的扩展设置，以确定最适合您使用案例的索引值。
+ Amazon EMR 高级扩展尤其适用于批处理工作负载。对于 SQL/数据仓库和流式处理工作负载，我们建议使用默认托管扩展策略以获得最佳性能。
+ 在集群中启用节点标签配置时，不支持 Amazon EMR 高级扩展。如果在集群中同时启用了高级扩展和节点标签配置，则扩展行为就像启用了默认的托管扩展设置一样。
+ 性能优化型扩展策略能够比默认托管扩展策略更长时间地保持高计算资源，从而加快作业执行速度。这种模式优先考虑快速纵向扩展以满足资源需求，从而加快作业完成速度。与默认策略相比，这可能会导致成本更高。
+ 如果集群已经过优化并充分利用，启用高级扩展可能不会带来额外好处。在某些情况下，启用高级扩展可能会导致成本增加，因为工作负载可能会运行更长时间。在这些情况下，我们建议使用默认托管扩展策略，以确保最佳资源分配和成本效益。
+ 在托管扩展环境中，随着设置从性能优化 [**100**] 调整为利用率优化 [**1**]，重点从执行时间转向资源利用率。但是请务必注意，结果可能会因工作负载的性质和集群的拓扑而异。为确保您的使用案例获得最佳效果，强烈建议您使用工作负载测试扩展策略，以确定最合适的设置。
+ 仅**PerformanceUtilizationIndex**接受以下值：
  + **1**
  + **25**
  + **50**
  + **75**
  + **100**

  提交的任何其他值都会导致验证错误。

# 了解 Amazon EMR 节点分配策略和场景
节点分配策略

本部分概述了可用于 Amazon EMR 托管扩展的节点分配策略和常见扩展方案。

## 节点分配策略


Amazon EMR 托管扩展基于以下纵向扩展和缩减策略分配核心节点和任务节点：

**纵向扩展策略 **
+ 对于 Amazon EMR 7.2 及更高版本，托管扩展首先根据节点标签和应用程序进程限制 YARN 属性来添加节点。
+ 对于 Amazon EMR 7.2 及更高版本，如果启用了节点标签并将应用程序进程限制在 `CORE` 节点上，则在应用程序进程需求增加和执行程序需求增加时，Amazon EMR 托管式自动扩缩功能会增加核心节点和任务节点。同样地，如果启用了节点标签并将应用程序进程限制在 `ON_DEMAND` 节点上，则托管扩展会在应用程序进程需求增加时扩展按需型节点，并在执行程序需求增加时扩展竞价型节点。
+ 如果未启用节点标签，则应用程序进程放置不限于任何节点或市场类型。
+ 通过使用节点标签，托管扩展可在同一调整大小操作中纵向扩展和缩减不同的实例组和实例集。例如，在 `instance_group1` 具有 `ON_DEMAND` 节点和 `instance_group2` 具有 `SPOT` 节点的场景中，启用了节点标签，应用程序进程仅限于带有 `ON_DEMAND` 标签的节点。如果应用程序进程需求减少，而执行程序需求增加，则托管扩展将缩减 `instance_group1` 并纵向扩展 `instance_group2`。
+ 当 Amazon EMR 在纵向扩展当前实例组的过程中遇到延迟时，使用托管式扩展的集群会自动切换到不同的任务实例组。
+ 如果设置了 `MaximumCoreCapacityUnits` 参数，则 Amazon EMR 会扩展核心节点，直到核心单位达到所允许的最大限制。所有剩余容量都添加到任务节点。
+ 如果设置了 `MaximumOnDemandCapacityUnits` 参数，则 Amazon EMR 使用按需型实例扩展集群，直到按需型单位达到所允许的最大限制。使用竞价型实例添加所有剩余容量。
+ 如果同时设置了 `MaximumCoreCapacityUnits` 和 `MaximumOnDemandCapacityUnits` 参数，Amazon EMR 在扩展期间会考虑这两个限制。

  例如，如果 `MaximumCoreCapacityUnits` 小于 `MaximumOnDemandCapacityUnits`，Amazon EMR 首先扩展核心节点，直到达到核心容量限制。对于剩余容量，Amazon EMR 首先使用按需型实例扩展任务节点，直到达到按需型限制，然后对任务节点使用竞价型实例。

**缩减策略**
+ 与纵向扩展策略类似，Amazon EMR 会根据节点标签删除节点。有关节点标签的更多信息，请参阅[了解节点类型：主节点、核心节点和任务节点](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)。
+ 如果您尚未启用节点标签，托管扩展将删除任务节点，然后删除核心节点，直到达到所需的缩减目标容量。托管扩展绝不会将集群缩减到托管扩展策略中指定的最小限制以下。
+ Amazon EMR 版本 5.34.0 及更高版本以及 Amazon EMR 版本 6.4.0 及更高版本支持 Spark 随机排序数据感知，这可以防止实例在托管扩展感知到现有随机排序数据时缩减。有关随机排序操作的更多信息，请参阅 [Spark 编程指南](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations)。托管扩展会尽最大努力防止使用任何活跃 Spark 应用程序当前和上一阶段的随机排序数据缩减节点，最长不超过 30 分钟。这有助于最大限度地减少随机排序数据意外丢失，从而避免重新尝试作业和重新计算中间数据。但是，并不能保证防止随机排序数据丢失。为了改进 Spark 随机播放保护，我们建议对版本标签为 7.4 或更高版本的集群进行洗牌感知。在集群配置中添加以下标志，以启用改进的 Spark shuffle 保护。
  + 如果`yarn.nodemanager.shuffledata-monitor.interval-ms`标志（默认 30000 毫秒）或`spark.dynamicAllocation.executorIdleTimeout`（默认 60 秒）已更改为默认值，请`true`通过更新必要的标志来确保条件`spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms`保持不变。

    ```
    [
    	{
    		"Classification": "yarn-site",
    		"Properties": { 
    		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
    		}
    	},
    	{
    		"Classification": "spark-defaults",
    		"Properties": {
    		"spark.dynamicAllocation.enabled": "true",
    		"spark.shuffle.service.removeShuffle": "true"
    		}
    	}
    ]
    ```
+ 托管扩展首先删除任务节点，然后删除核心节点，直到达到所需的缩减目标容量。集群的扩展绝不会低于托管扩展策略中指定的最小限制。
+ 对于使用 Amazon EMR 5.x 版本 5.34.0 及更高版本以及 6.x 版本 6.4.0 及更高版本启动的集群，如果在 Apache Spark 上运行的应用程序中有活动阶段，Amazon EMR 托管扩展不会缩小`ApplicationMaster`适用于 Apache Spark 的节点。这样可以最大限度地减少任务失败和重试次数，这有助于提高作业性能并降低成本。要确认集群中哪些节点正在运行 `ApplicationMaster`，请访问 Spark 历史记录服务器，然后在 Spark 应用程序 ID 的**执行程序**选项卡下筛选驱动程序。
+ 虽然使用 EMR 托管扩展进行智能扩展可最大限度地减少 Spark 的随机排序数据丢失，但是在某些情况下，在缩减期间可能无法保护瞬态随机排序数据。为了增强缩减期间随机排序数据的弹性，建议在 YARN 中启用**随机排序数据正常停用**。在 YARN 中启用**随机排序数据正常停用**后，选择进行缩减且具有随机排序数据的节点将进入**停用**状态并继续提供随机排序文件。YARN 会 ResourceManager 等到节点报告不存在随机文件，然后再从集群中移除节点。
  + Amazon EMR 6.11.0 及更高版本支持 Tez 和 Shuffle Handlers 的 **Hive** 洗牌数据基于 Yarn 的优雅停用。 MapReduce 
    + 通过将 `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` 设置为 `true` 来启用随机排序数据正常停用。
  + 启用外部随机排序服务后（EMR on EC2 中默认启用），Amazon EMR 7.4.0 及更高版本支持基于 Yarn 的 Spark 随机排序数据正常停用。
    + 在 Yarn 上运行 Spark 时，Spark 外部随机播放服务的默认行为是 Yarn NodeManager 在应用程序终止时删除应用程序的洗牌文件。这可能会影响节点停用速度和计算利用率。对于长时间运行的应用程序，请考虑将 `spark.shuffle.service.removeShuffle` 设置为 `true` 以移除不再使用的随机排序文件，从而更快地停用没有活跃随机排序数据的节点。
  + 为了最大限度地减少 Amazon EMR 7.4.0 及更高版本中的 Spark shuffle 数据丢失，请考虑设置以下标志。
    + 如果`yarn.nodemanager.shuffledata-monitor.interval-ms`标志（默认 30000 毫秒）或`spark.dynamicAllocation.executorIdleTimeout`（默认 60 秒）已更改为默认值，请`true`通过更新必要的标志来确保条件`spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms`保持不变。

      ```
      [
      	{
      		"Classification": "yarn-site",
      		"Properties": { 
      		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
      		}
      	},
      	{
      		"Classification": "spark-defaults",
      		"Properties": {
      		"spark.dynamicAllocation.enabled": "true",
      		"spark.shuffle.service.removeShuffle": "true"
      		}
      	}
      ]
      ```

如果集群没有任何负载，Amazon EMR 将取消在之前评估中添加的新实例，并执行缩减操作 如果集群负载过重，Amazon EMR 会取消移除实例，并执行纵向扩展操作。

## 节点分配注意事项


我们建议您对核心节点使用按需型购买选项，以避免在竞价型实例回收时丢失 HDFS 数据。当更多竞价型实例添加到任务节点时，您可以使用任务节点的竞价型购买选项来降低成本并加快任务执行速度。

## 节点分配方案


您可以通过设置不同组合的最大、最小、按需限制和最大核心节点参数，根据您的需求创建各种扩展方案。

**方案 1: 仅扩展核心节点**

要仅扩展核心节点，托管式扩展参数必须满足以下要求：
+ 按需限制等于最大边界。
+ 最大核心节点等于最大边界。

当未指定按需限制和最大核心节点参数时，这两个参数都默认为最大边界。

如果您在节点标签中使用托管扩展，并将应用程序进程限制为仅在 `CORE` 节点上运行，那么这种情况就不适用，因为托管扩展会扩展任务节点以满足执行程序的需求。

以下示例仅演示了扩展核心节点的方案。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

**方案 2：仅扩展任务节点 **

要仅扩展任务节点，托管扩展参数必须满足以下要求：
+ 最大核心节点必须等于最小边界。

以下示例仅演示了扩展任务节点的方案。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

**方案 3：集群中仅有按需型实例 **

要仅拥有按需型实例，您的集群和托管扩展参数必须满足以下要求：
+ 按需限制等于最大边界。

  当未指定按需限制时，参数值默认为最大边界。默认值表示 Amazon EMR 仅扩展按需型实例。

如果最大核心节点小于最大边界，则可以使用最大核心节点参数来分配核心节点和任务节点之间的容量。

要在由实例组组成的集群中启用此方案，集群中的所有节点组必须在初始配置期间使用按需市场类型。

如果您在节点标签中使用托管扩展，并将应用程序进程限制为仅在 `ON_DEMAND` 节点上运行，那么这种情况就不适用，因为托管扩展会扩展 `Spot` 节点以满足执行程序的需求。

以下示例演示了在整个集群中使用按需型实例的方案。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

**方案 4: 集群中只有竞价型实例**

要仅拥有竞价型实例，托管扩展参数必须满足以下要求：
+ 按需限制设置为 0。

如果最大核心节点小于最大边界，则可以使用最大核心节点参数来分配核心节点和任务节点之间的容量。

要在由实例组组成的集群中启用此方案，核心实例组必须在初始配置期间使用竞价型购买选项。如果任务实例组中没有竞价型实例，则 Amazon EMR 托管扩展会在需要时使用竞价型实例创建任务组。

如果您在节点标签中使用托管扩展，并将应用程序进程限制为仅在 `ON_DEMAND` 节点上运行，那么这种情况就不适用，因为托管扩展会扩展 `ON_DEMAND` 节点以满足应用程序进程的需求。

以下示例演示了在整个集群中使用竞价型实例的方案。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

**方案 5：在核心节点上扩展按需型实例，在任务节点上扩展 Spot 实例 **

要在核心节点上扩展按需型实例和在任务节点上扩展 Spot 实例，托管扩展参数必须满足以下要求：
+ 按需限制必须等于最大核心节点。
+ 按需限制和最大核心节点必须小于最大边界。

要在由实例组组成的集群中启用此方案，核心节点组必须使用按需购买选项。

如果您在节点标签中使用托管扩展，并将应用程序进程限制为仅在 `ON_DEMAND` 节点或 `CORE` 节点上运行，那么这种情况就不适用。

以下示例演示了在核心节点上扩展按需型实例和在任务节点上扩展竞价型实例的方案。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

**场景 6：根据应用程序进程需求扩展 `CORE` 实例，根据执行程序需求扩展 `TASK` 实例。**

只有当您在节点标签中使用托管扩展，并将应用程序进程限制为仅在 `CORE` 节点上运行，这种情况才适用。

要根据应用程序进程需求扩展 `CORE` 节点，根据执行程序需求扩展 `TASK` 节点，必须在集群启动时设置以下配置：
+  `yarn.node-labels.enabled:true` 
+  `yarn.node-labels.am.default-node-label-expression: 'CORE'` 

当未指定 `ON_DEMAND` 限制和最大 `CORE` 节点参数时，这两个参数都默认为最大边界。

如果最大 `ON_DEMAND` 节点小于最大边界，托管扩展将使用最大 `ON_DEMAND` 节点参数在 `ON_DEMAND` 和 `SPOT` 节点之间拆分容量分配。如果将最大 `CORE` 节点参数设置为小于或等于最小容量参数，则 `CORE` 节点在最大核心容量下保持静态。

以下示例演示了根据应用进程需求扩展 CORE 实例和根据执行程序需求扩展 TASK 实例的场景。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

**场景 7：根据应用程序进程需求扩展 `ON_DEMAND` 实例，根据执行程序需求扩展 `SPOT` 实例。**

只有当您在节点标签中使用托管扩展，并将应用程序进程限制为仅在 `ON_DEMAND` 节点上运行，这种情况才适用。

要根据应用程序进程需求扩展 `ON_DEMAND` 节点，根据执行程序需求扩展 `SPOT` 节点，必须在集群启动时设置以下配置：
+  `yarn.node-labels.enabled:true` 
+  `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'` 

当未指定 `ON_DEMAND` 限制和最大 `CORE` 节点参数时，这两个参数都默认为最大边界。

如果最大 `CORE` 节点小于最大边界，托管扩展将使用最大 `CORE` 节点参数在 `CORE` 和 `TASK` 节点之间拆分容量分配。如果将最大 `CORE` 节点参数设置为小于或等于最小容量参数，则 `CORE` 节点在最大核心容量下保持静态。

以下示例演示了根据应用进程需求扩展按需型实例和根据执行程序需求扩展竞价型实例的场景。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)

# 了解 Amazon EMR 中的托管扩展指标
托管扩展指标

为集群启用托管扩展时，Amazon EMR 以一分钟的精细程度发布高分辨率数据指标。您可以通过 Amazon EMR 控制台或 Amazon 控制台查看由托管扩展控制的每次调整大小启动和完成的事件。 CloudWatch CloudWatch 指标对于 Amazon EMR 托管扩展的运行至关重要。我们建议您密切监控 CloudWatch 指标，确保数据不会丢失。有关如何配置 CloudWatch 警报以检测缺失指标的更多信息，请参阅[使用 Amazon CloudWatch 警报](https://docs.amazonaws.cn//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。有关在 Amazon EMR 中使用 CloudWatch 事件的更多信息，请参阅[监控 CloudWatch](https://docs.amazonaws.cn/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html)事件。

以下指标指示集群的当前容量或目标容量。仅当启用了托管扩展时，这些指标才可用。对于由实例集组成的集群，将在 `Units` 中测量集群容量指标。对于由实例组组成的集群，将根据托管扩展策略中使用的单位类型在 `Nodes` 或 `vCPU` 中测量集群容量指标。


| 指标 | 说明 | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-metrics.html)  |  集群units/nodes/vCPUs中的目标总数，由托管扩展确定。 单位：*计数*  | 
|  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-metrics.html)  |  正在运行的集群中当前units/nodes/vCPUs可用的总数。当请求集群大小调整时，将在集群中添加或删除新实例后更新此指标。 单位：*计数*  | 
|  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-metrics.html)  |  集群units/nodes/vCPUs中的目标 CORE 数量，由托管扩展确定。 单位：*计数*  | 
|  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-metrics.html)  |  集群中当前units/nodes/vCPUs运行的 CORE 数量。 单位：*计数*  | 
|  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-metrics.html)  |  集群units/nodes/vCPUs中任务的目标数量，由托管扩展决定。 单位：*计数*  | 
|  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/managed-scaling-metrics.html)  |  集群中当前units/nodes/vCPUs运行的 TASK 数量。 单位：*计数*  | 

以下指标指示集群和应用程序的使用状态。这些指标可用于所有 Amazon EMR 功能，但在为集群启用托管扩展时，将以更高的分辨率和一分钟的精细程度发布数据。您可以将以下指标与上表中的集群容量指标相关联，以了解托管扩展决策。


| 指标 | 说明 | 
| --- | --- | 
|  `AppsCompleted`  |  提交给 YARN 并且已完成的应用程序数。 使用案例：监控集群进度 单位：*计数*  | 
|  `AppsPending`  |  提交给 YARN 并且处于挂起状态的应用程序数。 使用案例：监控集群进度 单位：*计数*  | 
|  `AppsRunning`  |  提交给 YARN 并且正在运行的应用程序数。 使用案例：监控集群进度 单位：*计数*  | 
| ContainerAllocated |  分配的资源容器数量ResourceManager。 使用案例：监控集群进度 单位：*计数*  | 
|  `ContainerPending`  |  队列中尚未分配的容器数。 使用案例：监控集群进度 单位：*计数*  | 
| ContainerPendingRatio |  待处理容器与已分配容器的比率 (ContainerPendingRatio = ContainerPending / ContainerAllocated)。如果 ContainerAllocated = 0，则为 ContainerPendingRatio = ContainerPending。的值 ContainerPendingRatio 代表数字，而不是百分比。此值对基于容器分配行为扩展集群资源很有用。 单位：*计数*  | 
|  `HDFSUtilization`  |  当前使用的 HDFS 存储的百分率。 使用案例：分析集群性能 单位：*百分比*  | 
|  `IsIdle`  |  指示集群不再执行任务，但仍处于活动状态并会产生费用。如果没有任何任务和任务处于运行状态，则此指标设置为 1；否则设置为 0。系统每隔五分钟检查一次该值，值为 1 仅表示在检查时集群处于空闲状态，并不表示它整个五分钟内都处于空闲状态。为避免误报，当多次连续五分钟检查获得的值均为 1 时，您应提出警报。例如，当该值在三十分钟或更长时间内都为 1 时，您应提出警报。 使用案例：监控集群性能 单位：*布尔值*  | 
|  `MemoryAvailableMB`  |  可供分配的内存量。 使用案例：监控集群进度 单位：*计数*  | 
|  `MRActiveNodes`  |  当前正在运行 MapReduce 任务或作业的节点数量。等效于 YARN 指标 `mapred.resourcemanager.NoOfActiveNodes`。 使用案例：监控集群进度 单位：*计数*  | 
|  `YARNMemoryAvailablePercentage`  |  YARN 可用的剩余内存百分比 (YARNMemoryAvailablePercentage = MemoryAvailable MB/ MemoryTotal MB)。此值对基于 YARN 内存使用量扩展集群资源很有用。 单位：*百分比*  | 

以下指标提供有关 YARN 容器和节点所用资源的信息。YARN 资源管理器的这些指标有助于深入了解集群中运行的容器和节点所使用的资源。请将这些指标与上表中的集群容量指标进行比较，以便更清晰地了解托管扩展的影响：


| 指标 | 相关版本 | 说明 | 
| --- | --- | --- | 
|  `YarnContainersUsedMemoryGBSeconds`  |  适用于发行版标签 7.3.0 及更高版本  |  发布期间消耗的容器内存 \$1 秒数。 **单位：**GB \$1 秒  | 
|  `YarnContainersTotalMemoryGBSeconds`  |  适用于发行版标签 7.3.0 及更高版本  |  发布期间的 yarn 容器总数 \$1 秒数。 **单位：**GB \$1 秒  | 
|  `YarnContainersUsedVCPUSeconds`  |  适用于发行版标签 7.5.0 及更高版本  |  发布期间消耗的容器 VCPU \$1 秒数。 **单位：**VCPU \$1 秒  | 
| `YarnContainersTotalVCPUSeconds` | 适用于发行版标签 7.5.0 及更高版本 |  发布期间的容器 VCPU 总数 \$1 秒数。 **单位：**VCPU \$1 秒  | 
|  `YarnNodesUsedMemoryGBSeconds`  |  适用于发行版标签 7.5.0 及更高版本  |  发布期间消耗的节点内存 \$1 秒数。 **单位：**GB \$1 秒  | 
| `YarnNodesTotalMemoryGBSeconds` | 适用于发行版标签 7.5.0 及更高版本 |  发布期间的总节点内存 \$1 秒数。 **单位：**GB \$1 秒  | 
|  `YarnNodesUsedVCPUSeconds`  |  适用于发行版标签 7.3.0 及更高版本  |  发布期间消耗的节点 VCPU \$1 秒数。 **单位：**VCPU \$1 秒  | 
|  `YarnNodesTotalVCPUSeconds`  |  适用于发行版标签 7.3.0 及更高版本  |  发布期间的总节点 VCPU \$1 秒数。 **单位：**VCPU \$1 秒  | 

## 绘制托管扩展指标的图表


您可以绘制指标图表，以便直观地显示集群的工作负载模式和 Amazon EMR 托管扩展做出的相应扩展决策，如以下步骤所示。

**在 CloudWatch 控制台中绘制托管扩展指标的图表**

1. 打开 [CloudWatch 控制台](https://console.amazonaws.cn/cloudwatch/)。

1. 在导航窗格中，选择 **Amazon EMR**。您可以搜索要监控的集群的集群标识符。

1. 向下滚动到图形的指标。打开指标显示图形。

1. 要为一个或多个指标绘制图表，请选中每个指标旁边的复选框。

以下示例介绍了集群的 Amazon EMR 托管扩展活动。该图形显示三个自动缩减期，这些时段可在工作负载活动性较低时节省成本。

![\[绘制托管扩展指标的图形\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png)


所有集群容量和使用指标均以一分钟的间隔发布。其它统计信息也与每个一分钟数据相关联，这样您就可以绘制各种函数，如 `Percentiles`、`Min`、`Max`、`Sum` 、`Average`、`SampleCount`。

例如，下图以不同的百分位数 P10、P50、P90、P99 绘制同一 `YARNMemoryAvailablePercentage` 指标以及 `Sum`、`Average`、`Min`、`SampleCount`。

![\[使用不同百分位数绘制托管扩展指标的图形\]](http://docs.amazonaws.cn/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png)