Athena Athena扫描的数据量不同但响应时间相同

问题描述

我有2个完全相同的雅典娜查询。但一个只选择一天，另一个选择一年。

注意：该信息为S3存储桶上的实木复合地板格式（HIVE分区。年/月/日/小时）。

这是基准：

查询1（一天）：运行时间：1分钟5秒，扫描数据：13.96 MB

查询2（一年）：（运行时间：1分19秒，扫描的数据：49.57 MB）

如果扫描的数据量相差很大，为什么时间几乎相同？

解决方法

Athena所基于的

Presto是MPP-大规模并行处理引擎。 如果要扫描的数据更多，则可以以更高的并行度进行扫描，因此您可以在同一时间内扫描更多的数据。

Presto UI（不了解Athena）提供的指标包括：查询墙时间，查询CPU时间和总体并行性，很好地显示了这一点。

,

由于您使用年/月/日/小时分区，您可能有数千个分区。在这种情况下，如果您的分区不使用 string 数据类型，Athena 会在@Theo 提到的 QueryPlanningTimeInMillis 步骤中浪费大量时间。

发生这种情况是因为当您为分区列使用除 string 之外的任何数据类型时，Athena 会在服务器端修剪分区（这需要大量时间）。

为了使您的查询更加高效，请对所有分区列使用 string 数据类型（即使它们在技术上是整数）。这样，Athena 会在 Metastore 级别修剪分区 - 从而减少开销并防止查询超时。

来源：Considerations and Limitations for SQL Queries in Amazon Athena (AWS Docs)

,

检查由GetQueryExecution API调用（例如aws athena get-query-execution --query-execution-id ID --region REGION）返回的查询统计信息，这将分解以下组件的总执行时间：

• QueryQueueTimeInMillis：查询在执行之前排队的时间
• QueryPlanningTimeInMillis：计划查询所花费的时间，包括列出S3上的分区
• EngineExecutionTimeInMillis：运行查询所花费的时间（N.B.包括QueryPlanningTimeInMillis）
• ServiceProcessingTimeInMillis：将结果写入S3的时间
• TotalExecutionTimeInMillis：执行查询所花费的总时间（包括以上所有内容，但并不总是完全匹配）

要比较执行，您需要比较正确的东西。您的查询花费大致相同时间的原因可能是由于他们花费了大部分时间排队，或者他们在计划期间花费了大部分清单对象在S3上，或者他们花费了大部分时间将结果写入S3 –或像Piotr所说的那样，所有这些数字或多或少都是相同的，而Athena可能会使用四倍于较大查询的容量，而较大查询所需的额外几秒钟是计划期间列出更多分区的开销和/或将更大的结果写入S3。