修复 BigQuery 中的“资源超出”并使其运行速度更快

Question

GDELT 的 Kalev Leetaru 遇到了这个问题 - 以下查询将在分析整月时在 Bi​​gQuery 中运行，但在整整一年时不会运行。

SELECT Source, Target, count, RATIO_TO_REPORT(count) OVER() Weight
FROM (
  SELECT a.name Source, b.name Target, COUNT(*) AS COUNT
  FROM (FLATTEN(
      SELECT
        GKGRECORDID, CONCAT( STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)), '#', STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)) ) AS name
      FROM [gdelt-bq:gdeltv2.gkg]
      WHERE DATE>20150100000000 and DATE<20151299999999, name)) a
  JOIN EACH (
    SELECT 
      GKGRECORDID, CONCAT( STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)), '#', STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)) ) AS name
    FROM [gdelt-bq:gdeltv2.gkg]
    WHERE DATE>20150100000000 and DATE<20151299999999 ) b
  ON a.GKGRECORDID=b.GKGRECORDID
  WHERE a.name<b.name
    AND a.name != '0.000000#0.000000'
    AND b.name != '0.000000#0.000000'
  GROUP EACH BY 1, 2
  ORDER BY 3 DESC )
WHERE count > 50
LIMIT 500000

“在查询执行期间超出了资源。”

我们怎样才能解决这个问题？

Answer 1

首先是关于成本优化的说明：BigQuery 对扫描的每列收费，此查询将超过 72GB。 GDELT gkg 表将其整个故事存储在一张表中 - 我们可以通过创建年度表而不是单个表来优化成本。

现在，我们如何修复这个查询，让它运行一整年？ “查询执行期间资源超出”通常来自不可扩展的函数。 例如：

• RATIO_TO_REPORT(COUNT) OVER()不会扩展：OVER() 函数在整个结果集上运行，允许我们计算总数以及每行贡献的总数 - 但要运行这个，我们需要整个结果集适合一台虚拟机。 好消息是 OVER() 能够在对数据进行分区时进行扩展，例如通过具有 OVER(PARTITION BY month) - 那么我们只需要每个分区都适合 VM。 对于此查询，为简单起见，我们将删除此结果列。

• ORDER BY 无法扩展：要对结果进行排序，我们也需要将所有结果都放在一台 VM 上。 这就是为什么“--allow-large-results”不允许逐步运行 ORDER BY，因为每个 VM 将并行处理和输出结果。

在这个查询中，我们有一个简单的方法来处理 ORDER BY 的可扩展性——我们将把后面的过滤器“WHERE COUNT > 50”移到流程的前面。 我们将移动它并将其更改为 HAVING，而不是对所有结果进行排序，并过滤那些 COUNT>50 的结果，因此它在 ORDER BY 之前运行：

SELECT Source, Target, count
FROM (
  SELECT a.name Source, b.name Target, COUNT(*) AS COUNT
  FROM (FLATTEN(
      SELECT
        GKGRECORDID, CONCAT( STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)), '#', STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)) ) AS name
      FROM [gdelt-bq:gdeltv2.gkg]
      WHERE DATE>20150100000000 and DATE<20151299999999,name)) a
  JOIN EACH (
    SELECT 
      GKGRECORDID, CONCAT( STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)), '#', STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)) ) AS name
    FROM [gdelt-bq:gdeltv2.gkg]
    WHERE DATE>20150100000000 and DATE<20151299999999 ) b
  ON a.GKGRECORDID=b.GKGRECORDID
  WHERE a.name<b.name
    AND a.name != '0.000000#0.000000'
    AND b.name != '0.000000#0.000000'
  GROUP EACH BY 1, 2
  HAVING count>50
  ORDER BY 3 DESC )
LIMIT 500000

现在查询运行了一整年的数据！

让我们看看解释统计：

我们可以看到 1.88 亿行的表被读取了两次：第一个子查询产生了 15 亿行（给定“FLATTEN”），第二个子查询过滤掉了不在 2015 年的行（注意这个表在 2015 年初开始存储数据）。

第 3 阶段很有趣：加入两个子查询产生了 30 亿行！ 通过 FILTER 和 AGGREGATE 步骤，这些减少到 5 亿：

我们能做得更好吗？

是的！ 让我们将 2 WHERE a.name != '....'到更早的“HAVING”：

SELECT Source, Target, count
FROM (
  SELECT a.name Source, b.name Target, COUNT(*) AS COUNT
  FROM (FLATTEN(
      SELECT
        GKGRECORDID, CONCAT( STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)), '#', STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)) ) AS name
      FROM [gdelt-bq:gdeltv2.gkg]
      WHERE DATE>20150100000000 and DATE<20151299999999
      HAVING name != '0.000000#0.000000',name)) a
  JOIN EACH (
    SELECT 
      GKGRECORDID, CONCAT( STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)), '#', STRING(ROUND(FLOAT(IFNULL(REGEXP_EXTRACT(SPLIT(V2Locations,';'),r'^[2-5]#.*?#.*?#.*?#.*?#.*?#(.*?)#'), '0')), 3)) ) AS name
    FROM [gdelt-bq:gdeltv2.gkg]
    WHERE DATE>20150100000000 and DATE<20151299999999 
    HAVING name != '0.000000#0.000000') b
  ON a.GKGRECORDID=b.GKGRECORDID
  WHERE a.name<b.name
  GROUP EACH BY 1, 2
  HAVING count>50
  ORDER BY 3 DESC )
LIMIT 500000

这运行得更快！

让我们看看解释统计：

看？ 通过在加入之前将过滤移动到一个步骤，阶段 3 只需经过 10 亿行，而不是 30 亿行。 快得多（即使对于 BigQuery，您可以自行检查，也能够在短时间内处理 JOIN 生成的超过 30 亿行）。

这个查询是为了什么？

看看这里的漂亮结果： http : //blog.gdeltproject.org/a-city-level-network-diagram-of-2015-in-one-line-of-sql/