amazon-web-services - AWS Athena 分区获取所有路径

Question

最近，当分区数量非常多时，我遇到了 AWS Athena 问题。

旧版本的数据库和表只有 1 个分区级别，比如 id=x。我们拿一张 table ；例如，我们存储每个 id(产品)的支付参数，并且没有很多 ID。假设它在 1000-5000 左右。现在，在查询该表时，在 where 子句上传递 id 号，例如“.. where id = 10”。实际上，查询返回的速度非常快。假设我们每天更新数据两次。

最近，我们一直在考虑为一天添加另一个分区级别，例如“../id=x/dt=yyyy-mm-dd/..”。这意味着如果一个月过去了，分区数每天增长 xID 倍，如果我们有 3000 个 ID，我们每月大约会得到 3000x30=90000 个分区。因此，分区数量迅速增长。

假设 3 个月前的数据(约 270k 分区)，我们希望看到如下查询最多在 20 秒左右返回。
select count(*) from db.table where id = x and dt = 'yyyy-mm-dd'
这需要一分钟。

真实案例

事实证明，Athena 首先获取所有分区(元数据)和 s3 路径(无论使用 where 子句)，然后过滤您希望在 where 条件下查看的那些 s3 路径。第一部分(按分区获取所有 s3 路径的持续时间与分区数量成正比)

您拥有的分区越多，执行查询的速度就越慢。

直觉上，我希望 Athena 只获取 where 子句中规定的 s3 路径，我的意思是这将是分区的一种神奇方式。也许它获取所有路径

有没有人知道解决方法，或者我们是否以错误的方式使用 Athena？

Athena 是否应该仅用于少量分区？

编辑

为了澄清上述声明，我从支持邮件中添加了一段。

来自支持

... You mentioned that your new system has 360000 which is a huge number. So when you are doing select * from <partitioned table>, Athena first download all partition metadata and searched S3 path mapped with those partitions. This process of fetching data for each partition lead to longer time in query execution. ...

更新

在 AWS 论坛上打开了一个问题。在 aws 论坛上提出的链接问题是 here .

谢谢。

Answer 1

如果不知道数据量、文件格式以及我们谈论的文件数量，就不可能正确回答这个问题。

TL; DR 我怀疑您有包含数千个文件的分区，瓶颈在于列出并读取所有文件。

对于随时间增长的任何数据集，您应该根据查询模式对日期甚至时间进行时间分区。如果您应该对其他属性进行分区取决于很多因素，最终结果通常是不分区更好。不总是，但经常。

在许多情况下，使用合理大小(~100 MB)的 Parquet 比分区更有效。原因是分区增加了必须在 S3 上列出的前缀数量以及必须读取的文件数量。在许多情况下，单个 100 MB Parquet 文件比十个 10 MB 文件更有效。

当 Athena 执行查询时，它会首先从 Glue 加载分区。 Glue supports limited filtering on partitions ，并将有助于修剪分区列表 - 因此，据我所知，Athena 读取所有分区元数据是不正确的。

当它有分区时，它会发出 LIST对分区位置的操作以收集查询中涉及的文件——换句话说，Athena 不会列出每个分区位置，只会列出为查询选择的分区中的那些。这可能仍然是一个很大的数字，而这些列表操作绝对是一个瓶颈。如果一个分区中的文件超过 1000 个，情况会变得特别糟糕，因为这是 S3 列表操作的页面大小，并且必须按顺序进行多个请求。

列出所有文件后，Athena 将生成一个拆分列表，该列表可能等于也可能不等于文件列表——某些文件格式是可拆分的，如果文件足够大，它们将被并行拆分和处理。

只有在完成所有这些工作之后，才会开始实际的查询处理。根据拆分的总数和 Athena 集群中的可用容量，您的查询将被分配资源并开始执行。

如果您的数据是 Parquet 格式，并且每个分区有一个或几个文件，那么您问题中的计数查询应该在一秒钟或更短的时间内运行。 Parquet 在文件中有足够的元数据，计数查询不必读取数据，只需读取文件页脚。由于涉及多个步骤，很难让任何查询在不到一秒的时间内运行，但是命中单个分区的查询应该可以快速运行。

由于这需要两分钟，我怀疑您每个分区有数百个文件，如果不是数千个，那么您的瓶颈是在 S3 中运行所有列表和获取操作需要太多时间。