自 2016 年 2 月 19 日以来，BigQuery 交互式查询响应时间下降

Posted 2023-03-24

【中文标题】自 2016 年 2 月 19 日以来，BigQuery 交互式查询响应时间下降

【英文标题】：BigQuery interactive query response times degradation since 2/19/16

【发布时间】：2016-02-22 19:14:15

【问题描述】：

对于 Google BigQuery 基础架构人员：我们已经运行了几个月的一组短期交互式查询，现在平均大约需要 5 秒才能完成。从 19 年 2 月 2 日星期五开始，这些响应时间一直在稳步上升（SQL 没有改变，我们正在处理使用滑动窗口查询的稳定数据流）

这是您知道的全球 BigQuery 问题吗？

编辑：更精细的响应时间：

【问题讨论】：

请提供运行时间超过预期的作业的作业 ID。没有我们所知道的全局 bigquery 问题。 （理想情况下，如果您还可以提供快速运行的作业的作业 ID，那也会很有帮助）

这里的一个短的（相对）短的一个。SOobGfn97JIaLKyeeu5tDFgT4G3maBgs26xO3fm0Xp2wDMFjy7yJFryFCWQkTOEI96mWFij1ZSbj4d7gOKByCb1cB8ZLqdZcfPG8rZh5QSCYGLaqBLKhyI0weIL0YkenbKHYKRYYQRfoiLVHGuG9oBDfn8VprJH61aC0AcbLeL_xZmyX8UXtio0gMjNnY4BFsxpEHbKHyJyxW984grv1NedH94krsC3d1_esrPIKz5c58L5MZzQn4iq9VL3VjOQz（25秒）和一个长一个j2JaIDT9yw3bjI3MskbidDnSdKeZX4KM_IXYPY34_iWQogzSvYjT5U9NxAy8EakTIsLp6ODW0pkevmcVNTaVvGoDZb9GlEIEK0LOlJEyp103Y3nrHIwWFW7b5CzqMs9UVkGa3PTXIIeWY136mJiyeI29yuhFkvZumDNjQ2LBeFezAb1jcKlEAf6WiV7GaWVpqeP8_PgVFv2sHfL0RC9wyJe9dXg98osJ5PmWSDge5VdXbwsAb5LV04M1b6JlQA7h（3分钟，13秒）跨度>

以上都处理了大约 2.7 MB。我们每天（一天）开始大约 19K 次，并且有点依赖这些在 5 秒内完成。这些在 40/s App Engine 队列中汇集，以保持在 50/s 运行查询限制内。随着这些增加，队列填满并开始出现延误。

【参考方案1】：

有好消息也有坏消息；好消息是查询只需要 0.5 秒即可执行。坏消息是找到存储数据的文件需要 191 秒。

我们有几个性能回归导致解析路径的尾部延迟较高。数据存储在许多路径中的表（如您的表）的性能会更差。

您使用时间范围装饰器会加剧性能问题，这意味着我们优化文件布局的努力效果不佳。

我们今天下午开始推出对潜在性能问题的修复；它可能需要至少一周的时间才能在所有地方生效。完成后我会更新这个答案（如果我忘记了，请提醒我）

与此同时，您可以通过从查询中删除时间范围装饰器来获得更快的结果。您已经按时间过滤，因此查询应该仍然正确。当然，这可能意味着查询的运行成本更高。

【讨论】：

感谢您调查这个 Jordan，我会拿出装饰器，直到您批准为止。

自美国东部标准时间凌晨 1:30 起，我们的响应时间又回到了 4 - 5 秒的范围内。

Jordan：关于您对我们的表的数据存储在许多路径中的评论的一个问题：这是指 TABLE_QUERY 用法、联合还是左外连接？

这是由于 bigquery 表在内部的存储方式。如果您进行大量小型导入，它们将被单独放入单独的文件中，直到它们稍后被优化（并且流式导入也会生成小文件）。如果你使用时间范围装饰器，这意味着我们不能使用优化版本。但是 TABLE_QUERY 也可能最终读取很多小表，所以你会遇到同样的问题。

谢谢，是的，这些表都由流式导入填充。