在 BigQuery 之上设计 API

Posted 2023-03-24

【中文标题】在 BigQuery 之上设计 API

【英文标题】：Designing an API on top of BigQuery

【发布时间】：2015-06-13 11:21:42

【问题描述】：

我有一个 AppEngine 应用程序，可以跨多个网站跟踪用户的各种展示数据。目前，我们每月收集大约 4000 万条记录，在收集数据 6 周后，主 BigQuery 表的大小接近 15Gb，我们的估计显示，再过 6 周，我们每月将收集超过 1 亿条记录。就大数据而言，这是一个相对较小的数据集，但具有相当快的增长潜力。

现在面对成功的试验，我们需要开发一个位于 BigQuery 之上的 API，它允许我们分析数据并将结果传送到我们提供的信息中心。

我在这里担心的是，客户分析的大多数数据最多只跨越几天（每个请求），而且由于 BigQuery 查询实际上是全表扫描，API 响应时间可能会变慢，因为表变大了，BQ 需要处理更多数据才能返回结果。

因此，我的问题是这样的。我们是否应该对 BigQuery 日志表进行分片（例如按月或按周）以减少需要处理的数据，还是对数据进行预处理并将结果存储在 NDB 数据存储中是否“更明智”？这将产生一个极快的 API，但需要我们预处理所有内容，甚至是一些客户可能永远不需要的东西。

或者我可能过早地优化了？

【参考方案1】：

根据我在 BigQuery 中分析类似项目的性能的经验。如果您只关心性能，那么您无需进行任何更改。 BigQuery 的优化器可以解决很多问题，如果查询仅在几天内使用 WHERE - 性能会很好。但是从计费的角度来看，随着数据的增长，您将支付越来越多的费用，因此为了节省资金 - 按月甚至按周对数据进行分片是明智的。使用 TABLE_RANGE，您仍然可以在需要时查询所有数据，因此您不会丢失任何功能。