我已经阅读到Presto用于临时查询，而Hive / spark更适合ETL场景。在ETL中不使用Presto的原因似乎是因为Presto查询可能失败并且没有中间查询的容错能力。
但是，看起来我们可以通过在日常的Jenkins工作流程中使用Presto来解决此问题，并在发生查询失败时重试。 有没有人尝试过使用这种方法，或者这种方法有什么缺点？
如果您在ETL中使用Presto，那么您的Presto集群有多大？您为presto集群使用哪种EC2实例？
答案 0 :(得分：1)
假设您的ETL作业不是很长或很复杂（即标准SQL足以完成所需的转换），我认为Presto可以做得很合理。如您所指出的，查询中没有容错功能，因此您需要一种机制来在失败时重新启动查询。希望Presto的速度可以抵消偶尔的重启。另一种策略是将较长的复杂查询分为一系列较短/较简单的查询，并在两者之间创建临时表，以有效地实现手动检查点。当他们将一些Hive批作业迁移到Presto：https://www.slideshare.net/kbajda/presto-at-hadoop-summit-2016
时，Facebook就采用了这种策略。我要提出的另一项建议是为ETL旋转一个单独的Presto群集，以避免任何资源与交互式Presto工作负载争用。
就实例类型而言，它显然取决于您的查询。通常，您希望在RAM和CPU之间保持良好的平衡。从R4实例类型开始是一个不错的选择。一旦在运行时观察到工作量，就可以添加更多节点来加快ETL进程，或者探索其他实例类型（例如，如果CPU已满载，则转移到C4 / 5实例类型可能是一个不错的选择）。
通常，“ Presto用户”邮件列表是很好的信息来源：https://groups.google.com/group/presto-users。 此外，还可以在Presto Summit（https://www.starburstdata.com/technical-blog/presto-summit-2018-recap/）等活动中向社区成员学习。