presto具有多连接器。尽管连接器确实实现了读写操作，但从我阅读的所有教程中，似乎它们通常被用作仅从中读取的数据源。例如，Netflix在Amazon S3上具有" 10 pByte"数据，他们明确指出，Presto Worker节点上没有使用磁盘（并且不使用HDFS）。规定的用例是"临时交互式"查询。
另外，亚马逊雅典娜本质上是S3 Presto，并带有类似用例。
我很困惑这在实践中如何工作。显然，您不想在每个查询上读取10 pb的数据。因此，我想，您想将一些先前获取的数据保存在内存中，例如数据库索引。但是，由于数据和查询没有任何限制，我无法理解这是如何有效的。
用例1：我经常运行相同的查询，例如在仪表板上显示公制。Presto是否避免撤销已经"已知"的数据点？
用例2：我正在分析一个大数据集。每个查询略有不同，但是有常见的子查询，或者我们过滤到数据的常见子集。普雷斯托是否从以前的查询中学习并进行中间结果？
或者，如果不是这种情况，我是否会被建议在某个地方存储中间结果（例如，创建表为...）？
Presto本身没有数据缓存层。老实说，我认为您在这里提出的功能不应该由Presto作为SQL Analytics引擎提供。对于您提到的两个用例，我建议将Alluxio与Presto一起部署为缓存层，以帮助：
用例1：我经常运行相同的查询，例如在 仪表板。Presto是否避免撤销数据点 已经"已知"？
作为缓存层，Alluxio可以从PRESTO（或其他应用程序）检测数据访问模式，并做出缓存/驱逐决策，以在内存层中使用最常用的数据（符合您的配置，可以是SSD或HDD，也）。当数据访问不一致时，这将有所帮助。
用例2：我正在分析一个大数据集。每个查询有点 不同，但是有常见的子查询，或者我们过滤到 数据的常见子集。Presto是否从以前的查询中学习？ 进行中间结果？
有了更多有关输入数据的知识，您可以在Alluxio中执行数据策略，以（1）预加载数据（常见的子查询）到缓存空间中，（2）将TTL设置为从Alluxio缓存空间中退休数据，以腾出空间热数据，（3）在某些输入路径上设置缓存策略（例如，在某些路径上缓存，在其他路径上没有缓存）。
结帐的更多提示可以运行Presto/alluxio堆栈：https：//www.alluxio.io/blog/blog/top-5-performance-tuning-tuning-tuning-tims-for-running-presto-on-an-alluxio-1/p--->
没有中间隐式缓存层。当您在群集上使用HDFS时，您肯定会从OS磁盘缓存中受益，因此下一个查询运行速度会更快，但是您将不会获得即时的缓存结果。类似的数据块级缓存也可能适用于S3。
通常，没有合理尺寸的系统可以筛选10位数据的数据，因为阅读所有数据将需要很多时间。但是，可以对数据进行分区，以便Presto知道需要扫描哪些数据或多或少。分区与查询条件保持一致（例如，您通过数据分配数据并查询最新数据），这可以很好地工作。
当您的数据不按相同的查询方式分区，并且不想以不同的方式重新分配数据时，用create table ... as select保存临时结果是很有意义的。您还可以使用一些内存存储，例如raptor（当前未记录）或memory连接器，以更快地访问。
有关分区，调整存储和查询的一些入门技巧，您可以查看https://aws.amazon.com/blogs/big-data/top-10-performance-performance-tuning-tuning-tims-for-amazon--athena/.