Spark-BigQuery连接器加载查询结果时为何创建临时表？

你的疑惑很合理，毕竟直接用BQ控制台或jobs.getQueryResults() API确实不用显式存临时表，但Spark作为分布式计算框架，这里的设计是为了适配它的核心需求，具体原因如下：

• 分布式并行读取的适配：jobs.getQueryResults()本质是单会话的分页查询接口，虽然能分段获取结果，但没法支持Spark多Worker节点同时并发读取不同数据分片。而临时表是BQ的标准存储对象，Spark可以通过BQ的存储API，让多个Worker直接并行读取表的不同分区/分片，最大化利用分布式计算的优势。

• 内部临时结果的访问限制：BQ查询默认会把结果写入内部临时表，但这个表是BQ自动管理的，有严格的访问限制：只能由发起查询的原账号、原会话访问，生命周期极短（通常24小时内自动清理），且不支持Spark需要的列式读取、分区裁剪等优化。显式创建的用户临时表则可以突破这些限制，保证Spark作业在运行期间能稳定、高效地读取数据。

• 作业容错与一致性保障：Spark作业可能因节点故障、资源不足等原因重试，或者运行时间较长。如果依赖BQ的内部临时结果，一旦结果被清理或失效，整个作业就会失败。显式临时表由用户控制生命周期，能确保数据在作业运行期间持续可用，同时保证多次读取的结果完全一致。

• 权限与作业隔离：在多用户、多作业共享集群的场景下，显式临时表可以做细粒度的权限控制，避免不同作业的查询结果互相干扰。而BQ内部临时结果和查询强绑定，无法实现这种隔离。

另外补充一点：你看到的JobConfigurationQuery.destinationTable，如果不指定的话，BQ会自动创建内部临时表，但这个表对Spark来说是不可见、不可直接访问的——Spark的BQ连接器需要的是用户可控制的、能通过标准存储API访问的表对象，所以必须显式落地到临时表。

内容的提问来源于stack exchange，提问作者Kohsuke Kawaguchi