我们通过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之前遇到过这种情况 - 一个看起来成功运行的查询但是如果指定了目标/引用表,结果却没有被推送,那么表被截断了?
答案 0 :(得分:0)
我是BigQuery团队的开发人员。我从你离开的面包屑中查找了你的工作细节(你的查询是在那个开始时间开始的唯一一个)。
看起来您的目标表在今天太平洋标准时间今天下午4:09被截断,这是您的作业运行的时间,但它被留空了 - 截断它的查询实际上并没有填写任何信息。
我在拼凑细节方面遇到了一些麻烦,因为其中一个源表似乎已被覆盖(连接左外侧的左表是在下午4:20创建的)。
但是,“处理的总字节数”字段中有一条线索 - 它表示查询仅处理了12K的数据。内部统计数据表明,在所涉及的两个表中,查询中只涉及384行。
我的猜测是查询合法地返回了0行,因此该表已被清除。
有一个错误,即删除表中的所有数据不会更新上次修改时间。我们使用上次修改来表示元数据更新的时间(如描述,架构等)或表中最后一次添加数据的时间。但是,如果你只是截断表格,那就不会更新元数据或添加数据,所以我们最终会得到陈旧的最后修改时间。
如果这听起来不像是一个合理的事件链,那么我们需要更多关于如何调试它的信息(特别是因为看起来所涉及的表在运行此查询后已被修改),以及我们可以重现它的方式会很棒。
答案 1 :(得分:0)
所以,我们弄清楚问题是什么。在过去的几天里它再次失败了几次,所以我们进一步挖掘。
正在执行的查询依赖于在其之前执行的另一个查询。虽然我们确实等待第一个查询完成(作业状态=“完成”),但在幕后看来它实际上还没有完全完成,而且它的数据还没有被使用。
目前的流程是:
我们注意到,在第一次查询使用流式传输时,数据实际显示大约需要5-10秒,并且可以在BigQuery中使用。
我们使用了相当丑陋的解决方法 - 只需在第一次查询后等待几秒钟,然后再运行下一个查询。不完全优雅,但它有效。