使用GCP Data Fusion迁移Oracle表至BigQuery时NUMBER类型报错求助

问题原因 #

Data Fusion的「多数据库表」源组件在解析Oracle无精度的NUMBER类型（即未指定精度和小数位的NUMBER列，如你的第3列）时，无法自动确定对应的BigQuery数据类型，导致schema获取失败。明确指定精度的NUMBER(2,0)通常不会触发这个问题，但无约束的NUMBER因为可存储范围极大，组件无法自动完成类型映射。

可行解决方案（无需修改源表为INT类型） #

1. 自定义SQL映射（快速生效） #

在「多数据库表」组件中切换为自定义SQL模式，手动将无精度的NUMBER列转换为带明确精度的DECIMAL类型，示例SQL如下：

SELECT
  column_1,
  column_2,
  CAST(column_3 AS DECIMAL(38, 10)) AS column_3, -- 根据实际数据精度调整参数
  column_4,
  column_5, -- NUMBER(2,0)可直接保留，也可CAST为INT
  column_6,
  column_7,
  column_8,
  column_9
FROM your_oracle_table_name

自定义SQL会强制Data Fusion识别明确的列类型，避免自动schema解析失败。

2. 配置Data Fusion全局类型映射 #

通过修改Data Fusion的JDBC类型映射规则，让组件自动将Oracle无精度NUMBER转换为兼容类型：

• 进入Data Fusion的环境配置，找到Oracle JDBC数据源的类型映射设置
• 添加映射规则：将Oracle的NUMBER（JDBC类型代码为2）映射为Data Fusion内部的DECIMAL(38,10)，后续BigQuery会自动对应为NUMERIC类型
• 保存配置后，即可直接使用「多数据库表」组件读取整张表，无需编写自定义SQL

3. 源表结构调整（仅业务允许时使用） #

若可以修改Oracle源表，将无精度的NUMBER列改为带明确精度的类型（如NUMBER(38,0)用于整数数据，NUMBER(38,10)用于小数数据），但此方案会影响源系统，需谨慎操作。

结论 #

不需要将所有NUMBER列修改为INT类型，优先使用自定义SQL映射或全局类型映射方案，无需改动源表即可解决报错问题。

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