etl - 在 ETL 场景中使用 Presto 的缺点是什么？

Question

我读过 Presto 用于临时查询，而 Hive/spark 更适用于 ETL 场景。在 ETL 中不使用 Presto 的原因似乎是因为 Presto 查询可能会失败并且没有中间查询容错。

然而，看起来我们可以通过在我们的日常 Jenkins 工作流程中使用 Presto 以及在查询失败的情况下重试来解决它。
有没有人尝试过使用这种方式，或者他们对这种方法有什么不利之处？

如果您在 ETL 中使用 Presto，那么您的 Presto 集群有多大？您的 presto 集群使用哪种 EC2 实例？

Answer 1

如果您的 ETL 作业不是很长或很复杂(即，标准 SQL 足以进行所需的转换)，我认为 Presto 可以完成合理的工作。正如您所指出的，没有中间查询容错，因此您需要一种机制来在失败时重新启动查询。希望 Presto 的速度能够抵消偶尔的重启。另一种策略是将较长的复杂查询分解为一系列较短/较简单的查询，并在两者之间创建临时表以有效实现手动检查点。 Facebook 在将一些批处理 Hive 作业迁移到 Presto 时利用了这种策略:https://www.slideshare.net/kbajda/presto-at-hadoop-summit-2016

我要提出的另一个建议是为 ETL 旋转一个单独的 Presto 集群，以避免与交互式 Presto 工作负载发生任何资源争用。

在实例类型方面，这显然取决于您的查询。大多数情况下，您需要 RAM 和 CPU 的良好平衡。从 R4 实例类型开始是一个不错的选择。在运行时观察工作负载后，您可以添加更多节点以加快 ETL 过程或探索其他实例类型(例如，如果 CPU 已满载，则转移到 C4/5 实例类型可能是一个不错的选择)。

更普遍的是，Presto-Users 邮件列表是一个很好的信息来源:https://groups.google.com/group/presto-users .
此外，还可以在 Presto 峰会 (https://www.starburstdata.com/technical-blog/presto-summit-2018-recap/) 等事件中向社区成员学习。