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

Question

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

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

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

更新 2019-09-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在状态 enum 已经有一段时间了，但直到现在还没有被使用。所以现在我在历史选项卡中得到了关于查询状态的正确信息，但其他一切都保持不变。

此外，另一篇文章也发布了类似的问题。

Answer 1

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

\n\n

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

\n\n

您可以通过一遍又一遍地运行相同的查询来查看这一点，然后绘制随时间变化的查询执行指标，您会注意到它们变化很大，并且您会注意到查询在顶部排队的时间出现峰值。每小时 \xe2\x80\x93 当其他人都在运行他们的计划查询时。

\n