如何让我的 Athena SQL 查询更快答案

【问题标题】：How can I make my Athena SQL query faster如何让我的 Athena SQL 查询更快
【发布时间】：2020-09-14 08:39:27
【问题描述】：

我在基于 PrestoDB 的 AWS Athena 上运行它。我最初的计划是查询过去 3 个月的数据以分析该数据。但是，即使是过去 2 小时的查询时间也需要 30 多分钟，此时查询超时。有没有更高效的查询方式？

SELECT column1, dt, column 2
FROM database1
WHERE date_parse(dt, '%Y%m%d%H%i%s') > CAST(now() - interval '1' hour AS timestamp)

日期列以字符串YYYYmmddhhmmss的形式记录

【问题讨论】：

您的数据文件的格式是什么？数据是否被压缩？您是否使用分区数据？这些都是可能影响 Amazon Athena 的性能（以及成本！）的重要因素。见：Analyzing Data in S3 using Amazon Athena | AWS Big Data Blog
这看起来很像由于源中的小文件而发生的问题。您能确认源中的平均文件大小吗？

标签： string datetime query-optimization where-clause presto

【解决方案1】：

问题很可能是查询在被过滤的列上应用了一个函数。这是低效的，因为数据库需要在过滤整个列之前对其进行转换。有人说这个谓词是non-SARGable。

您的主要工作应该是修复您的数据模型并将日期存储为dates 而不是字符串。

也就是说，您用来表示日期的字符串格式仍然可以使用直接过滤。思路是将过滤器值转换为目标字符串格式（而不是将列值转换为日期）：

where dt > date_format(now() - interval '1' hour, '%Y%m%d%H%i%s')

【讨论】：

在更改所有数据之前，您可以通过运行WHERE dt > '202009141000' 之类的查询来测试这是否会有所帮助。如果将字符串与静态值进行比较并不能显着加快查询速度，请不要重写所有数据。
我真正想说的是，问题不太可能是函数应用于dt 列。格式化右侧以匹配现有数据格式的建议很好，并且会有所帮助，但我怀疑它充其量只是微不足道的，Athena 的查询计划器对数据一无所知，并且没有索引，过滤是蛮力。但是，如果数据格式是 Parquet，由于谓词下推，它可能会产生很小的影响。

【解决方案2】：

有很多不同的因素会影响 Athena 执行查询所需的时间。数据量通常占主导地位，但其他重要因素是数据格式（例如 CSV 和 Parquet 之间存在巨大差异）和文件数量。与许多其他新数据库情况相比，查询的复杂性通常不是一个重要因素，而且您的查询非常简单，不是问题（在WHERE 的两侧应用一个函数没有帮助条件，但这在 Athena 中没什么大不了的，因为过滤是蛮力的，与 Athena 这样的引擎中的 IO 相比，在每一行上应用一个函数并不是什么大问题。

如果您提供有关文件数量、数据格式等的更多信息，我们可能会为您提供更好的帮助，因为如果没有这些信息，它可能只是任何事情。我的怀疑是，你有一个包含数千万或数亿个文件的前缀——这对 Athena 来说是最糟糕的情况。

当 Athena 计划查询时，它会列出表在 S3 上的位置。 S3 的列表操作的页面大小为 1000，因此如果文件多于该大小，Athena 将不得不按顺序列出，直到获得完整列表。这不能并行化，而且速度也不是很快。

您需要不惜一切代价避免在同一前缀中包含超过 1000 个文件。如果您有更多的文件，您可以添加前缀（目录），因为 Athena 会将 S3 列为文件系统，并并行化前缀列表。 table-data/a/、table-data/b/、table-data/c/ 中的每个 1000 个文件比 table-data/ 中的 3000 个文件要好得多。

我之所以怀疑它是大量小文件而不是大量数据的原因是，如果它是大量数据，您可能会这么说 - 而大量数据实际上是 Athena 真正擅长的事情。除非是十亿个小文件，否则翻录 TB 的数据是没有问题的。

【讨论】：