我读到Presto适用于特别查询，而Hive/spark更适合ETL场景。在ETL中不使用Presto的原因似乎是因为Presto查询可能会失败，并且没有中期查询容错。
然而，我们似乎可以通过在日常Jenkins工作流中使用Presto以及在查询失败的情况下重试来绕过它。有人尝试过使用这种方法吗？或者他们对这种方法有什么负面影响吗？
如果您在ETL中使用Presto，您的Presto集群有多大？您的presto集群使用哪种EC2实例？
如果ETL作业不是很长或很复杂(即，标准SQL足以满足所需的转换(，我认为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用户邮件列表是一个很好的信息来源：https://groups.google.com/group/presto-users.此外，在Presto峰会等活动中向社区成员学习(https://www.starburstdata.com/technical-blog/presto-summit-2018-recap/)。