concurrency - AWS Athena 并发限制 : Number of submitted queries VS number of running queries

Question

根据 AWS Athena limitations您一次最多可以提交 20 个相同类型的查询，但这是一个软限制，可以根据要求增加。我用 boto3为了与 Athena 交互，我的脚本提交了 16 个 CTAS 查询，每个查询大约需要 2 分钟才能完成。在 AWS 账户中，只有我在使用 Athena 服务。但是，当我通过控制台查看查询状态时，我发现尽管所有查询都处于状态 Running，但实际上只有少数查询(平均 5 个)正在执行。 .以下是通常会在 Athena 历史选项卡中看到的内容:



我知道，在我向 Athena 提交查询后，它会根据整体服务负载和传入请求的数量分配资源来处理查询。但是我尝试在不同的日期和时间运行它们，仍然会同时执行大约 5 个查询。

所以我的问题是它应该如何？如果是这样，那么如果其中大约 15 个查询处于空闲状态并等待可用插槽，那么能够提交多达 20 个查询有什么意义呢？

更新 2019-09-26

刚刚在 presto 文档中偶然发现了 HIVE CONNECTOR，其中有一个部分 AWS Glue Catalog Configuration Properties .在那里我们可以看到

hive.metastore.glue.max-connections: Max number of concurrent connections to Glue (defaults to 5).

这让我想知道它是否与我的问题有关。据我了解，Athena 只是一个在 EMR 集群上运行的 Presto，该集群配置为使用 AWS Glue 数据目录作为 Metastore。

那么，如果我的问题来自这样一个事实，即 Athena 的 EMR 集群只是使用默认值来连接到 Glue 的并发连接，即 5，这正是在我的情况下实际执行(平均)并发查询的数量。

更新 2019-11-27

Athena 团队最近为 Athena 部署了许多新功能。虽然 QUEUED已经在状态 enum 有一段时间了，直到现在还没有被使用。所以现在我在历史选项卡中得到了关于查询状态的正确信息，但其他一切都保持不变。



另外， another post发布了类似的问题。

Answer 1

您帐户对 Athena 服务的限制不是 SLA，它在查询调度程序中更重要。

根据可用容量，即使您没有运行任何其他查询，您的查询也可能会排队。更高并发限制的确切含义是内部的并且可能会发生变化，但根据我的经验，最好将其视为查询调度程序处理查询的优先级。所有帐户的查询都在同一个服务器池中运行，如果每个人都在运行查询，那么您将没有任何容量可用。

您可以通过一遍又一遍地运行相同的查询来看到这一点，然后随着时间的推移绘制查询执行指标，您会注意到它们变化很大，并且您会注意到查询排队的时间高峰每小时——当其他人都在运行他们预定的查询时。