PySpark生成Parquet后Athena查询报INT64与double不兼容的解决方法

报错的核心是Parquet文件实际存储的字段物理类型为INT64，但Glue表定义的对应字段类型为double，二者元数据映射不匹配才触发校验报错——哪怕Spark执行printSchema时显示字段为double、Glue Crawler扫描时默认识别成double，本质都是目录里混了历史写入的旧类型Parquet文件、Spark写出时元数据和实际存储类型没对齐，不存在数值层面的转换障碍，完全可以通过以下几个方法解决：

一、适配现存文件的快速修复方案 #

• 重写目标Parquet文件，强制对齐字段类型
  针对存储目录下存在多版本历史Parquet文件、类型混杂的场景，直接通过PySpark读取原有数据，对不兼容字段做类型转换后覆写全量文件，彻底解决元数据不一致问题，可直接执行如下代码：

  # 读取目录下全量历史Parquet数据
  old_df = spark.read.parquet("s3://你的Parquet文件存储路径")
  # 将报错的test_num字段强制转为double类型，对齐目标schema
  fixed_df = old_df.withColumn("test_num", old_df["test_num"].cast("double"))
  # 覆写原路径，生成类型完全统一的Parquet文件
  fixed_df.write.mode("overwrite").parquet("s3://你的Parquet文件存储路径")
  

  覆写完成后重新运行Glue Crawler刷新表元数据，即可正常在Athena中查询。
• 修改Glue表schema适配现有文件的实际类型
  如果目标目录数据量极大、重写成本过高，可直接进入Glue控制台编辑对应表的字段映射，将test_num字段从double调整为bigint（与Parquet中的INT64类型一一对应），保存后无需修改底层文件即可正常查询。该方案需提前确认字段实际数据无小数，避免改类型后出现精度丢失。
• Athena查询临时绕过类型检查
  针对临时取数场景，无需修改底层文件或表结构，直接在查询语句中通过CAST做类型转换即可绕过元数据校验，示例语句：

  SELECT
    CAST(test_num AS double) AS test_num
  FROM 你的Glue库名.你的表名
  

二、从源头避免后续出现同类问题的优化方案 #

• 读取CSV时显式指定字段类型，不依赖Spark自动schema推断
  Spark自动推断CSV字段类型时，碰到全为整数的数值列会优先识别为INT64，后续写出Parquet时容易出现元数据和预期类型不一致的问题。可在读取CSV时手动定义schema，强制将对应字段指定为double类型，示例代码：

  from pyspark.sql.types import StructType, StructField, DoubleType
  # 手动定义字段类型，跳过自动推断
  manual_schema = StructType([
    StructField("test_num", DoubleType(), nullable=True)
  ])
  csv_df = spark.read.schema(manual_schema).csv("s3://你的CSV源文件路径")
  

• 写Parquet时启用严格类型对齐配置
  写出Parquet文件时添加对应参数，关闭Spark的类型兼容逻辑，确保写出的元数据和实际存储类型完全一致，示例配置：

  csv_df.write \
    .option("spark.sql.parquet.writeLegacyFormat", "true") \
    .mode("overwrite") \
    .parquet("s3://你的Parquet存储路径")
  

常见踩坑提醒 #

• 重写Parquet文件时需要清空目标目录下的所有历史旧文件，避免目录中同时存在int64、double两种类型的同名字段文件，导致Glue Crawler识别schema时和实际文件不匹配。
• Athena对Parquet的元数据类型有严格校验，即使INT64和double存在数值上的隐式转换关系，只要物理存储类型和表定义不匹配，就会触发上述报错，无法通过普通配置跳过。

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