为了减少资源调配时间，我们决定保留一个具有5个示例的专用emr集群（我们预计需要5个）。如果我们需要更多，我们认为我们需要实现某种自动缩放。
我对emr一点都不熟悉-它支持自动缩放吗？我在文件里找到这个：http://docs.aws.amazon.com/elasticmapreduce/latest/developerguide/emr-manage-resize.html
这是寻找自动缩放的正确位置还是我误解了“调整大小”的含义。我读过emr的一个好处是“按需处理”，我认为它可以在ec2示例之间分配负载，而无需指定示例的数量，因此这给我的印象是它可以自己缩放ec2示例，这意味着我们不需要自动缩放自己。我是否误解了“按需处理”的含义？
如果我提供的调整大小链接适合我正在尝试做的事情，是否有人有确定何时调整大小的经验？文档只描述了如何调整大小，但没有例如如何在调整大小时发出警报。我已经使用了他们的常规自动缩放服务，它允许您根据特定条件调整大小，但我没有看到这一点。
我仍然不确定自动缩放emr是不是一个坏主意——它是否太复杂了（因为有像qubole这样的整个公司都提供这个功能），或者可能不是很有用，因为emr已经使用了它所需要的任何计算能力？我不太清楚电子病历到底提供了什么，所以也许这就是我困惑的原因。
2条答案
按热度按时间4nkexdtk1#
aws目前（截至2016年末）不支持作为emr一部分的开箱即用自动缩放。然而，emrapi提供了所有必要的元素1）收集监控数据，2）以编程方式上下扩展集群。
基本上，有两个主要选项可以实现emr集群的自动缩放：
自动缩放循环：在服务器上运行并持续监视集群当前负载的进程。性能指标（内存、cpu、i/o等）可以定期收集并存储在数据库中。根据性能指标评估自动缩放规则，并根据需要放大或缩小集群的任务节点。
基于事件的自动缩放：使用cloudwatch度量（例如，emr的度量或ec2的度量），您可以通过编程定义在特定条件下触发的触发器（例如，如果所有节点的平均cpuutilization超过80%，则添加节点）。
两种选择各有利弊。选项2的优点是它是一种无服务器的方法（不需要运行自己的服务器）。缺点是cloudwatch度量是成批收集的（通常是5分钟的间隔），因此数据可能会稍微延迟或不太精确。另外，基于事件的方法可能无法提供检查集群扩展的当前和历史状态所需的工具。另一方面，选项1确实需要一个服务器，但因此提供了更多的控件来定制缩放规则的逻辑。此外，它还允许保留缩放决策历史的可搜索记录。
你可以看看themis，一个在atlassian开发的emr自动缩放框架。themis实现了上面选项1中讨论的自动缩放循环。当前的功能包括主动式和被动式自动缩放，它带有一个web ui，并且该工具非常易于配置。
uyto3xhc2#
您链接的页面显示了手动或编程增加集群中节点的方法。我找不到任何关于电子病历自动缩放的信息。
除非我们遗漏了一些事实，否则你还是得想出自己的缩放算法和过程。如果你考虑了一些因素，比如你的工作积压，你支付的时间单位，使用更便宜的“点”示例，多个集群等等，这可能不是一个简单的练习。
除了增加集群的规模之外，还需要缩小规模。emr允许任务节点使用这种方法（手动或编程），但它们声明核心节点不允许。您必须通过aws功能终止核心节点，并承担丢失数据的风险。如果您的工作负载随着时间的推移而增加或减少，那么核心节点的缩减对于降低成本是很有价值的。
qubole会自动处理所有这些事情。您可以从ui或api运行作业，然后启动、调整集群大小或调整集群大小。完成后，它会缩小或终止集群。它还允许您一次有最少数量的节点持续运行。我还听说qubole节点的启动时间比emr快得多。
希望这对你有帮助。