小编Ala*_*rce的帖子

我正在编写一个后台工作来自动处理BigQuery中的A/B测试数据,并且我发现在执行大型GROUP EACH BY语句时,我正在点击"在查询执行期间超出资源".我在查询执行期间从Resources Exceeded中看到,减少组的数量可以使查询成功,因此我将数据拆分成较小的部分,但我仍然遇到错误(尽管不常见).能够更好地直观了解导致此错误的原因会更好.特别是:

• "超出资源"是否意味着碎片耗尽内存,或者是否也意味着任务耗尽时间？
• 什么是近似内存使用和我可用的总内存的正确方法？我是否正确假设每个分片跟踪大约1/n的组并保持组密钥和每个组的所有聚合,或者是否有其他方式我应该考虑它？
• 如何确定分片的数量？特别是,如果我查询较小的数据集,是否会获得更少的分片/资源？

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

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,并且查询结果在一百万个组之下,并且它仍然因"超出资源"而失败.减少要立即处理的时间戳的数量可以修复错误,但是我担心我最终会达到一个足够大的数据范围,这样整个方法就会停止工作.

我正在调查我编写的定期运行的作业中的数据正确性问题，该问题似乎是由BigQuery以非原子方式两次重写同一张表引起的。更具体地说，我有同一查询的两个副本同时运行（由于重试逻辑），两个副本都设置为覆盖同一表（使用WRITE_TRUNCATE选项），并且生成的表每行都有两个副本。我期望一个查询用查询结果写一个表，而另一个查询用相同的结果覆盖它，而不是以一个双倍大小的表结尾。

在设计系统时，我的理解是所有BigQuery操作都是原子操作（基于大查询中的原子插入，我可以安全地查询被WRITE_TRUNCATE替换的BigQuery表，并且在重新填充其基础表时视图失败））。是我遇到了bug，还是我误解了我可以期望的确切保证？

纵观历史，在过去一周中，至少有4个案例发生了这种情况。

这是导致这种情况发生的时间轴（具体细节适用于最明显的情况）：

1. 在世界标准时间4月30日18:07左右，我的代码同时提交了82个查询。每个人查询一个以conversions_2014_04_30_14结尾的表，然后查询另一个表，并写入以conversions_2014_04_30_16结尾的表（指定WRITE_TRUNCATE）。
2. 大约25分钟后，其中25个查询仍未完成（比平时要多），因此触发了“重试”逻辑，该逻辑放弃了所有仍在运行的查询，只是再次提交了它们（这是为了解决我遇到的问题我已经看到查询将在何处停留几个小时而没有运行，我在这里提到：https : //code.google.com/p/google-bigquery/issues/detail?id=83&can=1）。这意味着一次要处理50个查询，这25个尚未完成的查询中有两个。
3. 完成所有查询后，结果表中的82个中有6个是应有的两倍。

这是一个例子：

第一个查询作业：124072386181：job_tzqbfxfLmZv_QMYL6ozlQpWlG5U

第二个查询作业：124072386181：job_j9_7uJEjtvYbyeVmEVP0u2er9Lk

结果表：124072386181：bigbingo_history.video_task_companions_conversions_2014_04_30_16

再举一个例子：

第一个查询作业：124072386181：job_TQJzGabFT9FtHI05ftTkD5O8KKU

第二查询作业：124072386181：job_5hogbjnLX_5a2opEJl9Jacnn53s

表格：124072386181：bigbingo_history.Item_repetition__Elimination_conversions_2014_04_27_16

由于运行了这些查询（除了第一个表的架构添加），因此未触及这些表，因此它们仍包含重复的行。确认这一点的一种方法是查看所有查询都具有“ GROUP BY替代项，bingo_id”，但是表具有每个（替代项，bingo_id）对中的两个。