我已经读到 Presto 用于临时查询，而 Hive/spark 更适合 ETL 场景。在 ETL 中不使用 Presto 的原因似乎是因为 Presto 查询可能会失败并且没有中间查询容错。
但是，看起来我们可以通过在我们的日常 Jenkins 工作流程中使用 Presto 以及在查询失败时重试来解决它。 有没有人尝试过使用这种方法，或者他们对这种方法有什么缺点？
如果您在 ETL 中使用 Presto，您的 Presto 集群有多大？您将哪种 EC2 实例用于您的 presto 集群？
【问题讨论】：
如果您的 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/) 等活动中向社区成员学习。
【讨论】：