扫描Parquet联邦表时INT32类型错误：Bug还是预期行为？

错误原因 #

这个问题的核心矛盾在于BigQuery读取时预期的字段类型，和Parquet文件实际存储的类型不匹配，常见触发场景有以下几种：

• Hive元数据与Parquet实际Schema不一致：因为你的表是Hive分区的Parquet表，如果BigQuery关联了Hive Metastore（HMS），它会优先使用Hive表定义的Schema。比如Hive中把visitor_partition定义为INT（对应INT32），但实际Parquet文件里存储的是INT64，就会导致BigQuery期望INT32，但读取到INT64的冲突。
• BigQuery自动类型推断偏差：虽然你用parquet-tools确认了字段是INT64，但BigQuery的自动推断逻辑可能因为字段数值范围极小（你的min是0，max是99），错误地将其推断为INT32类型，尤其是首次创建表时基于少量样本文件推断的情况。
• 分区文件Schema不一致：如果不同Hive分区下的Parquet文件Schema不统一，比如部分分区的visitor_partition是INT32、部分是INT64，BigQuery在合并Schema时可能默认采用INT32作为预期类型。

解决/规避方法 #

针对上述原因，你可以尝试以下几种方案：

1. 显式指定联邦表的Schema
   创建外部表时手动定义完整Schema，强制visitor_partition为INT64，覆盖自动推断或Hive元数据的类型。示例语句：

   CREATE EXTERNAL TABLE my_dataset.my_table (
     -- 替换为你的其他字段定义
     col1 STRING,
     col2 TIMESTAMP,
     visitor_partition INT64
   )
   PARTITIONED BY (year INT64, day DATE)
   STORED AS PARQUET
   LOCATION 'gs://your-gcs-bucket/path-to-table/'
   OPTIONS (
     hive_partition_uri_prefix = 'gs://your-gcs-bucket/path-to-table/year='
   );
   

2. 忽略Hive Metastore的Schema（如果关联了HMS）
   如果你的联邦表基于Hive Metastore创建，可以添加ignore_hive_metastore_schema=true选项，让BigQuery直接读取Parquet文件的实际Schema，而非依赖Hive的定义：

   CREATE EXTERNAL TABLE my_dataset.my_table
   PARTITIONED BY (year INT64, day DATE)
   STORED AS PARQUET
   LOCATION 'gs://your-gcs-bucket/path-to-table/'
   OPTIONS (
     hive_metastore_uri = 'thrift://your-hms-host:9083',
     ignore_hive_metastore_schema = true
   );
   

3. 刷新外部表的元数据
   有时候BigQuery会缓存外部表的Schema信息，即使Parquet文件的Schema已经更新，缓存的旧Schema依然会导致错误。执行以下命令刷新元数据：

   CALL BQ.REFRESH_EXTERNAL_METADATA('my_dataset.my_table');
   

4. 校验所有分区文件的Schema一致性
   用parquet-tools检查其他Hive分区下的Parquet文件，确保visitor_partition字段的类型在所有文件中都是INT64。如果存在混合类型的文件，需要统一Parquet文件的Schema（比如重新导出数据），或者在创建表时指定兼容的类型（比如用INT64覆盖）。

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