BigQuery 流式插入在 GKE 上出现错误

哈喽！今天心血来潮给大家带来了《BigQuery 流式插入在 GKE 上出现错误》，想必大家应该对Golang都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习Golang，千万别错过这篇文章~希望能帮助到你！

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

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

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

BigQuery 日志记录也没有任何错误/警告。

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

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

[编辑]

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

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

解决方案

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

好了，本文到此结束，带大家了解了《BigQuery 流式插入在 GKE 上出现错误》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！