BigQuery 检索时间慢

Question

BigQuery 处理大型数据集的速度很快，但从 BigQuery 检索大型结果却一点也不快。

例如，我运行了一个查询，该查询通过三个 HTTP 请求返回 211,136 行，总共只用了 12 多秒。
查询本身是从缓存中返回的，因此没有时间花在执行查询上。主机服务器是在美国东部（弗吉尼亚）运行的 Amazon m4.xlarge。

在生产中，我发现这个过程在返回约 100 万行时需要约 90 秒。显然，其中一些可能是由于网络流量造成的……但它似乎太慢了，不能成为唯一的原因（那 211,136 行只有 ~1.7MB）。

有没有其他人在返回结果的时候遇到速度这么慢，并找到了解决办法？

---

更新：在 Google Cloud 内的 VM 上重新进行测试，结果非常相似。排除 Google 和 AWS 之间的网络问题。

Answer 1

使用 TableData.List 的并发请求

这不是很好，但有一个解决方案。

进行查询，并将最大行数设置为 1000。如果没有页面标记，则直接返回结果。

如果有页面令牌，则忽略结果*，并使用 TableData.List API。但是，不要简单地一次发送一个请求，而是为结果中的每 10,000 条记录发送一个请求*。为此，可以使用“MaxResults”和“StartIndex”字段。 （请注意，即使是这些较小的页面也可能被分解为多个请求*，因此仍然需要分页逻辑。

这种并发（和更小的页面）导致检索时间显着减少。不如 BigQ 简单地流式传输所有结果，但足以开始实现使用 BigQ 的收益。

潜在缺陷：密切关注请求数，因为对于较大的结果集，可能会出现 100req/s 的限制。还值得注意的是，无法保证排序，因此使用 StartIndex 字段作为伪分页可能并不总是返回正确的结果*。

* 任何带有单个星号的内容仍然是有根据的猜测，但未确认为真实/最佳实践。

Answer 2

我们在这个 API 上的 SLO 是 32 秒，调用需要 12 秒是正常的。 90 秒听起来太长了，它一定会达到我们系统的一些尾部延迟。

我知道它慢得令人尴尬。这有多种原因，我们正在努力改善此 API 的延迟。到明年第一季度末，我们应该能够推出一项更改，将 tabledata.list 时间减少一半（通过将 API 前端升级到我们新的 One Platform 技术）。如果我们有更多的资源，我们也会让 jobs.getQueryResults 更快。