亚马逊AWS官方博客

通过 Amazon EMR 重新配置动态修改集群

Original URL: https://aws.amazon.com/blogs/big-data/modifying-your-cluster-on-the-fly-with-amazon-emr-reconfiguration/
如果您是使用长期运行的 Amazon EMR 集群的开发人员或数据科学家,您将面临快速变化的工作负载。这些变化通常需要不同的应用程序配置才能在集群上以最佳方式运行。

通过重新配置功能,现在可以更改正在运行的 EMR 集群上的配置。从 EMR 版本 emr-5.21.0 开始,该功能允许您在不创建新集群或通过 SSH 手动连接到每个节点的情况下修改配置。在这篇文章中,我将讨论以下主题:

  • 使用重新配置
  • 实例组状态、配置版本和事件
  • 重新配置示例用例
  • 重新配置的优点

使用重新配置

EMR 版本 emr-5.21.0 中更新了下列任务:

  • 提交重新配置
  • 修改配置
  • 定义配置级别

提交重新配置

您可以通过 EMR 控制台、SDK 或 AWS CLI 提交重新配置。有关更多信息,请参见提交重新配置其他信息

修改配置

提交重新配置时,必须包含要应用于集群的所有配置。更新仅应用这些项目,删除所有其他项目。在修改配置时,EMR 控制台还将为您跟踪以前的集群配置。

定义配置级别

为应用程序定义集群级别和实例组级别配置。在创建集群时提供集群级别配置。然后,这些配置将自动应用于所有实例组,甚至是在集群启动并运行后添加的实例组。配置启动后,将无法修改集群级别配置。但您可以通过重新配置请求在实例组级别补充或覆盖这些配置。每当提交实例组的重新配置请求时,这些新的实例组级别配置将优先于继承的集群级别配置。

要更好地了解集群级别和实例组级别配置如何在实例组上协同工作,请查看 EMR 控制台中的简单演示:

配置选项卡下,从筛选器下拉列表中选择一个实例组。导航到所需实例组的配置表。配置表的列指示了配置的级别。

此集群以集群级别配置集开头:

[
{
"Classification": "core-site",
"Properties": {
"Key-A": "Value-1",
"Key-B": "Value-2"
}
}
]

正如您在控制台中看到的,实例组 ig-Y4E3MN8C4YBP 自动继承了集群级别配置集。现在,重新配置实例组,如下所示:

[
{
"Classification": "core-site",
"Properties": {
"Key-A": "Value-a",
"Key-C": "Value-3"
}
}
]

一旦请求通过,配置“Key-A”的值将被实例组级别配置覆盖,从“Value-1”变为“Value-a”。  相反,配置“Key-B”的值保持不变。同时,您的请求引入了新的补充配置“Key-C”。 控制台中的配置表将始终显示这些细微的变化。

有关如何自定义群集级别和实例组级别配置的详细信息,请参阅创建群集时提供配置

实例组状态、配置版本和事件

重新配置请求的状态显示在实例组状态转换、配置版本增加和 CloudWatch 事件中。了解它们如何防止丢失任何重新配置请求:

  • 实例组状态:实例组收到重新配置请求后,它将从 RUNNING 状态转换为 RECONFIGURING 状态。RECONFIGURING 状态指示重新配置过程开始。该过程完成且新配置生效后,实例组将返回 RUNNING 状态。然后,您可以通过应用程序的 Web UI 或特定于应用程序的命令验证配置。
  • 配置版本:您提交的每个重新配置请求都会创建新的配置集,并以新版本号进行区分。配置版本从 0 开始,您提交的每个新配置集分别加 1。每个实例组都保留其各自的配置版本号。版本号会随着您重新配置不同实例组的次数而增加。
  • 事件:EMR 将每个重新配置请求的状态作为 Amazon CloudWatch 事件发布。这些事件列出了何时提交请求、重新配置操作何时启动以及何时完成的确切时间。为便于跟踪,每个请求与其关联的配置版本一起发布。 例如,以下事件流显示了 EMR 如何执行实例组中的典型重新配置请求:

有关重新配置操作的 EMR 事件和实例组状态转换的完整列表,请参阅 EMR 管理指南

重新配置示例用例

以下是重新配置操作的一些用例示例:

  • 重新配置 HDFS 块大小
  • 配置容量调度程序队列

重新配置 HDFS 块大小

您可能要应对不断变化的工作负载。这些更改可在集群的整个生命周期内调用新的应用程序配置。

例如,假设您最近看到长时间运行的集群的工作负载和文件大小增加。您希望在不替换当前集群的情况下考虑增加。

要增加 HDFS 块大小以提高性能,请利用新的重新配置功能。HDFS NameNode 会跟踪集群中的每个数据块。增加此数据块的大小可通过减少 NameNode 监视的数据块数来提高 HDFS 性能。此外,该功能还可通过减少所需映射器的数量来提高作业性能。

要将 HDFS 块大小从默认的 128 GB 增加到 256 GB,请向主实例组提交重新配置请求,该实例组运行相同的节点:

$ aws emr modify-instance-groups --cli-input-json file://reconfiguration.json

以下是 reconfiguration.json 文件示例。

reconfiguration.json:
{
"ClusterId": "j-MyClusterID",
"InstanceGroups": [
{
"InstanceGroupId": "ig-MyMasterId",
"Configurations": [
{
"Classification": "hdfs-site",
"Properties": {
"dfs.blocksize": "256m"
},
"Configurations": []
}]
}]
}

然后,EMR 重新配置过程将“dfs.blocksize”参数修改为 hdfs-size.xml 文件中提供的值“256 m”。该重新配置过程还将自动重启 NameNode 以获取新配置。添加到集群的任何新数据块都将自动使用新的默认块大小 256 MB。如果您希望任何现有数据块获取此默认值,请按照下列步骤操作:

  1. 将数据块复制到新的位置。
  2. 删除原数据块。
  3. 将数据块复制回原始位置。

恢复的数据块将获取新的默认块大小。NameNode 在短暂的重启期间处于非活动状态。

配置容量调度程序队列

是否要更改不同 Hadoop 作业之间的集群资源共享策略? 修改正在运行的集群上的 YARN CapacityScheduler 配置? 在您与其他组织共同管理的大型共享集群上添加新队列? 更改不同队列之间的容量分配以满足不断变化的工作负载?

使用 EMR 重新配置功能,您可以通过向主节点提交重新配置请求来进行更改。新配置会在几分钟内在您的队列上生效。这省去了登录到主节点、直接更新配置文件或手动刷新队列的麻烦。

默认情况下,EMR 集群含有单个队列。 要创建两个额外的队列 alpha 和 beta,并将集群总资源容量的 30% 分配给每个队列。以下是提交重新配置请求以完成所需更改的样本命令:

$ aws emr modify-instance-groups --cli-input-json file://reconfiguration.json

以下是 reconfiguration.json 文件示例。

reconfiguration.json:
{
"ClusterId":"j-MyClusterID",
"InstanceGroups":[
{
"InstanceGroupId":"ig-MyMasterId",
"Configurations":[
{
"Classification":"capacity-scheduler",
"Properties":{
"yarn.scheduler.capacity.root.queues":"default,alpha,beta",
"yarn.scheduler.capacity.root.default.capacity":"40",
"yarn.scheduler.capacity.root.default.accessible-node-labels.CORE.capacity":"40",
"yarn.scheduler.capacity.root.alpha.capacity":"30",
"yarn.scheduler.capacity.root.alpha.accessible-node-labels":"*",
"yarn.scheduler.capacity.root.alpha.accessible-node-labels.CORE.capacity":"30",
"yarn.scheduler.capacity.root.beta.capacity":"30",
"yarn.scheduler.capacity.root.beta.accessible-node-labels":"*",
"yarn.scheduler.capacity.root.beta.accessible-node-labels.CORE.capacity":"30"
},
"Configurations":[]
}
]
}
]
}

对两个队列都提供了对“*”标签的访问权限,以便每个队列都可以访问标注的核心节点。此外,所有队列的容量总和必须等于 100。默认队列的容量减少到 40%。

最后,每个队列对核心标签的访问容量与队列本身的容量相匹配。这意味着核心分区以与集群其余部分相同的比率在队列之间拆分。

完成此步骤后,转到 YARN ResourceManager Web UI 以验证修改是否生效。

EMR 重新配置的优点

以下是 EMR 重新配置的优点:

  • 重新配置是个滚动过程
  • 重新配置故障和恢复

重新配置滚动过程

EMR 重新配置的一个主要优点是滚动重新配置过程。摘自文档:

“Amazon EMR 遵循’滚动’流程来重新配置 Task 和 Core 实例组中的实例。实例组中只有 10% 的实例是一次性修改和重启的。该过程需要更长时间才能完成,但会降低正在运行的集群中发生应用程序故障的可能性。”

滚动重新配置允许 90% 的核心节点在重新配置期间保持运行,从而防止任何 HDFS 停机。YARN on EMR 还启用了 NodeManager 恢复。NodeManager 将恢复重新配置重启后运行的容器。

由于容器始终处于活动状态,因此某些 MapReduce 作业可以在重新配置过程中继续成功运行。但并非所有应用程序都可以在重启后恢复。例如,Spark on YARN(EMR 默认值)可能会在 NodeManager 重启后遇到执行程序问题和作业故障。

在生产环境中重新配置之前,使用您计划在安全环境中执行的重新配置类型来测试应用程序。

最后,滚动重新配置过程可能导致实例组的配置状态暂时不匹配。虽然不匹配,但某些实例仍可能含有旧配置,而其他实例可能具有新请求的配置。重新配置集群时,请考虑此情况可能产生的任何副作用。

重新配置故障和恢复

EMR 还可以从重新配置故障中恢复您的实例组。

为使新配置生效,EMR 会重启重新配置的应用程序,并确保它们在声明重新配置操作完成之前正在运行。

但如果任何应用程序无法在任何节点上成功重启,重新配置操作将会失败,而实例组仍将处于 RECONFIGURING 状态。这类故障可能是由于有问题的配置值造成的。例如,无效的地址“yarn.resourcemanager.scheduler.address”可能导致 YARN ResourceManager 无法重启。

在此种情况下,EMR 会自动触发配置恢复。恢复将重新应用实例组上先前的工作配置集。恢复完成后,实例组状态将恢复为 RUNNING 状态。因此,实例组将返回运行状态,并保持应用程序在集群上的可用性。滚动重新配置持续整个过程。

如果在重新应用先前的工作配置后应用程序仍无法启动,则 EMR 会将实例组置于 te ARRESTED 状态,而不是进一步尝试重新配置。要从 ARRESTED 状态释放实例组,请提交新的重新配置请求。

小结

在这篇文章中,我为大家讲解了如何使用新的 EMR 集群重新配置功能在运行的集群上配置实例组的基础知识。我还详细介绍了提交重新配置请求的额外语义、重要的配置级别概念以及重新配置跟踪方法的方式。我列举了几个真实的重新配置示例,并介绍了两个有用的重新配置功能。

试用新的集群重新配置功能,并在下面的评论中与我们分享您的体验!

 


关于作者

Brandon Scheller 是 Amazon EMR 的一名软件开发工程师。他热衷于开发和推进 Hadoop 生态系统的应用程序以及与开源社区的合作。闲暇时,他喜欢在喀斯喀特山脉登山。

 

 

 

Junyang Li 是 Amazon EMR 的一名软件开发工程师。 她致力于开发 EMR 的前沿功能,并参与开源项目。工作之余,她还喜欢艺术和手工艺品、健身和旅行。