【发布时间】：2018-03-17 00:50:06
【问题描述】：
我们一直在两个数据集上使用流式插入，一个带有日期分区表，一个带有非日期分区表。很长一段时间（一年多），它们一直运行良好。
最近我们注意到 BigQuery 更频繁地响应 503 错误。 15% 到 50% 的时间。
在尝试分析问题时，我们构建了测试客户端，该客户端仅完成 1 条记录的流式传输，并使用了模板后缀选项。我们看到了一种我们以前从未见过的非常奇怪的行为。以下是场景：
- templateSuffix='xxx' 和 tableId='sessions_'，其中 session_xxx 不存在。这行得通！
- templateSuffix='yyy' 和 tableId='sessions_'，其中 session_yyy 存在于不久前。这失败了！ (503)
- templateSuffix='xxx' 和 tableId='sessions_'，其中 sessions_xxx 是由第一次测试创建的。这行得通！
我们在使用 API Explorer 时也看到了相同的行为。
由于某些未知原因，我们的生产系统仍然只是以前面提到的速度失败，但测试始终失败。生产系统位于数据中心，但测试是在我们的办公室运行的。
看起来 503 是包罗万象的错误，我们甚至尝试只传递一个字段以确保它不是数据。那里也没有运气。场景是一致的。
没有模板后缀的流式传输，适用于存在已久的表和新创建的表，这使我们相信问题似乎出在模板后缀功能上。
不确定是否相关（可能不相关），但是当使用日期分区表流式传输到第二个数据集时，错误率非常相似。但此外，当 insertAll 调用没有错误响应时，大约 40% 的时间数据即使在一天后也不会显示在表中。
【问题讨论】：
-
能否提供每个失败的具体错误信息？
-
几乎都是：503 Service Unavailable { "code" : 503, "errors" : [ { "domain" : "global", "message" : "执行过程中遇到错误。重试可能解决问题。", "reason" : "backendError" } ], "message" : "执行过程中遇到错误。重试可能会解决问题。", "status" : "UNAVAILABLE" }
-
你可以把project_id、dataset_id、table_id、插入时间等更多信息发给我，让我看看。