2024年7月17日起ORC文件加载BigQuery报无效时间戳错误

问题场景 #

之前通过Storage Transfer Service将Azure Blob Storage中的ORC文件同步至GCS，再用Airflow的BashOperator执行bq load命令加载到BigQuery，流程一直正常。但2024年7月17日起，流程报错：

Error while reading data, error message: Invalid timestamp value (-62135769600 seconds, 0 nanoseconds)

已确认源端SQL Server数据源、Azure Data Factory导出ORC的Copy Activity均未变更，且导出流程运行正常。

错误原因分析 #

• 这个错误时间戳-62135769600对应的是公元1年1月1日，而BigQuery的TIMESTAMP类型支持的范围是1970-01-01 00:00:00 UTC 到 9999-12-31 23:59:59.999999999 UTC，该时间远低于TIMESTAMP的下限，因此触发报错。
• 虽然源端声称无变更，但大概率是7月17日之后的批次数据中新增了0001-01-01这类极端早期日期——之前的数据集里没有这类值，所以没触发问题。
• 也存在隐性变更的可能：比如ADF依赖的ORC导出库发生了版本更新，导致原本会被转换的特殊日期（比如SQL Server里的最小日期）被原样保留，进而导致BigQuery加载失败。

排查步骤 #

• 用orc-tools解析GCS中7月17日之后的ORC文件，定位包含该无效时间戳的记录，确认原始日期值：

  orc-tools scan gs://your-bucket/path/to/file.orc | grep "-62135769600"
  

• 直接核查源SQL Server对应批次的数据，查找是否存在0001-01-01或类似极端日期的记录。
• 检查ADF Copy Activity的日期类型配置：比如是否设置了NullIf规则、日期格式转换参数，是否有隐性的服务版本更新导致逻辑变化。
• 确认BigQuery目标表的字段类型：如果业务上只需要日期部分，却误将字段设为TIMESTAMP，而DATE类型支持0001-01-01到9999-12-31，这种情况下也会触发错误。

解决建议 #

1. 修正源数据或导出逻辑
   如果0001-01-01是无效业务数据，协调源端修正该值；或者在ADF Copy Activity中添加转换规则，将这类极端日期替换为1970-01-01（TIMESTAMP的最小值）或NULL。
2. 调整BigQuery字段类型
   如果该日期是合法业务场景，且只需要日期部分，将目标表的字段类型从TIMESTAMP改为DATE；如果需要保留完整时间信息，可先转为STRING类型存储，后续按需处理。
3. 在加载阶段转换处理
   • 使用bq load命令时，通过参数指定空值标记，将极端日期转为NULL：

     bq load --source_format=ORC --replace --null_marker='0001-01-01' your-dataset.your-table gs://your-bucket/*.orc schema.json
     

   • 先创建ORC外部表，再通过查询转换后写入目标表：

     CREATE OR REPLACE TABLE your-dataset.your-table AS
     SELECT
       CASE WHEN ts_field = TIMESTAMP('0001-01-01') THEN NULL ELSE ts_field END AS ts_field,
       -- 其他字段
     FROM `your-dataset.your-external-orc-table`
     

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