BigQuery中Delete+Insert查询首次与后续执行计划差异原因咨询

我正在测试BigQuery中Delete+Insert查询的性能，查询语句如下：

delete from target_table A where <partition_col> = 5 and exists
(Select 1 from staging_table B where
  A.col1 = b.col1  and
  A.col2 = B.col2 and 
  A.col3 = B.col3 and 
  A.col4 = B.col4 and
  B.date >= A.date )

 insert into target_table select * from staging_table

该查询用于从目标表删除增量键对应的数据，再从staging表插入增量数据。

执行性能对比 #

• 首次执行：

  slot time - 2hr 7min, bytes shuffled 135.59gb, bytes processed 47.5gb
  

• 后续执行：

  slot time 31min 31sec, bytes shuffled 105.57mb, bytes processed 5.31gb
  

关键观察 #

后续执行计划中未出现REPARTITION阶段，仅首次执行时有该阶段，这直接大幅减少了后续执行的数据shuffling量。

补充说明 #

每次删除后我会从staging表重新插入数据到目标表，更新staging表的一个日期字段后重新运行DELETE语句（使staging表成为包含更新日期字段的增量数据集）。

执行计划图示 #

• 首次删除执行图1：
  
• 首次删除执行图2：
  
• 第二次删除执行图1：
  
• 第二次删除执行图2：
  

现象解释 #

这一差异核心源于BigQuery对目标表数据分布的优化：

1. 首次执行时的数据分布：目标表target_table的分区<partition_col>=5可能存在数据分布不均、或未按关联键（col1-col4）聚类的情况。为高效执行EXISTS关联删除，BigQuery需要对目标表分区数据进行重分区（REPARTITION），让关联键相同的数据落在同一个slot上，避免跨节点大量数据shuffle，这一步会产生大量shuffled数据，导致slot时间过长。
2. 后续执行时的优化：首次删除并插入数据后，新插入的target_table分区数据会继承staging表的数据分布（若staging表本身按关联键聚类或分布合理），或BigQuery会自动优化该分区的数据存储布局。再次执行删除时，目标表分区的数据已按关联键对齐，无需再做REPARTITION操作，可直接在本地节点完成关联匹配，因此shuffled数据量骤降，执行时间大幅缩短。
3. 增量数据集的影响：后续执行时staging表为增量数据集，数据量远小于首次执行的全量数据，配合数据分布优化，共同带来性能提升。

内容的提问来源于stack exchange，提问作者Mani Shankar.S