AWS Athena 分区获取所有路径
AWS Athena partition fetch all paths
最近，当分区数量相当多时，我遇到了 AWS Athena 问题。
旧版本有一个数据库和 tables，只有 1 个分区级别，比如 id=x。让我们来一个table；例如，我们存储每个 ID（产品）的支付参数，并且没有足够的 ID。假设它在 1000-5000 左右。现在在查询 table 时在 where 子句上传递 id 号，如“.. where id = 10”。实际上，查询 return 编辑得非常快。假设我们每天更新两次数据。
最近，我们一直在考虑为一天添加另一个分区级别，例如“../id=x/dt=yyyy-mm-dd/..”。这意味着如果一个月过去了，分区数每天增长 xID 次，如果我们有 3000 个 ID，那么一个月大约会得到 3000x30=90000 个分区。因此，分区数量迅速增长。
比如 3 个月前的数据（~270k 分区），我们希望在最多 20 秒左右的时间内看到如下查询 return。
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.
谢谢。
如果不知道我们正在谈论的数据量、文件格式和文件数量，就不可能正确回答这个问题。
TL; DR 我怀疑你的分区有数千个文件，瓶颈是列出并读取它们。
对于任何随时间增长的数据集，您应该根据查询模式按日期甚至时间进行时间分区。如果你应该对其他属性进行分区取决于很多因素，最后往往证明不分区更好。不总是，但经常。
在许多情况下，使用合理大小（~100 MB）的 Parquet 比分区更有效。原因是分区增加了必须在 S3 上列出的前缀数量，以及必须读取的文件数量。在许多情况下，一个 100 MB 的 Parquet 文件比十个 10 MB 的文件更有效。
当 Athena 执行查询时，它将首先从 Glue 加载分区。 Glue supports limited filtering on partitions，并且会对 p运行ing 分区列表有所帮助 - 所以据我所知，Athena 读取 all 分区元数据是不正确的.
当它有分区时，它将向分区位置发出 LIST 操作以收集查询中涉及的文件——换句话说，Athena 不会列出 每个 分区位置，就是查询选择的分区中的那些。这可能还是一个很大的数字，这些列表操作肯定是一个瓶颈。如果一个分区中有超过 1000 个文件，情况会变得特别糟糕，因为这是 S3 列表操作的页面大小，并且必须顺序进行多个请求。
列出所有文件后，Athena 将生成一个拆分列表，该列表可能等于也可能不等于文件列表 – 某些文件格式是可拆分的，如果文件足够大，它们将被拆分并并行处理。
只有在完成所有这些工作后，实际的查询处理才会开始。根据拆分总数和 Athena 集群中的可用容量，您的查询将分配资源并开始执行。
如果您的数据是 Parquet 格式，并且每个分区有一个或几个文件，您问题中的计数查询应该 运行 一秒或更短。 Parquet 在文件中有足够的元数据，计数查询不必读取数据，只需读取文件页脚。由于涉及多个步骤，很难在不到一秒的时间内获得对 运行 的任何查询，但命中单个分区的查询应该 运行 很快。
因为需要两分钟，我怀疑每个分区有数百个文件，如果不是数千个，你的瓶颈是 运行 所有列表和在 S3 中获取操作需要太多时间。
最近，当分区数量相当多时，我遇到了 AWS Athena 问题。
旧版本有一个数据库和 tables，只有 1 个分区级别，比如 id=x。让我们来一个table；例如，我们存储每个 ID（产品）的支付参数，并且没有足够的 ID。假设它在 1000-5000 左右。现在在查询 table 时在 where 子句上传递 id 号，如“.. where id = 10”。实际上，查询 return 编辑得非常快。假设我们每天更新两次数据。
最近，我们一直在考虑为一天添加另一个分区级别，例如“../id=x/dt=yyyy-mm-dd/..”。这意味着如果一个月过去了，分区数每天增长 xID 次，如果我们有 3000 个 ID，那么一个月大约会得到 3000x30=90000 个分区。因此，分区数量迅速增长。
比如 3 个月前的数据（~270k 分区），我们希望在最多 20 秒左右的时间内看到如下查询 return。
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.
谢谢。
如果不知道我们正在谈论的数据量、文件格式和文件数量，就不可能正确回答这个问题。
TL; DR 我怀疑你的分区有数千个文件，瓶颈是列出并读取它们。
对于任何随时间增长的数据集，您应该根据查询模式按日期甚至时间进行时间分区。如果你应该对其他属性进行分区取决于很多因素，最后往往证明不分区更好。不总是，但经常。
在许多情况下，使用合理大小（~100 MB）的 Parquet 比分区更有效。原因是分区增加了必须在 S3 上列出的前缀数量，以及必须读取的文件数量。在许多情况下，一个 100 MB 的 Parquet 文件比十个 10 MB 的文件更有效。
当 Athena 执行查询时，它将首先从 Glue 加载分区。 Glue supports limited filtering on partitions，并且会对 p运行ing 分区列表有所帮助 - 所以据我所知，Athena 读取 all 分区元数据是不正确的.
当它有分区时，它将向分区位置发出 LIST 操作以收集查询中涉及的文件——换句话说，Athena 不会列出 每个 分区位置，就是查询选择的分区中的那些。这可能还是一个很大的数字，这些列表操作肯定是一个瓶颈。如果一个分区中有超过 1000 个文件，情况会变得特别糟糕，因为这是 S3 列表操作的页面大小，并且必须顺序进行多个请求。
列出所有文件后，Athena 将生成一个拆分列表，该列表可能等于也可能不等于文件列表 – 某些文件格式是可拆分的，如果文件足够大，它们将被拆分并并行处理。
只有在完成所有这些工作后，实际的查询处理才会开始。根据拆分总数和 Athena 集群中的可用容量，您的查询将分配资源并开始执行。
如果您的数据是 Parquet 格式，并且每个分区有一个或几个文件，您问题中的计数查询应该 运行 一秒或更短。 Parquet 在文件中有足够的元数据，计数查询不必读取数据，只需读取文件页脚。由于涉及多个步骤，很难在不到一秒的时间内获得对 运行 的任何查询，但命中单个分区的查询应该 运行 很快。
因为需要两分钟，我怀疑每个分区有数百个文件，如果不是数千个，你的瓶颈是 运行 所有列表和在 S3 中获取操作需要太多时间。