BigQuery 连接对于小尺寸表来说太慢了

Question

我有一张包含以下详细信息的表格：
- 表格大小 39.6 MB
- 行数 691,562
- 2 列：contact_guid STRING、program_completed STRING
- 第 1 列数据类型类似于 uuid。大约 30 个字符长度
- 第 2 列数据类型是长度约为 50 个字符的字符串

我正在尝试这个查询：

#standardSQL
SELECT
  cp1.contact_guid AS p1,
  cp2.contact_guid AS p2,
  COUNT(*) AS cnt
FROM
  `data.contact_pairs_program_together`  cp1
JOIN
  `data.contact_pairs_program_together`  cp2
ON
  cp1.program_completed=cp2.program_completed
WHERE
  cp1.contact_guid < cp2.contact_guid
GROUP BY
  cp1.contact_guid,
  cp2.contact_guid having cnt >1 order by cnt desc

执行时间：1200 秒

我知道我正在进行自加入，并且在最佳实践中提到了避免自加入。

我的问题：

1. 我觉得这个以 mb 为单位的表大小对于 BigQuery 来说太小了，为什么要花这么多时间？就行数和字节大小而言，小表在连接上下文中对 BigQuery 意味着什么？
2. 行数是否太大？ 700k ^ 2 在连接期间是 10^11 行。联接的实际行数是多少？
3. 我确实检查了有关连接的文档，但没有找到关于连接的表有多大以及它可以运行多长时间的信息。我们如何估算粗略的执行时间？

执行细节：

Answer 1

如您提供的屏幕截图所示 - 您正在处理爆炸连接。

在这种情况下，第 3 步需要 130 万行，并设法生成 4.59 亿行。步骤 04 到 0B 处理重新分区和重新洗牌所有额外数据 - 因为查询没有提供足够的资源来处理这些行数：它从 1 个并行输入扩展到 10,000 个！

您有两个选择：要么避免爆炸连接，要么假设爆炸连接需要很长时间才能运行。但正如问题中所解释的 - 你已经知道了！

如果您在一个操作中生成所有额外的行（执行连接、实现），然后运行另一个查询来处理 4.59 亿行，会怎么样？由于上述原因，第一个查询会很慢，但第二个查询会运行得很快，因为 BigQuery 会提供足够的资源来处理大量数据。

Answer 2

同意以下建议

看看您是否可以使用分析函数（Tim）重新表述您的查询

使用分析函数会是一个更好的主意（Elliott）

下面是我的做法

#standardSQL
SELECT
  p1, p2, COUNT(1) AS cnt
FROM (
  SELECT
    contact_guid AS p1, 
    ARRAY_AGG(contact_guid) OVER(my_win) guids
  FROM `data.contact_pairs_program_together` 
  WINDOW my_win AS (
    PARTITION BY program_completed 
    ORDER BY contact_guid DESC 
    RANGE BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING
  )
), UNNEST(guids) p2
GROUP BY p1, p2
HAVING cnt > 1
ORDER BY cnt DESC   

如果有帮助，请尝试告诉我们