Google Pub/Sub+Cloud Run架构下BigQuery插入吞吐量不达预期问题

1. BigQuery侧状态排查 #

• 查看BigQuery监控指标：重点关注streaming_insert_requests（每秒请求数）、streaming_insert_rows（每秒插入行数）、streaming_insert_errors错误率。优先排查是否存在非配额类错误，比如行格式不匹配、表结构不一致导致的重复重试，这类错误会直接浪费请求资源拉低吞吐量。
• 校验insertAll()方法参数配置：确认是否开启了skipInvalidRows、ignoreUnknownValues，未开启的情况下单条错误行会导致整批请求失败，触发无意义重试。
• 核对实际配额：到Google Cloud配额页面查询对应表的流插配额，默认单表每秒1万次请求是通用值，部分区域、历史超配的账号可能被限制到更低值。

2. 业务代码问题排查 #

• 检查批量写入逻辑：insertAll()官方建议单批最多提交500行、总大小不超过10MB，如果你是单请求只插1行，哪怕打满1万次/秒的请求配额，实际每秒插入行数也只有1万，和批量写入的性能差距可达上百倍，这是绝大多数低吞吐量问题的根因。
• 检查请求并发逻辑：Python的google-cloud-bigquery库默认是同步调用，如果没有做异步并发处理（比如用concurrent.futures实现多并发请求），IO阻塞会导致单进程QPS被限制在几十到数百级别，哪怕CPU、内存使用率只有50%也跑不上去。
• 检查重试逻辑：确认是否对4xx类不可恢复错误（比如参数错误、权限不足）也做了重试，这类错误重试不会成功，只会占用带宽拖慢整体速度。

3. 链路配置排查 #

• 确认资源区域一致性：Cloud Run服务和BigQuery数据集必须在同一区域，跨区域调用的网络延迟会大幅提升单次请求耗时，直接拉低吞吐量。
• 检查Cloud Run配置：查看单实例并发数设置，如果手动设为1会严重限制单实例处理能力，默认值为80，可根据单实例负载调整到合适值；同时查看Cloud Run的实际运行实例数指标，确认是否因为扩缩容阈值设置过高、冷启动慢导致实际运行实例数远低于最大100的配置。
• 检查Pub/Sub堆积：查看Pub/Sub的undelivered_messages指标，如果存在大量消息堆积，说明瓶颈在Cloud Run消费侧，而非BigQuery插入侧。

内容的提问来源于stack exchange，提问作者Nicolas Tang