BigQuery 中消耗的时隙时间

Posted 2023-03-24

【中文标题】BigQuery 中消耗的时隙时间

【英文标题】：Slot time consumed in BigQuery

【发布时间】：2020-09-29 18:44:30

【问题描述】：

我运行了一个查询，结果如下。

经过时间：12.1 秒

插槽时间消耗：14 小时 12 分钟

total_slot_ms：51147110（即 14 小时 12 分钟）

我们采用按需定价计划。所以最大插槽数为 2000。话虽如此，如果我在整个 12.1 秒的跨度内使用了 2000 个插槽，那么我最终的 total_slot_ms 应该为 24200000 （即 2000x12.1x1000强>）。但是，total_slot_ms 为 51147110。使用的平均插槽数为 51147110/121000 = 4225（远高于 2000）。有人可以向我解释一下我是如何使用超过 2000 个插槽的吗？

【参考方案1】：

增加 Bigquery 槽容量可显着提高整体查询性能，尽管槽量实际上是 Bigquery on-demand 定价计划中 Quotas 限制的主题，超过槽量限制不会向您收取额外费用：

BigQuery 槽在单个项目中的所有查询之间共享。 BigQuery 可能会超出此限制以加速您的查询。

要查看您正在使用的插槽数量，请参阅Monitoring BigQuery using Cloud Monitoring。

【参考方案2】：

BigQuery 按需支持有限突发。 https://cloud.google.com/bigquery/docs/release-notes#December_10_2019

【参考方案3】：

您可能想要检查查询的执行计划并了解每个阶段的等待、读取、写入活动的所有不同 slot_time_ms。由于这是按需时段，您可能会看到很多等待时间，这将加起来总时间。 除了burst之外，explain pan的每个阶段都会帮助你理解总时间不一定是实际slot消耗，而是等效slot消耗。

【参考方案4】：

在 Google 的课程中​​，有一个查询显示 13 个“经过的时间”秒和 50 分钟的“插槽时间消耗”的示例。他们说：

嘿，在我们所有的工作人员中，我们基本上并行完成了 50 分钟的大规模工作，50 分钟，以便您的查询可以在 13 秒内返回。对您来说最重要的是，您无需担心启动这些工作人员、在他们之间移动数据、确保他们在聚合之间共享所有结果。您所关心的只是编写 SQL，找到洞察力，然后以非常快的速度运行该查询。但是从你那里抽象出很多正在发生的分布式并行处理。

【讨论】：

您的答案可以通过额外的支持信息得到改进。请edit 添加更多详细信息，例如引用或文档，以便其他人可以确认您的答案是正确的。你可以找到更多关于如何写好答案的信息in the help center。