BigQuery 流式插入在 GKE 上失败

Posted 2023-03-24

【中文标题】BigQuery 流式插入在 GKE 上失败

【英文标题】：BigQuery streaming inserts fail on GKE

【发布时间】：2020-12-03 16:23:49

【问题描述】：

我们有具有 3 个 n2-highcpu-8 节点的 GKE 集群，用 GO 编写的 Web 应用程序扩展到 3 个实例（每个节点 1 个），它们使用流式传输将所有请求写入 BigQuery，我注意到非常奇怪的行为：

在高应用程序使用率期间，3 个应用程序实例中的 2 个开始 100% 失败流式写入，仅写入“超出上下文截止日期”作为错误，当我删除这 2 个 pod 并且它们恢复接收流量时旧 1 开始失败，并出现“超出上下文截止日期”，而新 2 中的 1 个成功继续写入数据，另一个开始失败。

我查看了 BigQuery 文档中提供的报价和限制，但没有找到任何可能与此案例相关的内容，我查看了 Stackdriver Monitoring 以查看每张表每秒有多少写入以及大约 1500 的数字，以及大小发送的数据也很小 1-5kb，我们不使用批量写入，所以它主要通过 goroutines 在请求到来时尽快完成。

BigQuery Logging 也没有任何错误/警告。

是否有任何隐藏的限制，或者整体 BigQuery 流式写入仅适用于少量同时写入，我们需要一些使用 Pub/Sub 和 Dataflow 的队列解决方案将数据大量传输到 BigQuery？

GKE 和 BigQuery 数据集位于 europe-west-2，这种情况每天都在发生

[编辑]

以下是来自最大表格之一的一些流式统计数据（如果确实有任何影响）：

流缓冲区统计信息 估计大小 249.57 MB 估计行数 1,640,220 最早入场时间2020年12月3日18:43:00

【问题讨论】：

BigQuery 听起来很公平，您没有达到限制。你能分享你的代码让我们看看是否出现了奇怪的东西吗？

【参考方案1】：

实际上这个问题与应用程序的 Affinity 设置配置错误有关，并且 2 个 Pod 在同一个 GKE 节点上运行，在黄金时段消耗了 100% 的 cpu，这似乎是一个相关问题，所以在这之后我们进行了排序没有看到任何上下文截止日期消息或写入 BigQuery 的错误