自动缩放 EMR - 是否需要？我应该只使用 EC2 吗？我应该只使用 Qubole 吗？

Question

为了减少配置时间，我们决定保留一个具有 5 个实例的专用 EMR 集群（我们预计需要大约 5 个）。如果我们需要更多，我们认为我们需要实现某种自动缩放。

我对 EMR 完全不熟悉 - 它是否支持自动缩放？我在文档中找到了这个：http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-manage-resize.html

这是寻找自动缩放的正确位置还是我误解了“调整大小”的含义。我读过 EMR 的一个好处是“按需处理”，我认为它可以在 ec2 实例之间分配负载，而无需您指定有多少实例，所以这给我的印象是它可以自行扩展 ec2 实例，这意味着我们不需要自己自动缩放。我是否误解了“按需处理”的含义？

如果我提供的调整大小链接适合我正在尝试做的事情，是否有人有确定 何时 调整大小的经验？该文档仅描述了如何而不是例如如何设置何时调整大小的警报。我使用了他们的常规自动缩放服务，它允许您根据某些条件调整大小，但我在这里没有看到。

我仍然不确定自动缩放 EMR 是否是一个坏主意 - 它是否过于复杂（因为有像 Qubole 这样的整个公司提供此功能）或者可能不是很有用，因为 EMR 已经使用了它需要的任何计算能力？我不太了解 EMR 实际提供的功能，所以也许这就是我感到困惑的原因。

Answer 1

您链接的页面显示了手动或以编程方式增加集群中节点的方法。我找不到任何关于 EMR 自动缩放的信息。

除非我们遗漏了一些事实，否则您仍然需要提出自己的缩放算法和流程。如果您考虑到诸如您的工作积压、您支付的时间单位、使用较便宜的“现货”实例、多个集群等因素，这可能不是一个简单的练习。

除了增加集群的大小之外，还需要缩小规模。 EMR 允许（手动或以编程方式）用于任务节点，但他们声明它们不用于核心节点。您必须通过 AWS 功能终止核心节点，并有丢失数据的风险。如果您的工作负载随着时间的推移而增加或减少，那么缩减核心节点大小对于降低成本将是有价值的。

Qubole 开箱即用地自动处理所有这些事情。您从 UI 或 API 运行作业，它会启动、调整集群大小或调整集群大小。完成后，它会缩小或终止集群。它还允许您同时运行最少数量的节点。我还听说 Qubole 节点的启动时间比 EMR 快得多。

希望对你有所帮助。

Answer 2

AWS 目前（截至 2016 年底）不支持开箱即用的自动扩展作为 EMR 的一部分。但是，EMR API 提供了所有必要的要素来 1) 收集监控数据，以及 2) 以编程方式向上和向下扩展集群。

基本上，有两个主要选项可以为 EMR 集群实现自动缩放：

1. Autoscaling Loop：在服务器上运行并持续监控集群当前负载的进程。性能指标（内存、CPU、I/O 等）可以定期收集并存储在数据库中。自动扩缩规则会根据性能指标进行评估，集群的任务节点会根据需要进行扩展或缩减。
2. 基于事件的自动缩放：使用 CloudWatch 指标（例如，metrics for EMR 或 metrics for EC2），您可以以编程方式定义在特定条件下触发的触发器（例如，如果所有节点的平均 CPUUtilization节点超过 80%）。

这两种选择各有利弊。选项 2 的优点是它是一种无服务器方法（不需要运行您自己的服务器）。缺点是 CloudWatch 指标是分批收集的（通常是五分钟间隔），因此数据可能会稍微延迟或不太精确。此外，基于事件的方法可能无法提供检查集群扩展的当前和历史状态所需的工具。另一方面，选项 1 确实需要服务器，但因此具有更多控制来自定义扩展规则的逻辑。此外，它还允许保留可搜索的扩展决策历史记录。

您可以查看 Themis，这是 Atlassian 开发的 EMR 自动缩放框架。 Themis 实现了上面选项 1 中讨论的自动缩放循环。当前的功能包括主动式和被动式自动缩放，它带有一个 Web UI，并且该工具非常易于配置。