我们花了超过200美元用于测试BigQuery上的执行时间，并且每次执行时间在15秒到2分钟的交互式查询上完全相同。任何人都可以告诉我为什么会发生这种情况？
我们需要一致的执行时间来测试和优化我们的查询。有没有办法预测执行时间的一致性？我会理解执行时间差异为±10％，但差异远远超过1000％，我们无法测试或优化任何东西，因为我们的查询设置与执行时间无关，这似乎是完全随机的。我们并行运行4个查询，所有查询都在相同的数据上，结构相同（只是重命名了一些列名以禁用缓存），执行时间为：13s，27s，32s，44s。然后是20,13,24,45等等......然后在某个时刻我们运行一个查询（与上面相同）并且执行时间是400s ... WTF？
BigQuery上的销售团队也不存在购买支持包（现在请求报价几次，首先是一个月前），所以剩下的就是在这里寻求帮助。
答案 0 :(得分：2)
关于执行时间不一致，这似乎比我预期的方差更高。你能提供一个快速查询和慢查询的工作ID，这样我就可以查看内部查询统计中花费的时间吗？
尽管如此，查询时间的一些相当显着的变化，虽然不是你所看到的范围，但并不令人惊讶。以下是一些因素：
尾部潜伏期。该查询被分解为几个不同的工作者（可能有数千个，具体取决于您的数据大小）。正在从分布式文件系统集群中读取数据，这可能会使您的数据在数百个或更多磁盘上进行条带化（同样取决于表的大小）。
要响应的这些组件中最慢的一个将决定您的总查询时间。这称为尾部延迟，这意味着您必须等到落后者的长尾完成。我们做了很多工作来尽量减少影响，复制数据和重新调度工作，但它仍然会产生很大的影响。
负载。目前，当我们的群集负载很重时，它可能会减慢其他用户的响应时间。我们正在研究更好的隔离机制，但它们还有一些出路。这不会考虑您所看到的幅度的时间差异，但它可能是一个因素。
节流。当单个客户一次发送多个并行查询时，这些查询可能会变慢，以防止该客户占用太多容量。这是否发生以及是否发生这取决于许多因素，包括查询大小和群集上的其他负载。
写作结果。如果您的结果大于100k左右，写出结果可能会非常缓慢，并且可能会出现荒谬的变化。这是我们目前正在调查的错误。
正在努力减少所有这些因素的影响。然而，现在，我们没有魔术棒，我们可以挥手并说“查询性能将在20％以内”，除了说“我们认识到这个问题并正在努力改进它”。 / p>
如果您提供工作ID，我们可以查看您的查询的具体情况，以确定花费的时间以及我们可以采取哪些措施来解决问题。