Presto 以前是 PrestoDB，而 Trino 以前是 PrestoSQL。
PrestoDB 于 2012 年在 Facebook 创建，直到 2019 年 1 月它们都是同一个项目。
据我所知，该项目最初是为了解决 300 PB Hive 数据仓库上的缓慢查询而创建的。还有来自 Teradata 的 Presto 发行版等等。
Trino
- 虽然 Trino 是针对多个数据源运行 ETL 查询的公司的出色解决方案，但它还提供了节省资源和收集更多输出的选项。
- Trino 还擅长允许用户使用 SQL 运行即席查询，而不管数据位于何处。它消除了将数据 ETL 到另一个系统的需要。
- Trino 允许用户创建个性化的报告和统一的仪表板，以更好地查询多个数据源。
Presto
Trino 中不存在的 Presto 功能，例如 Presto-on-Spark 看起来一直是开发重点：
- Project Aria – 非常适合处理 ORC 等文件格式。
- Project Presto Unlimited – 一种用于创建临时内存存储桶的内存节省功能。
- 其他用户定义的函数，例如动态 SQL 函数支持。
- Presto-on-Spark – Spark 执行器中的库。
差异
- Presto 已在 Facebook、Uber 和 Twitter 上大规模开发、测试和运行
- 今天的“Presto on Spark”可以运行大量批量 ETL 作业。
- Presto 的 RaptorX 提供多级缓存
- Presto 社区正在通过多个协调器而不是一个协调器节点使 Presto 更加可靠和可扩展（以防止单点故障）。
Trino 和 Presto 在架构和主要功能级别上基于事实的差异。两个项目从2019年开始分开，两者的发展和侧重点不同。如何回答以下三个问题：
- 在哪些场景中每个更有用？（或者 – 每个项目的重点是什么？）
- 两者中的任何一个都需要更多的内存资源吗？
- 对于某些用例，两者中的任何一个是否往往更快？
TL;DR：亲自尝试 Presto 和 Trino，并尝试与这两个社区进行互动。如果你想要一个黑白的答案，我的选择是 Trino。
这是我必须让您开始使用 Trino 的存储库。https://github.com/bitsondatadev/trino-getting-started
完全公开，我是 Starburst（企业 Trino）和 Trino/PrestoDB 贡献者的开发倡导者。任何有足够经验来回答这个问题的人都是有偏见的，所以我将提供一些背景和我对公正建议的最佳尝试。我还应该提到，你在那里发布的一个来源只是写关于 Presto 和 Trino 的文章，因为这是一个热门话题，他们只想获得 SEO 和页面浏览量。他们的技术与 Presto/Trino 几乎没有任何关系，他们不会检查他们写的任何东西。所以这增加了更多的混乱。我将首先回答您的问题，然后对您在上面指出的功能做出一些答复。
- 在哪些场景中每个更有用？
它们通常用于取代 Hive 作为日期湖查询引擎，以及跨多个数据源联合查询。每个人都有自拆分以来添加的功能。您在上面为 Presto 和下面指出的两个博客详细介绍了自拆分以来 Trino 中添加的内容：
https://trino.io/blog/2020/01/01/2019-summary.html
https://trino.io/blog/2021/01/08/2020-review.html
Trino 现在对高精度时间戳支持进行了重大修复，这对于金融科技、游戏和其他需要高粒度时间支持的行业非常有用。Trino 还支持高级 SQL 功能，例如Windows 上的WINDOW语法和模式匹配以及通过MATCH_RECOGNIZE. Trino 中还有更多的动态过滤 + 动态分区修剪支持，它通过在优化器中提示哪些分区确实需要包含在查询连接中来删除冗余扫描。
我从 Presto 看到的唯一一件大事是我个人觉得有趣的 Presto on Spark 作品。目前值得注意，但我还没有看到有人写过他们如何使用或当您可以直接访问 Spark 时该功能实际上有多大帮助。我认为理论上你会在 Presto 生态系统中获得容错能力，但查询长时间运行的 Spark 作业有点违背 Presto 的目的，即提供更快的交互式查询。
- 两者中的任何一个都需要更多的内存资源吗？
总的来说，这几乎是一样的。肯定会有所不同，尤其是取决于您运行的查询类型和您点击的数据源。这些项目共有6年的历史。架构中的任何一方都没有发生如此根本性的变化，以至于除了可能已明确优化的例外情况外，您将体验到内存使用方面的很大差异。
- 对于某些用例，两者中的任何一个是否往往更快？
任何人都可以争辩说他们有更好的表现，并且双方都有自己的基准表明他们更好。这是一个愚蠢的游戏，不幸的是让您感到困惑而不是帮助。对于性能问题，我始终建议您将自己与实际用例（不仅仅是 TPCH/DS）进行比较。我很乐意在这里帮助你。我能说的最好的是这两个项目都专注于加速。
Presto 在 Raptor 和这个 Spark 插件上做了很多工作。Trino 在数据湖的 Hive 和 Iceberg 连接器上投入了大量精力。如果您需要支持亚秒级延迟，Trino 还具有用于实时连接 Pinot、Druid 和 Clickhouse 的连接器。Presto 有 Pinot 和 Druid，但还没有 ClickHouse。
- 为什么我选择 Trino 并且现在是这个社区的开发者倡导者：
在之前的一家公司拆分为 PrestoDB 和 PrestoSQL/Trino 之前，我开始使用 Presto，我们决定迁移到 Trino 主要是因为 Presto 的创建者，大多数代码贡献者（来自 Qubole 和 Teradata 以及其他公司的一群人）迁移了以及。（参见：PrestoDB贡献者图|特里诺贡献者图，你会发现大量的杰出贡献者停止围绕2019年继续在特里诺）。正如您从 Trino 公告博客中的图表中看到的那样，PrestoSQL 中正在进行更多活动。
双方都添加了一些功能，但大多数添加到 PrestoDB 的功能只会使 Facebook 受益，而不是整个社区。有很多社区贡献的 PR 已经过时了，因为它们没有被优先考虑。
最后，除了仅仅因为性能而选择 Trino 之外，我敦促您加入 Trino 和 Presto slack 频道，看看那里的活动。当您需要帮助设置某些东西，或者想要找到学习资源，或者想要通过将您的用例贡献给 Trino 社区来参与其中时，您会看到与 Presto 相比，Trino 方面很热闹。当您需要启动项目时，这将使您启动并运行。