Question

我正在编写一份后台工作来自动处理BigQuery中的A / B测试数据，并且我发现我在查询执行过程中遇到了资源超过＆＃34;＆＃34;在做大型GROUP EACH BY语句时。我从Resources Exceeded during query execution看到，减少组的数量可以使查询成功，所以我将数据分成更小的部分，但我仍然遇到错误（尽管不那么频繁）。能够更好地直观了解导致此错误的原因会更好。特别是：

资源是否超过＆＃34;总是意味着碎片耗尽内存，或者是否也意味着任务耗尽时间？
什么是正确的方法来估算内存使用情况和我可用的总内存？我是否正确假设每个分片跟踪大约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，并且查询结果在一百万个以下的组中，并且它仍然失败，超过＆＃34;资源超过＆＃34; 。减少要立即处理的时间戳的数量可以解决错误，但是我担心我最终会达到足够大的数据规模，这样整个方法就会停止工作。

Answer 1

正如您所猜测的，BigQuery根据正在操作的表的大小为GROUP EACH和JOIN EACH查询选择了许多并行工作者（分片）。这是一个粗略的启发式，但在实践中，它的效果非常好。

您的查询的有趣之处在于，由于CROSS JOIN中的扩展，GROUP EACH通过更大的表而不是原始表完成。因此，我们选择了一些太小而无法查询的分片。

回答您的具体问题：

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

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

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

1 个答案: