针对 AWS EMR 的 AWS Glue 定价

Posted 2023-02-16

【中文标题】针对 AWS EMR 的 AWS Glue 定价

【英文标题】：AWS Glue pricing against AWS EMR

【发布时间】：2018-07-17 16:22:45

【问题描述】：

我正在 AWS Glue 与 AWS EMR 之间进行一些定价比较，以便在 EMR 和 Glue 之间进行选择。

我考虑了 6 个 DPU（4 个 vCPU + 16 GB 内存），ETL 作业运行 10 分钟，持续 30 天。预期的爬虫请求被假定为比免费套餐多 100 万，对于 100 万个额外请求，按 1 美元计算。

在 EMR 上，我考虑了用于 EC2 和 EMR 的 m3.xlarge（价格分别为 0.266 美元和 0.070 美元），具有 6 个节点，运行 10 分钟，持续 30 天。

计算一个月后，我发现 AWS Glue 的计算结果约为 14.64 美元，而 EMR 计算结果约为 10.08 美元。我没有考虑其他额外费用，例如 S3、RDS、Redshift 等以及可选的 DEV Endpoint，因为我的目标是比较 ETL 工作价格收益

与 AWS Glue 相比，EMR 似乎更便宜。 EMR 定价是否正确，如果有任何遗漏，有人可以提出建议吗？我尝试了 EMR 的 AWS 价格计算器，但很困惑，不清楚是否计入了标准化小时数。

问候

尤瓦

【问题讨论】：

我不明白为什么这个问题应该被否决。 AWS 的定价非常混乱。

【参考方案1】：

是的，EMR 确实比 Glue 便宜，这是因为 Glue 是无服务器的并且完全由 AWS 管理，因此用户不必担心在后台运行的基础设施，但是 EMR需要进行大量配置才能设置。所以这是用户友好性和成本之间的权衡，对于更多技术用户来说，EMR 可能是更好的选择。

【讨论】：

谢谢，我明白了。

【参考方案2】：

@user2889316 - 你检查过我提供了比较数字的问题吗？

另请注意，一项工作的胶水大约是每小时 / DPU 0.44。我认为您不会有任何预计会全天运行的 AWS Glue JOB？您是在谈论 Glue Dev 端点还是 Job？

AWS Glue 作业至少需要 2 个 DPU 才能运行，这意味着每小时 0.88 个，我认为大约每天 21 美元？这仅适用于 GLUE 作业，还有 S3 等额外费用，以及任何数据库/连接费用/爬虫费用等。

EMR 的对应实例是 m3.xlarge，其费用为（定价分别为 0.266 美元和 0.070 美元）。对于每天 2 个实例，这大约低于 16 美元？加上其他 S3、数据库费用等。我正在考虑针对 AWS Glue 作业的默认 DPU 使用 2 个 EMR 实例。

希望这能给你一个想法。

谢谢

【参考方案3】：

如果您使用 EMR 的 Spot 实例而不是 On-Demand，它将花费按需价格的 1/3，而且会便宜得多。 AWS Glue 没有定价优势。

【讨论】：

不建议在生产环境中使用 Spot 实例。您不希望在 ETL 中途关闭服务器。 :P

如果 EMR 每天只使用 10 分钟（按照 OP 的要求），那么 Spot 实例最适合这种情况。在过去的 2 个月里，我每天使用 Spot 实例超过 5 个小时，并且从未突然断开连接。此外，还必须将 Spot 实例与按需实例一起使用，这样，如果 Spot 实例由于某种原因出现故障，该作业不会被终止并以减少的容量运行。

【参考方案4】：

如果您的基础架构不需要大幅扩展（并且大多采用固定配置），请使用 EMR。但如果需要，Glue 是更好的选择，因为它是无服务器的。只需更改 DPU，您的基础架构就可以扩展。但是在 EMR 中，您必须决定集群类型、节点数量、自动扩展规则。对于每次更改，您都需要更改集群创建脚本、对其进行测试、部署 - 基本上会增加标准发布周期的开销以进行更改。随着基础设施配置的更改，您可能需要更改 spark 配置以相应地优化作业。因此，随着基础设施配置的变化，发布新版本的时间会更长。如果添加高配置启动，成本会更高。如果添加低配置启动，则需要频繁更改脚本。

话虽如此，AWS Glue 已为每个 DPU 固定了基础设施配置 - 例如。每个核心 16GB 内存。如果您的 ETL 需要每个内核更多的内存，您可能必须转向 EMR。但是，如果您的 ETL 设计为使用 1 个执行程序时不会超过 11GB 驱动程序内存或使用 2 个执行程序时不会超过 5.5GB（例如，在新内核上并行获取额外的数据量或将卷分成 5gb/11gb 批量并运行在同一个核心上循环），Glue 是正确的选择。

如果您的 ETL 很复杂，并且所有作业都会让集群整天忙于工作，我建议您使用 EMR 并配备专门的 devops 团队来管理 EMR 基础设施。