Google BigQuery - 查询已成功运行但结果未推送到目标表

时间:2014-01-23 03:11:01

标签: java google-bigquery

我们通过Java REST API对BigQuery运行夜间查询,该API指定要推送到的结果的目标表(write disposition = WRITE_TRUNCATE)。今天的查询似乎运行没有错误,但结果没有被推送到目标表。

此查询已运行了几周,我们没有遇到任何问题。也没有进行任何代码更改。

在“失败”之后第二次手动运行它工作正常。我们发现这只是一个小故障,我们担心它可能再次发生。

我们从“失败”查询中记录的JSON响应看起来很好(我对所有敏感数据进行了模糊处理):

INFO: Job finished successfully: {
"configuration" : {
"dryRun" : false,
"query" : {
  "createDisposition" : "CREATE_IF_NEEDED",
  "destinationTable" : {
    "datasetId" : "[REMOVED]",
    "projectId" : "[REMOVED]",
    "tableId"   : "[REMOVED]"
  },
  "priority" : "INTERACTIVE",
  "query" : "[REMOVED]",
  "writeDisposition" : "WRITE_TRUNCATE"
 }
},
"etag" : "[REMOVED]",
"id" : "[REMOVED]",
"jobReference" : {
 "jobId" : "[REMOVED]",
 "projectId" : "[REMOVED]"
},
"kind" : "bigquery#job",
"selfLink" : "[REMOVED]",
"statistics" : {
 "creationTime" : "1390435780070",
 "endTime" : "1390435780769",
 "query" : {
  "cacheHit" : false,
  "totalBytesProcessed" : "12546"
},
 "startTime" : "1390435780245",
 "totalBytesProcessed" : "12546"
 },
 "status" : {
 "state" : "DONE"
 }
}

使用“试试吧!”对于Jobs / GET here并插入作业ID也表明作业确实成功并匹配我们记录的输出(粘贴在上面)。

检查Web控制台显示目标表已被截断但未更新。奇怪的是,“上次修改时间”尚未更新(我确实尝试过多次刷新页面):

http://i.stack.imgur.com/384NL.png

有没有人在使用BigQuery之前遇到过这种情况 - 一个看起来成功运行的查询但是如果指定了目标/引用表,结果却没有被推送,那么表被截断了?

2 个答案:

答案 0 :(得分:0)

我是BigQuery团队的开发人员。我从你离开的面包屑中查找了你的工作细节(你的查询是在那个开始时间开始的唯一一个)。

看起来您的目标表在今天太平洋标准时间今天下午4:09被截断,这是您的作业运行的时间,但它被留空了 - 截断它的查询实际上并没有填写任何信息。

我在拼凑细节方面遇到了一些麻烦,因为其中一个源表似乎已被覆盖(连接左外侧的左表是在下午4:20创建的)。

但是,“处理的总字节数”字段中有一条线索 - 它表示查询仅处理了12K的数据。内部统计数据表明,在所涉及的两个表中,查询中只涉及384行。

我的猜测是查询合法地返回了0行,因此该表已被清除。

有一个错误,即删除表中的所有数据不会更新上次修改时间。我们使用上次修改来表示元数据更新的时间(如描述,架构等)或表中最后一次添加数据的时间。但是,如果你只是截断表格,那就不会更新元数据或添加数据,所以我们最终会得到陈旧的最后修改时间。

如果这听起来不像是一个合理的事件链,那么我们需要更多关于如何调试它的信息(特别是因为看起来所涉及的表在运行此查询后已被修改),以及我们可以重现它的方式会很棒。

答案 1 :(得分:0)

所以,我们弄清楚问题是什么。在过去的几天里它再次失败了几次,所以我们进一步挖掘。

正在执行的查询依赖于在其之前执行的另一个查询。虽然我们确实等待第一个查询完成(作业状态=“完成”),但在幕后看来它实际上还没有完全完成,而且它的数据还没有被使用。

目前的流程是:

  1. 从其他数据源获取数据并将结果流式传输到表A
  2. 当(1)完成时(轮询作业ID并获取状态“DONE”)提交另一个查询,该查询使用表A中的结果加入以创建表B
  3. 表A的数据尚不可用,因此(2)的查询会产生一个空表
  4. 我们注意到,在第一次查询使用流式传输时,数据实际显示大约需要5-10秒,并且可以在BigQuery中使用。

    我们使用了相当丑陋的解决方法 - 只需在第一次查询后等待几秒钟,然后再运行下一个查询。不完全优雅,但它有效。