大查询抛出“查询执行期间超出资源”

如何解决大查询抛出“查询执行期间超出资源”

在使用Google BigQuery时，我正在按组运行查询，并收到错误消息：“查询执行期间资源超出。无法在分配的内存中执行查询。高峰使用：限制的152％。最大的内存使用者（s）：用于OVER（）子句分析的排序操作：99％其他/未分配：1％”。

我正在使用此查询-

    SELECT
  CASE
    WHEN (sourceId = 1 AND web_id IS NOT NULL) THEN LAST_VALUE(Name IGNORE NULLS) OVER (PARTITION BY dgId,web_id ORDER BY event_timestamp ASC)
    WHEN (sourceId IN (2,4)
    AND zc IS NOT NULL) THEN coalesce(LAST_VALUE(Name IGNORE NULLS) OVER (PARTITION BY dgId,zc ORDER BY event_timestamp ASC),FIRST_VALUE(Name IGNORE NULLS) OVER (PARTITION BY dgId,zc ORDER BY event_timestamp ASC ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING))
  ELSE
  Name
END
  AS Name,session_id,CASE
    WHEN (sourceId = 1 AND web_id IS NOT NULL) THEN LAST_VALUE(user_id IGNORE NULLS) OVER (PARTITION BY dgId,4)
    AND zc IS NOT NULL) THEN coalesce(LAST_VALUE(user_id IGNORE NULLS) OVER (PARTITION BY dgId,FIRST_VALUE(user_id IGNORE NULLS) OVER (PARTITION BY dgId,zc ORDER BY event_timestamp ASC ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING))
  ELSE
  user_id
END
  AS user_id
FROM (
  SELECT
    CASE
      WHEN (sourceId = 1 AND web_id IS NOT NULL) THEN FIRST_VALUE(consent_resolved IGNORE NULLS) OVER (PARTITION BY dgId,web_id ORDER BY event_timestamp ASC ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)WHEN (sourceId IN (2,4) AND zc IS NOT NULL) THEN FIRST_VALUE(consent_resolved IGNORE NULLS) OVER (PARTITION BY dgId,zc ORDER BY event_timestamp ASC ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)
    ELSE
    consent_resolved
  END
    AS consent_resolved,* EXCEPT(consent_resolved)
  FROM (
    SELECT
      CASE
        WHEN (LOWER(consent) ='no') THEN consent
      ELSE
      NULL
    END
      AS consent_resolved,*
    FROM
      `table_name` ))
WHERE
  consent_resolved IS NULL;

任何建议如何解决？我的大查询表中有5000万行。

解决方法

虽然我没有样本数据来优化您的查询，但我将向您解释要点。

BigQuery中有一些特定的操作，要求数据必须存在于单个节点上。因此，当数据不再适合该节点时，您将收到“查询执行期间超出资源”错误，并且 OVER（）是这些操作之一。如我所见，您的查询执行了大量的 OVER（） 和 ORDER BY 昂贵的资源（在资源方面）。

因此，为了优化查询，您可以使用WITH clause将数据分成碎片。此外，根据documentation，有几点使您的查询具有更好的性能，例如：

• 输入数据和数据源（I / O）：查询多少字节 阅读吗？

• 节点之间的通信（改组）：多少字节 您的查询传递到下一个阶段？

• 您的查询将多少字节传递给每个插槽？

• 计算：查询需要多少CPU工作量？

• 输出（实现）：查询写入多少字节？

• 查询反模式：您的查询是否遵循SQL最佳做法？