Athena 3执行含特定字符串WHERE子句查询时出现HIVE_CURSOR_ERROR求助

问题根源分析 #

Athena v3基于Trino引擎，相比v2的Presto，对Parquet文件的类型校验更严格。你的情况大概率是以下原因之一：

• 部分Parquet文件中id_enabled字段实际混存了布尔值（true）和字符串值（'false'/'inactive'），v2能兼容隐式转换，v3则直接触发读取错误；
• 表的元数据定义（string类型）与部分Parquet文件的字段实际类型不匹配；
• 存在损坏的Parquet数据块，仅当匹配'true'时触发读取。

根本解决办法 #

1. 校验并修正表元数据 #

• 用Parquet工具查看文件的实际字段类型（可下载单个文件到本地执行）：

  parquet-tools schema your-file.parquet
  

• 如果发现字段类型不统一，用AWS Glue爬虫重新扫描表所在S3路径，自动同步正确的元数据；或者手动更新表结构：

  ALTER TABLE db.table CHANGE COLUMN id_enabled id_enabled STRING;
  

• 刷新表分区和元数据：

  MSCK REPAIR TABLE db.table;
  

2. 重写表数据，统一字段类型 #

创建临时表，强制将id_enabled转换为字符串类型后重新存储：

-- 创建临时表存储转换后的数据
CREATE TABLE db.table_temp WITH (format = 'Parquet') AS
SELECT
  -- 保留其他所有字段
  col1, col2, ...,
  -- 强制转换为字符串，确保类型统一
  CAST(id_enabled AS VARCHAR) AS id_enabled
FROM db.table;

-- 备份原表后替换（谨慎操作，先确认数据无误）
DROP TABLE db.table;
ALTER TABLE db.table_temp RENAME TO db.table;

3. 定位并修复损坏文件 #

通过$path字段找到触发错误的具体文件：

SELECT DISTINCT "$path" FROM db.table WHERE id_enabled LIKE '%true%';

找到对应S3文件后，检查是否损坏：

• 如果是冗余数据，直接删除；
• 如果是有效数据，重新生成该文件（从源头重新导出或修复）。

临时方案说明 #

id_enabled like '%true%'能生效是因为模糊匹配时，Athena可能跳过了严格的类型校验逻辑，仅读取可解析的数据块，但这会带来性能损耗和数据不准确的风险，不建议长期使用。

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