Question

我有一个大小约为200K行的表研究人员和另一个约50K行的表请求。我发出以下请求。

SELECT a._id, a.createdAt, b.time, b.researcherId FROM
datasci.requests as a 
JOIN analytics.researchers as b on
ABS(TIMESTAMP_DIFF(a.createdAt, b.time , MINUTE)) < 15

我认为这会在几分钟内完成 - 在排序后合并到2个列表。但请求是＆gt;在Bigquery有1个小时，还没有完成。我重复了几次，结果相同。这个查询是否需要重写？

一种选择是帮助＆＃34; BQ通过添加额外的ON条件来完成周（a.createdAt）==周（b.time）这有帮助还是只会让它变得更糟？

Answer 1

行。回答我自己的问题。因此，根据经验，它有助于在不等式条件下增加一个相等条件（数量级更快）。但是，在我的具体情况下，我添加了以下条件

ON (DATE_SUB(DATE(a.createdAt),INTERVAL 1 DAY)  = DATE(b.time)) OR (DATE_ADD(DATE(a.createdAt),INTERVAL 1 DAY)  = DATE(b.time))  OR (DATE(a.createdAt  = DATE(b.time)) AND ABS(TIMESTAMP_DIFF(a.createdAt, b.time , MINUTE)) < 15

花了太多时间。所以，我将它分成3个单独的查询并将它们联合起来

ON (DATE_SUB(DATE(a.createdAt),INTERVAL 1 DAY)  = DATE(b.time)) AND ABS(TIMESTAMP_DIFF(a.createdAt, b.time , MINUTE)) < 15

ON (DATE_ADD(DATE(a.createdAt),INTERVAL 1 DAY)  = DATE(b.time)) AND ABS(TIMESTAMP_DIFF(a.createdAt, b.time , MINUTE)) < 15

ON (DATE(a.createdAt  = DATE(b.time)) AND ABS(TIMESTAMP_DIFF(a.createdAt, b.time , MINUTE)) < 15

这只花了几秒钟。

Answer 2

正如艾略特在评论中提到的那样 - It ends up being modeled like a CROSS JOIN with a filter instead, which isn't as fast
所以，除了filter本身并不快 - 我认为通过将filter置于其中而你也不合理地过度收费all calculations - 我只是将你的查询转换成下面的 - 其中至少一些（或大多数计算）expenses被移回到预加入阶段

SELECT a._id, a.createdAt, b.time, b.researcherId 
FROM (SELECT id, createdAt, 
        UNIX_SECONDS(createdAt)/60 AS minutes 
      FROM datasci.requests
  ) AS a 
JOIN (SELECT time, researcherId, 
        UNIX_SECONDS(time)/60 AS minutes 
      FROM analytics.researchers
  ) AS b 
ON ABS(a.minutes - b.minutes) < 15

如果这无论如何有帮助我会很有意思，因为我没有机会测试这个

即使这个transformation本身没有多大帮助 - 你可以将它应用到你最终的任何解决方案作为进一步的改进因素

在范围加入时Bigquery是否缓慢？

2 个答案: