BigQuery外部Parquet表指定分区后自动列检测失效咨询

我们有部分BQ项目通过以下SQL基于Parquet文件创建外部表：

CREATE OR REPLACE EXTERNAL TABLE my_dataset.my_table
WITH PARTITION COLUMNS (ingestion_date DATE)
OPTIONS (
    format = 'PARQUET',
    uris = ['gs://my-bucket/MyTable/*'],
    hive_partition_uri_prefix = 'gs://my-bucket/MyTable/'
);

此前该语句能自动检测Parquet文件中的列，同时使用指定的分区列，每日重建表都无异常。但从2025年10月15日CET时间约6点起，新创建的表只包含分区列，导致下游查询因找不到预期列而失败。目前已知两种临时修复方案：移除分区声明，或者同时显式指定列与分区配置，但根据官方文档，该场景本应支持自动列检测，现需明确问题原因及长期解决方案。

可能的问题原因 #

• Parquet文件结构异常：检查目标GCS路径下的Parquet文件是否在故障时间点发生了结构变更，比如字段被删除、schema为空，或者新写入的文件schema与历史版本不一致。BigQuery自动检测列时会采样路径内的文件，若采样到的文件无有效列，就会只保留分区列。
• BigQuery服务端逻辑变更：故障时间点可能恰逢BigQuery的后台更新，导致自动schema检测与分区配置的交互逻辑出现临时bug。
• 分区路径格式不符合规范：确认GCS上的分区路径是否遵循Hive格式（例如ingestion_date=2025-10-15），若路径格式错误，可能干扰BigQuery对文件内容的扫描逻辑，导致无法识别非分区列。
• 权限或文件访问问题：执行建表语句的账号是否对GCS路径下的所有Parquet文件有读取权限？若部分文件无法访问，采样时可能无法获取有效schema。

解决方案 #

1. 验证Parquet文件有效性
   • 用bq show --schema gs://my-bucket/MyTable/[具体有效文件路径]命令直接查看单个Parquet文件的schema，确认文件本身是否包含预期列。
   • 检查GCS路径下是否存在空文件或损坏的Parquet文件，清理这类无效文件后重试建表。
2. 强制指定采样文件
   • 在OPTIONS中添加参数，引导BigQuery优先采样包含完整schema的历史文件，示例：

     CREATE OR REPLACE EXTERNAL TABLE my_dataset.my_table
     WITH PARTITION COLUMNS (ingestion_date DATE)
     OPTIONS (
         format = 'PARQUET',
         uris = ['gs://my-bucket/MyTable/ingestion_date=2025-10-14/*', 'gs://my-bucket/MyTable/*'],
         hive_partition_uri_prefix = 'gs://my-bucket/MyTable/',
         hive_partition_load_metadata_mode = 'CUSTOM',
         metadata_cache_mode = 'MANUAL'
     );
     

3. 提交官方支持工单
   • 若确认Parquet文件无问题、路径格式正确且权限正常，大概率是BigQuery服务端的临时bug，可提交官方支持工单，提供故障时间点、建表语句、GCS路径等信息，请求排查修复。
4. 临时固化schema恢复业务
   • 若需要快速恢复，可先导出历史正确表的schema：bq extract --destination_format=PARQUET --schema my_dataset.my_table gs://temp-bucket/schema-file，然后在创建外部表时显式指定列定义，暂时绕过自动检测。

内容的提问来源于stack exchange，提问作者Etienne Neveu