AWS Athena 并发限制：提交的查询数 VS 正在运行的查询数

Question

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

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

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

2019 年 9 月 26 日更新

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

hive.metastore.glue.max-connections：Glue 的最大并发连接数（默认为 5）。

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

那么，如果我的问题来自 Athena 的 EMR 集群只是使用默认值来与 Glue 的并发连接，即 5，这正是我实际执行的并发查询的数量（平均而言） .

2019 年 11 月 27 日更新

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

此外，another post 发布时也存在类似问题。

Answer 1

您的帐户对 Athena 服务的限制不是 SLA，而是查询调度程序中的优先级。

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

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