使用 BigQuery 中的 GROUP EACH BY 了解“查询执行期间超出的资源”答案

【问题标题】：Understanding "Resources exceeded during query execution" with GROUP EACH BY in BigQuery使用 BigQuery 中的 GROUP EACH BY 了解“查询执行期间超出的资源”
【发布时间】：2014-05-01 06:32:13
【问题描述】：

我正在编写一个后台作业来自动处理 BigQuery 中的 A/B 测试数据，并且我发现在执行大型 GROUP EACH BY 语句时我遇到了“查询执行期间超出资源”的问题。我从Resources Exceeded during query execution 看到，减少组的数量可以使查询成功，所以我将数据分成更小的部分，但我仍然遇到错误（虽然不太频繁）。如果能更好地了解究竟是什么导致了这个错误，那就太好了。特别是：

“资源超出”是否总是意味着分片内存不足，还是也意味着任务超时？
估算内存使用情况和可用总内存的正确方法是什么？我是否正确假设每个分片跟踪大约 1/n 组并保留每个组的组密钥和所有聚合，还是我应该考虑另一种方式？
分片数量如何确定？特别是，如果我在较小的数据集上进行查询，是否会获得更少的分片/资源？

有问题的查询看起来像这样（实际上，它被用作子查询，外部查询聚合结果）：

SELECT
    alternative,
    snapshot_time,
    SUM(column_1),
    ...
    SUM(column_139)
FROM
        my_table
    CROSS JOIN
        [table containing 24 unix timestamps] timestamps
WHERE last_updated_time < timestamps.snapshot_time
GROUP EACH BY alternative, user_id, snapshot_time

（这是一个失败的作业示例：124072386181:job_XF6MksqoItHNX94Z6FaKpuktGh4）

我意识到这个查询可能是自找麻烦，但在这种情况下，表只有 22MB，查询结果不到一百万个组，它仍然因“超出资源”而失败。减少一次处理的时间戳数量可以修复错误，但我担心我最终会达到足够大的数据规模，以至于这种方法作为一个整体将停止工作。

【问题讨论】：

标签： google-bigquery

【解决方案1】：

如您所料，BigQuery 会根据正在操作的表的大小为 GROUP EACH 和 JOIN EACH 查询选择多个并行工作程序（分片）。这是一个粗略的启发式方法，但在实践中，它工作得很好。

您的查询的有趣之处在于，由于 CROSS JOIN 中的扩展，GROUP EACH 是在比原始表更大的表上完成的。因此，我们选择的分片数量对于您的查询来说太小了。

回答您的具体问题：

超过资源几乎总是意味着工作人员内存不足。在 Dremel 术语中，这可能是一个分片或混合器（混合器是计算树中聚合结果的节点。GROUP EACH BY 将聚合下推到分片，即计算树的叶子）。
没有一种很好的方法可以估算可用资源的数量。这会随着时间而改变，目标是让您的更多查询正常工作。
分片数由查询中处理的总字节数决定。正如您所注意到的，这种启发式方法不适用于扩展基础数据集的连接。也就是说，我们正在进行积极的工作以更明智地选择分片的数量。为了让您了解规模，您的查询仅安排在 20 个分片上，这只是较大表的一小部分。

作为一种解决方法，您可以将 CROSS JOIN 的中间结果保存为表，并在该临时表上运行 GROUP EACH BY。这应该让 BigQuery 在选择分片数量时使用扩展的大小。（如果这不起作用，请告诉我，我们可能需要调整分配阈值）。

【讨论】：