使用BigQuery通配符执行SUM聚合时FLOAT类型字段报错问题

核心原因 #

这是BigQuery通配符查询的自动Schema推断机制导致的类型不匹配问题：
当你用通配符批量查询多张表时，BigQuery会扫描部分表的Schema来推断统一的字段类型。如果其中某张表的trip_distance字段被推断为NUMERIC类型，但其他表中该字段是FLOAT64，BigQuery就会尝试把所有表的trip_distance强制转换成NUMERIC——而FLOAT64转NUMERIC如果遇到超出精度范围的值，或者类型本身不兼容，就会抛出Cannot read field 'trip_distance' of type FLOAT64 as NUMERIC的错误。

而你用非通配符查询单表时，Schema是明确的，不存在类型推断冲突，所以能正常运行。至于整数字段（比如passenger_count）没问题，是因为不同表的整数类型通常会被统一推断为INT64，不会出现跨类型的转换冲突。

解决办法 #

1. 先排查所有表的字段类型

先确认涉及的所有表中trip_distance的实际类型，避免盲目转换：

SELECT
  table_id,
  column_name,
  data_type
FROM
  `你的项目ID.你的数据集ID.INFORMATION_SCHEMA.COLUMNS`
WHERE
  column_name = 'trip_distance'
  AND table_id LIKE '你的表前缀%' -- 匹配你通配符查询的表前缀

执行后就能看到哪些表的字段类型不一致。

2. 显式强制类型统一（最直接的解决方式）

在聚合查询中，把trip_distance显式转换为统一类型，推荐用SAFE_CAST避免转换失败导致整个查询崩溃：

• 如果想统一为FLOAT64类型：

SELECT
  SUM(SAFE_CAST(trip_distance AS FLOAT64)) AS total_trip_distance
FROM
  `你的项目ID.你的数据集ID.你的表前缀*`

• 如果想统一为NUMERIC类型（注意处理精度问题）：

SELECT
  SUM(SAFE_CAST(trip_distance AS NUMERIC)) AS total_trip_distance
FROM
  `你的项目ID.你的数据集ID.你的表前缀*`

SAFE_CAST会把转换失败的行设为NULL，不会中断整个聚合操作，适合批量表的场景。

3. 提前统一表的Schema（长期方案）

如果这些表是你可控的，最好修改所有表的trip_distance字段为同一类型（比如统一用FLOAT64或NUMERIC），这样后续通配符查询就不会再出现类型冲突问题。

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