Presto有多个connectors。虽然连接器确实实现了读写操作，但在我阅读的所有教程中，似乎它们通常仅用作数据源来读取。例如，netflix在Amazon S3上有“10 PB”的数据，他们明确声明Presto工作节点上没有使用任何磁盘（也没有HDFS）。 所述用例是“临时交互式”查询。
此外，Amazon Athena本质上是S3 + Presto，并附带了类似的用例。
我很困惑这在实践中如何发挥作用。显然，您不希望在每个查询中读取10 PB的数据。所以我假设，您希望将一些先前获取的数据保留在内存中，例如数据库索引。但是，由于没有对数据和查询的限制，我无法理解这是如何有效的。
用例1：我经常运行相同的查询，例如在仪表板上显示指标。 Presto是否避免重新扫描已经“已知”的数据点？
用例2：我正在分析一个大型数据集。每个查询略有不同，但是有常见的子查询或我们过滤到数据的公共子集。 Presto是否从先前的查询中学习并结转了中间结果？
或者，如果不是这种情况，我是否会建议将中间结果存储在某处（例如CREATE TABLE AS ...）？
答案 0 :(得分：2)
Presto本身没有数据缓存层。老实说，我不认为您在此处提出的功能应该由Presto作为SQL分析引擎提供。对于您提到的两个用例，我建议将deploying Alluxio together with 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/
答案 1 :(得分：1)
据我所知，没有中间隐式缓存层。当您在群集上使用HDFS时，您肯定会受益于操作系统磁盘缓存，因此下一次查询运行会更快，但您不会获得即时缓存结果。类似的数据块级缓存也可能适用于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/。
答案 2 :(得分：0)
改善Presto查询延迟的常见优化方法是缓存工作集，以避免来自远程数据源或网络速度较慢的不必要的I / O。本节介绍以下选项，以将Alluxio用作Presto的缓存层。
Alluxio文件系统将Presto Hive Connector作为HDFS或对象存储（例如AWS S3，GCP，Azure blob存储）之上的独立分布式缓存文件系统。用户可以通过文件系统界面了解缓存的使用并明确控制缓存。例如，可以预加载Alluxio目录中的所有文件以预热Presto查询的缓存，并设置TTL（生存时间）以恢复缓存的容量。
Alluixo结构化数据服务通过目录和基于Option1的缓存文件系统与Presto进行交互。通过无缝访问现有的Hive表，而无需修改Hive Metastore上的表位置，并通过合并许多小文件或转换输入文件的格式来进一步优化性能，此选项在选项1之上还提供了其他好处。