google-bigquery - 在BigQuery中使用GROUP EACH BY了解 "Resources exceeded during query execution"

Question

我正在写一个后台作业来自动处理BigQuery中的A/B测试数据，并且发现在执行大型GROUP EACH BY语句时遇到“查询执行期间超出资源”的情况。从Resources Exceeded during query execution中我看到减少组的数量可以使查询成功，因此我将数据分成较小的部分，但是我仍然遇到错误(尽管不那么频繁)。更好地了解导致此错误的原因，这将是很好的。特别是:

“超出资源”是否总意味着分片用完了内存，或者是否还意味着任务用完了时间？

估算内存使用量和可用总内存的正确方法是什么？我是否假设每个分片跟踪大约1/n个组并保持每个组的组 key 和所有聚合是正确的，还是我应该考虑另一种方法？

如何确定分片数量？特别是，如果查询较小的数据集，是否会减少分片/资源？

有问题的查询看起来像这样(实际上，它用作子查询，而外部查询聚合结果):

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，并且查询结果不足一百万个组，并且仍然因“超出资源”而失败。减少立即处理的时间戳数可以解决该错误，但是我担心我最终会遇到足够大的数据规模，以致整个这种方法将无法正常工作。

Answer 1

您已经猜到了，BigQuery根据要操作的表的大小为GROUP EACH和JOIN EACH查询选择许多并行工作程序(分片)。这是一种粗略的启发式方法，但实际上，它的效果很好。

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

要回答您的特定问题:

资源几乎总是超出限制，这意味着工作线程内存不足。用Dremel的术语来说，它可以是分片或混合器(混合器是计算树中聚合结果的节点。GROUP EACH BY将聚合向下推到分片(即计算树的叶子))。

没有一种很好的方法来估算可用资源量。随着时间的推移，这种情况会发生变化，目标是更多的查询应该可以正常工作。

分片的数量由查询中处理的总字节数决定。您已经注意到，这种启发式方法不适用于扩展基础数据集的联接。就是说，正在进行一些积极的工作，以使我们更加聪明地选择分片的数量。为了让您有个规模的概念，您的查询仅安排在20个分片上，这只占较大表的一小部分。

解决方法是，将CROSS JOIN的中间结果另存为表，然后在该临时表上运行GROUP EACH BY。那应该让BigQuery在选择分片数量时使用扩展大小。 (如果这不起作用，请让我知道，我们可能需要调整分配阈值)。