查询S3 Parquet文件报HIVE_BAD_DATA类型不兼容如何排查修复

不要靠pandas读DataFrame的dtype判断，pandas读取Parquet时会做自动类型兼容转换：原生INT64类型、全为整数值的DOUBLE类型，读入后都可能被转为float64，完全无法反映文件里的真实存储类型。
直接用下面两种方法查真实类型：

• 用pyarrow读取Parquet元数据，结果100%准确：

import pyarrow.parquet as pq

# 替换成你实际的S3文件路径
new_file_schema = pq.read_schema("s3://**/result_2022-06-16.gzip")
old_file_schema = pq.read_schema("s3://**/历史parquet文件路径.gzip")

print("新文件history字段原始类型:", new_file_schema.field("history").type)
print("历史文件history字段原始类型:", old_file_schema.field("history").type)

• 用命令行工具parquet-tools直接查看schema，执行parquet-tools schema 你的parquet文件路径，直接输出所有字段的原始存储类型，不需要写Python代码。

问题出在Parquet写入环节的自动类型推断逻辑：
你用pandas写Parquet时，依赖的pyarrow/fastparquet引擎会自动优化存储类型——哪怕DataFrame里history列的dtype是float64，如果当前文件里该列所有值都是1.0、2.0这种无小数位的整数值浮点，部分版本的写入引擎会自动把该列编码为INT64类型存储，减少文件体积；只要列里存在任意带小数位的值，就会按DOUBLE类型存储。
这也是为什么你读新旧文件的dtype都是float64：pandas读取时会把存成INT64的列自动转回float64，和你预期的类型对齐，把底层的类型差异藏掉了。

• 【推荐】写入时强制固定schema，从根源避免类型漂移
  后续写Parquet到S3时，不要让引擎自动推断类型，显式定义和Athena表完全对齐的固定schema：

import pyarrow as pa
import pyarrow.parquet as pq

# 按你的表结构定义固定schema，这里只示例history字段，其他字段按实际补充
write_schema = pa.schema([
    # 其他字段示例：("user_id", pa.string()), ("report_date", pa.date32()),
    ("history", pa.float64()) # 强制指定为双精度浮点，和Athena的double类型完全对应
])

# 转pyarrow表时传入固定schema，禁止自动类型推断
arrow_table = pa.Table.from_pandas(your_df, schema=write_schema, preserve_index=False)
# 按gzip压缩写入S3
pq.write_table(arrow_table, "s3://你的目标文件路径.gzip", compression="gzip")

• 修复已存在的异常文件
  找到所有history字段被存成INT64的Parquet文件，按上面的固定schema重新写入覆盖即可，不需要重跑全量历史数据。
• 【不推荐】Athena侧兼容
  如果暂时无法重写文件，可以把Athena表中history字段类型改为VARCHAR，查询时显式执行CAST(history AS DOUBLE)转换类型，但是会损失查询性能，后续写入还是可能出现类型问题，只适合临时救急。

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