AWS Athena 并发限制：提交的查询数与 运行 查询数
AWS Athena concurrency limits: Number of submitted queries VS number of running queries
根据AWS Athena limitations，您一次最多可以提交 20 个相同类型的查询，但这是一个软限制，可以根据要求增加。我使用 boto3 与 Athena 交互，我的脚本提交了 16 个 CTAS 查询，每个查询大约需要 2 分钟才能完成。在 AWS 账户中，只有我在使用 Athena 服务。但是，当我通过控制台查看查询状态时，我发现实际上只有少数查询（平均 5 个）在执行，尽管它们都处于 Running 状态。以下是 Athena hisotry 选项卡中通常会看到的内容：
我了解到，在我向 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 已经在状态枚举中存在了一段时间，但直到现在才被使用。所以现在我得到了历史选项卡中有关查询状态的正确信息，但其他一切都保持不变。
此外，another post 也出现了类似的问题。
您的帐户对 Athena 服务的限制不是 SLA，它更像是查询调度程序中的优先级。
根据可用容量，您的查询可能会排队，即使您没有 运行任何其他查询。更高的并发限制究竟意味着什么是内部的并且可能会改变，但根据我的经验，最好将其视为查询调度程序处理您的查询的优先级。查询同一服务器池中的所有帐户 运行，如果每个人都在 运行 查询，那么您将没有任何容量。
您可以通过 运行 一遍又一遍地执行相同的查询，然后随时间绘制查询执行指标，您会发现它们的变化很大，并且您会注意到峰值您的查询排在每小时最前面的时间 – 当其他人都在 运行 安排他们的查询时。
根据AWS Athena limitations，您一次最多可以提交 20 个相同类型的查询，但这是一个软限制，可以根据要求增加。我使用 boto3 与 Athena 交互，我的脚本提交了 16 个 CTAS 查询，每个查询大约需要 2 分钟才能完成。在 AWS 账户中，只有我在使用 Athena 服务。但是，当我通过控制台查看查询状态时，我发现实际上只有少数查询（平均 5 个）在执行，尽管它们都处于 Running 状态。以下是 Athena hisotry 选项卡中通常会看到的内容：
我了解到，在我向 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 已经在状态枚举中存在了一段时间，但直到现在才被使用。所以现在我得到了历史选项卡中有关查询状态的正确信息，但其他一切都保持不变。
此外，another post 也出现了类似的问题。
您的帐户对 Athena 服务的限制不是 SLA，它更像是查询调度程序中的优先级。
根据可用容量，您的查询可能会排队，即使您没有 运行任何其他查询。更高的并发限制究竟意味着什么是内部的并且可能会改变，但根据我的经验，最好将其视为查询调度程序处理您的查询的优先级。查询同一服务器池中的所有帐户 运行，如果每个人都在 运行 查询，那么您将没有任何容量。
您可以通过 运行 一遍又一遍地执行相同的查询，然后随时间绘制查询执行指标，您会发现它们的变化很大，并且您会注意到峰值您的查询排在每小时最前面的时间 – 当其他人都在 运行 安排他们的查询时。