Dataproc通过Spark BigQuery连接器读取BigQuery数据的成本疑问

核心结论 #

• 读取过程不会占用BigQuery的查询槽位，因为连接器默认采用BigQuery Storage API读取数据，绕开了BigQuery的查询执行引擎。
• 会产生明确的成本，大表读取的成本直接与实际读取的数据量挂钩。

具体成本拆解 #

1. BigQuery Storage API 费用 #

Spark BigQuery连接器默认通过Storage API批量拉取数据，这部分收费主要看两个维度：

• 实际读取的数据量：按TB计费，比如全量读取20TB大表就按20TB核算费用；如果按日期分区读取，仅计算你指定的分区数据量。
• API请求次数：单次请求成本极低，但大规模读取时累计的请求数会产生少量费用，这部分占比极小。

2. 特殊场景的额外成本（几乎无需考虑） #

如果你手动将连接器配置为旧版导出模式（spark.bigquery.method=export），即先把BigQuery数据导出到GCS再读取，会额外产生两笔费用：

• BigQuery数据导出费用（按导出数据量计费）。
• GCS临时存储费用（数据在GCS留存期间的存储成本）。
  但当前新版连接器默认使用Storage API，这种场景基本不会碰到。

3. 无槽位占用的原因 #

BigQuery的查询槽位仅用于交互式查询、批量SQL等依赖BigQuery执行引擎的操作。Spark连接器是直接从BigQuery底层存储读取数据，完全不走BigQuery的查询执行流程，因此不会占用任何查询槽位，也不会影响你的BigQuery查询配额。

成本优化建议 #

• 保持默认的spark.bigquery.method=direct_read配置，这是成本最优且性能最佳的读取方式。
• 读取分区表时务必添加过滤条件（比如指定日期范围），大幅减少实际读取的数据量，直接降低Storage API费用。
• 对于小于100MB的小表，使用Spark的broadcast()函数将其缓存到所有工作节点，避免重复读取，同时优化关联操作的性能。

内容的提问来源于stack exchange，提问作者Sourav Bhattacharyya