AWS Athena执行原正常查询报HIVE_CURSOR_ERROR错误

问题场景 #

在AWS Athena运行查询任务时，同一段此前可正常执行的查询语句，当前运行抛出错误：

HIVE_CURSOR_ERROR: HIVE_CURSOR_ERROR
规则说明：查询语句未明确指定目标数据库时，默认针对mytable数据库执行。

根因说明 #

该错误属于Athena底层数据读取阶段的游标异常，触发原因均和元数据、数据源的一致性相关，和查询语法本身无关（同语法历史可正常执行即可排除语法问题）。

排查修复步骤 #

• 校验底层数据源完整性与权限
  首先定位mytable关联的S3存储路径，检查三类异常：
  1. 路径下是否存在损坏文件、格式与表定义不匹配的文件（比如表定义为Parquet格式但混入了未上传完成的临时文件、其他格式的日志文件）
  2. Athena关联的服务角色是否仍持有该S3路径的读权限、S3存储桶的桶策略是否近期做过调整拦截了Athena的访问
  3. 路径下是否存在被意外删除的文件，导致元数据记录的文件不存在
     验证方式：执行最小化查询SELECT * FROM mytable LIMIT 10，如果该查询也报相同错误，可确定是全表层面的数据源异常。
• 核对表结构元数据一致性
  执行SHOW CREATE TABLE mytable导出当前表的完整定义，和查询正常运行时的历史表定义比对，重点检查：字段类型是否被修改、序列化/反序列化（SerDe）配置是否变更、表关联的S3路径是否被改动。schema和底层文件结构不匹配时，会直接触发游标读取失败。
• 修复分区表元数据偏差
  如果mytable为分区表，优先检查近期新增的分区：是否存在手动添加的分区路径下无有效数据文件、分区字段值和路径层级不匹配的问题。可执行MSCK REPAIR TABLE mytable全量同步分区元数据后重试查询；如果数据量较大，可逐个查询新增分区定位触发错误的具体分区，删除异常分区后重新添加即可。
• 定位特定字段触发的读取异常
  如果全表简单查询正常、仅特定复杂查询报错，可逐步简化查询语句，逐列增加查询字段，定位到触发错误的具体字段，重点检查嵌套结构字段、JSON类型字段的定义是否和实际存储的内容格式匹配。

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