大查询外部表-查询性能随着源URI中文件数量的增加而降低

Question

我创建了一个外部大查询表来读取"Parquet"；GCS存储桶中的文件。

GCS bucket中的文件夹布局如下：

gs://mybucket/root/year=2022/model=abc/
gs://mybucket/root/year=2022/model=.../
gs://mybucket/root/year=2021/model=abc/
gs://mybucket/root/year=2021/model=.../

布局的组织方式使其遵循大型查询文档中解释的配置单元分区布局。列"；年；以及"；型号"；被视为外部表中的分区列。

**External Data Configuration**
Source URI(s)- gs://mybucket/root/*
Source format - PARQUET 
Hive Partitioning Mode - CUSTOM 
Hive Partitioning Source URI Prefix - gs://mybucket/root/{year:INTEGER}/{model:STRING} 
Hive Partitioning Column(s)- year, model 

问题：当我在下面给出的外部表上运行查询时，我观察到每个查询在实际运行之前都会运行最初的2-3分钟。Big Query控制台显示"；查询挂起"；在这段时间内；查询运行"；输出以最小的时隙时间消耗显示(时隙时间显示为1-2秒。(

Select * from myTable Where year = 2022 and model = 'abc' 

基础文件数将随着年份和型号的不同而变化和增加。多年来，随着镶木地板文件的增多，最初的时间有时约为4-5分钟。

根据文档，我的理解是，如果查询中存在分区列，就会进行某种分区修剪，我希望查询能够根据文档立即做出响应。

https://cloud.google.com/bigquery/docs/hive-partitioned-queries-gcs#partition_pruning

但我的观察与此相反。如果源URI被限制为1年，则表读取一年的数据，查询初始时间(在控制台上保持"查询挂起"(将减少到1-2分钟(甚至更短(

Source URI(s)- gs://mybucket/root/year=2022/*

问题：这是预期行为吗？因为随着GCS存储桶中文件数量的增加，查询运行所需的时间甚至更长(尤其是初始时间，实际运行时间变化不大(，尽管在where子句中应用了年份和模型分区列。

Answer 1

这可能是预期行为。在进行分区修剪之前，需要列出GCS中的对象，这可能是花费时间的地方。我们正在努力改进这方面的工作。时隙时间如此之低，这一事实很好地表明修剪实际上正在发生(由于大多数文件都没有被读取，因此没有太多的时隙时间可供消耗(。