我有 2 个完全相同的 athena 查询。但一个只选择一天，另一个选择一年。
注意：信息在 S3 存储桶上采用镶木地板格式（HIVE 分区。年/月/日/小时）。
这是基准：
QUERY 1（一天）：运行时间：1 分 5 秒，扫描的数据：13.96 MB
QUERY 2（一年）：（运行时间：1 分 19 秒，扫描的数据：49.57 MB）
如果扫描的数据量相差很大，为什么时间几乎相同？
【问题讨论】：
标签： presto amazon-athena
Athena 所基于的 Presto 是 MPP——大规模并行处理引擎。 如果扫描的数据多，则可以以更高的并行度进行扫描，这样就可以在相同的wall time内扫描更多的数据。
Presto UI（不了解 Athena）提供了如下指标：查询墙时间、查询 CPU 时间和整体并行度，这些都很好地展示了这一点。
【讨论】：
检查GetQueryExecution API 调用返回的查询统计信息（例如aws athena get-query-execution --query-execution-id ID --region REGION），这将分解这些组件的总执行时间：
QueryQueueTimeInMillis: 查询在执行前排队的时间QueryPlanningTimeInMillis：计划查询所花费的时间，包括列出 S3 上的分区EngineExecutionTimeInMillis：运行查询所花费的时间（注意，这包括 QueryPlanningTimeInMillis）ServiceProcessingTimeInMillis：将结果写入 S3 所花费的时间TotalExecutionTimeInMillis：执行查询所花费的总时间（包括上述所有时间，但并不总是完全匹配）要比较执行情况，您需要比较正确的事情。您的查询花费大致相同时间的原因可能是他们花费了大部分时间排队，或者他们在计划期间花费了大部分列表对象在 S3 上，或者他们花费了大部分时间将结果写入 S3 – 或者，就像 Piotr 所说，所有这些数字或多或少都相同，Athena 可以使用四倍于更大查询的容量，更大查询所需的额外几秒钟是在规划期间列出更多分区的开销，和/或将更大的结果写入 S3。
【讨论】：
由于您使用的是年/月/日/小时分区，您可能有数千个分区。在这种情况下，如果您的分区不使用 string 数据类型，Athena 会在@Theo 提到的QueryPlanningTimeInMillis 步骤中浪费大量时间。
这是因为当您为分区列使用除 string 之外的任何数据类型时，Athena 会在服务器端修剪分区（这需要很长时间）。
为了使您的查询更加高效，请对所有分区列使用 string 数据类型（即使它们在技术上是整数）。这样，Athena 会在 Metastore 级别修剪分区，从而减少开销并防止查询超时。
来源：Considerations and Limitations for SQL Queries in Amazon Athena (AWS Docs)
【讨论】：