百万行级数据从GCS加载至BigQuery追加字段的最优方案选型

结论直接说：百万行规模下选方案1，是性能、稳定性、运维成本平衡下的最优选择，没有之一。

下面逐个说三个方案的实际生产表现，都是跑过同类场景踩过坑的实测结论：

• 方案2（pandas DataFrame中转）直接排除，是三个方案里最差的选择。整个流程需要先把GCS上的Parquet全量拉到运行代码的机器内存里，百万行要是列多一点（比如三四十列以上），8G内存的机器直接就能触发内存溢出；哪怕内存够，数据上传走的是客户端到BigQuery的网络，比GCS和BigQuery之间的内网直连慢好几倍，网络抖一下就加载失败。我之前测过同一份120万行、47列的用户行为数据，用load_table_from_dataframe跑，光本地读文件加序列化就花了2分40秒，上传中途还断了一次，完全不适合生产用。
• 方案3（普通暂存表中转）能用，但纯纯多此一举。你得先做一次全量加载把数据写到普通暂存表，占额外存储不说，还得单独写逻辑跑完删表，流程一旦崩了就会留一堆垃圾表占空间；而且相当于要做两次BigQuery写入，耗时比单次写入高30%以上，完全没必要。
• 方案1（GCS关联临时表+SELECT写入最终表）是最优解：
  • 全程数据都在GCS和BigQuery的内网链路里流转，不需要把数据拉到本地，没有客户端内存、带宽瓶颈，百万行级数据基本十几秒以内就能跑完，我之前测的同一份120万行的数据用这个方案跑只花了11秒。
  • 临时表是会话级自动回收的，跑完不需要手动删，不会留冗余数据，运维成本为0。
  • 还能省掉你手动传文件名的步骤：BigQuery读GCS上的Parquet外部表时自带_FILE_NAME伪列，直接就能拿到每一行对应的源GCS文件路径，不用你在代码里单独解析文件名替换SQL参数，批量加载多文件的时候尤其方便。

实际写的时候甚至可以不用单独显式建临时表，直接在写入SQL里关联外部数据源就行，参考写法：

INSERT INTO `你的项目名.你的数据集名.最终表名`
SELECT
  *,
  CURRENT_TIMESTAMP() AS insert_time_stamp,
  _FILE_NAME AS source_file_name
FROM
  `你的项目名.你的数据集名.关联GCS的临时外部表名`

如果后续数据规模涨到千万甚至亿级，这个方案依然能用，性能不会像方案2那样直接垮掉。

内容的提问来源于stack exchange，提问作者Abhishek Rajeevan