BigQuery分区表查询成本远超表大小，求原因及解决方法

我有一张由CloudSQL通过Datastream填充的BigQuery表。3天前为降低查询成本，我将其改为按日分区，但分区裁剪（partition pruning）未生效。由于切换回非分区表比较麻烦，就保留了分区设置。

该表每日会被截断后重新填充，当前表内有180万行数据，大小约700MB，加上20MB的流缓冲区（查询__TABLES__元表和GUI显示的数值一致）。

但执行SELECT * FROM table_name时，查询成本高达3GB，执行详情显示读取了近700万行数据，疑似已被截断的数据仍被BigQuery读取——这个大小刚好对应4天的数据量。未分区时从未出现过这个问题，请问这是什么原因？

补充信息 #

• 逻辑字节：~700MB
• 物理字节：~700MB
• 时间旅行（Time Travel）字节：~650MB
• 分区数：560

简化表结构如下：

event_date            DATE
hour                  INTEGER
data_columns          VARIOUS
...
datastream_metadata   RECORD
    uuid              STRING
    source_timestamp  INTEGER

无其他时间戳字段，event_date跨度数月，不适合作为过滤条件；source_timestamp仅为CloudSQL的最后修改日期，可能对应多天前的数据，也无法用于过滤。

更新1 #

奇怪的是，使用BigQuery的时间旅行（Time Travel）功能查询无流缓冲区的表版本时，查询成本回到700MB，但分区裁剪仍未生效。例如：

以下查询成本为3GB：

SELECT * FROM table_name
    WHERE event_date = '2023-10-29';

而以下查询（时间区间早于流缓冲区中最早记录）成本为700MB：

SELECT * FROM table_name
    FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
    WHERE event_date = '2023-10-29';

两者均返回约2000行数据，按event_date分区的话，查询成本应该仅为几百KB。

行为不一致：首次执行时间旅行查询时实际成本为700MB，但第二次及后续执行则按3GB计费。

内容的提问来源于stack exchange，提问作者Greyson Gould