BigQuery 为查询作业提供哪些原子性保证？

Question

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

我在设计系统时的理解是，所有 BigQuery 操作都是原子操作（基于 atomic inserts in big query、Can I safely query a BigQuery table being replaced with WRITE_TRUNCATE 和 Views are failing when their underlying table is repopulated）。问题是我遇到了错误，还是我误解了我可以期待的确切保证？

回顾历史，过去一周似乎至少有 4 起不同的案例发生了这种情况。

以下是导致这种情况发生的时间线（具体细节适用于最引人注目的案例）：

1. UTC 时间 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）对都有两个。

Answer 1

我们有一个错误，在某些情况下 write-truncate 可能最终会追加。我们昨天（5 月 22 日）发布了修复程序，从那时起就没有发现任何进一步的问题实例。