Presto 有多个连接器。虽然连接器确实实现了读取和写入操作，但从我阅读的所有教程来看，它们似乎通常用作仅读取的数据源。例如，netflix在 Amazon S3 上有“10 PB”的数据，他们明确声明 Presto 工作节点上没有使用磁盘（也没有 HDFS）。所述用例是“临时交互式”查询。
此外，Amazon Athena 本质上是 S3+Presto，并带有类似的用例。
我很困惑这如何在实践中起作用。显然，您不想在每个查询中读取 10 PB 的数据。所以我假设，您希望将一些以前获取的数据保留在内存中，例如数据库索引。但是，由于对数据和查询没有限制，我无法理解这如何有效。
用例 1：我经常运行相同的查询，例如在仪表板上显示指标。Presto 是否避免重新扫描已经“已知”的数据点？
用例 2：我正在分析一个大型数据集。每个查询都略有不同，但是有公共子查询或者我们过滤到数据的公共子集。Presto 是否从以前的查询中学习并结转中间结果？
或者，如果不是这种情况，是否建议我将中间结果存储在某处（例如 CREATE TABLE AS ...）？
Presto 本身没有数据缓存层。老实说，我不认为您在这里提出的功能应该由 Presto 作为 SQL 分析引擎提供。对于您提到的两个用例，我建议将 Alluxio 与 Presto 一起部署为缓存层以提供帮助：
用例 1：我经常运行相同的查询，例如在仪表板上显示指标。Presto 是否避免重新扫描已经“已知”的数据点？
作为缓存层，Alluxio 可以检测来自 Presto（或其他应用程序）的数据访问模式，并做出缓存/驱逐决策以服务内存层中最常用的数据（取决于您的配置，也可以是 SSD 或 HDD）。当数据访问不一致时，这将有所帮助。
用例 2：我正在分析一个大型数据集。每个查询都略有不同，但是有公共子查询或者我们过滤到数据的公共子集。Presto 是否从以前的查询中学习并结转中间结果？
随着对输入数据的更多了解，您可以在 Alluxio 中强制执行数据策略以（1）将数据（公共子查询）预加载到缓存空间中，（2）设置 TTL 以从 Alluxio 缓存空间中退出数据以为其他热点数据腾出空间， (3)在某些输入路径上设置缓存策略（例如，某些路径上的CACHE，其他一些路径上的NO CACHE）。
查看更多运行 Presto/Alluxio 堆栈的技巧：https ://www.alluxio.io/blog/top-5-performance-tuning-tips-for-running-presto-on-alluxio-1/
据我所知，没有中间隐式缓存层。当您在集群上使用 HDFS 时，您肯定会受益于 OS 磁盘缓存，因此下一次查询运行会更快，但您不会获得即时缓存结果。类似的数据块级缓存也可能适用于 S3。
通常，没有一个合理大小的系统可以筛选 10 PB 的数据，因为读取所有这些数据会花费大量时间。但是，可以对数据进行分区，以便 Presto 或多或少地知道需要扫描哪些数据。当分区与查询条件一致时（例如，您按数据分区数据并查询最新数据），这可以很好地工作。
当您的数据未以与查询相同的方式进行分区，并且您不想以不同的方式对其进行重新分区时，保存临时结果create table ... as select非常有意义。您还可以使用一些内存存储来存储此类临时表，例如raptor（当前未记录）或memory连接器以更快地访问。
有关分区、调整存储和查询的一些入门技巧，您可以查看https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/。
改善 Presto 查询延迟的常见优化是缓存工作集，以避免来自远程数据源或通过慢速网络的不必要 I/O。本节描述了利用 Alluxio 作为 Presto 的缓存层的以下选项。
Alluxio 文件系统将 Presto Hive 连接器作为独立的分布式缓存文件系统提供在 HDFS 或对象存储（如 AWS S3、GCP、Azure blob 存储）之上。用户可以通过文件系统接口明确了解缓存使用情况并控制缓存。例如，可以预加载 Alluxio 目录中的所有文件，为 Presto 查询预热缓存，并为缓存数据设置 TTL（生存时间）以回收缓存容量。
Alluixo 结构化数据服务通过基于 Option1 的目录和缓存文件系统与 Presto 交互。此选项在选项 1 的基础上提供了额外的好处，即无需修改 Hive Metastore 上的表位置即可无缝访问现有 Hive 表，并通过合并许多小文件或转换输入文件格式来进一步优化性能。