Amazon Athena分区修复失败求助：HIVE_PARTITION_SCHEMA_MISMATCH问题

我来帮你拆解并解决这个Glue和Athena的分区schema不匹配问题——我之前处理过类似的场景，咱们一步步来：

一、先解决手动添加分区的语法错误 #

你遇到的missing 'column' at 'partition'报错，是因为ALTER TABLE ADD PARTITION的语法不对。结合你之前把分区列类型从BIGINT改成STRING的操作，正确的语法应该给分区值加上单引号（因为STRING类型需要字符串字面量）：

ALTER TABLE mydb.mytable ADD PARTITION (partition_0='201711') LOCATION 's3://bucket/201711';
ALTER TABLE mydb.mytable ADD PARTITION (partition_0='201712') LOCATION 's3://bucket/201712';

执行这两句应该就能成功添加分区了。

二、解决MSCK REPAIR TABLE无法恢复分区的问题 #

MSCK REPAIR TABLE有时候在Glue元数据存储场景下，不会自动同步表的最新schema到新发现的分区，尤其是你修改过表schema之后。可以试试这几个方案：

• 换用Athena的RECOVER PARTITIONS命令：
  在Athena控制台执行：

  ALTER TABLE mydb.mytable RECOVER PARTITIONS;
  

  这个命令和MSCK逻辑类似，但在Glue集成的环境下兼容性更好，能更可靠地发现S3中的分区并同步元数据。

• 重新运行Glue爬虫：
  直接启动你之前用来爬取S3数据的Glue爬虫，指定只扫描目标表的S3路径（比如s3://bucket/）。爬虫会自动发现所有存在的分区，并且会让这些分区自动继承表的最新schema，从根源上解决schema不匹配的问题。

三、彻底避免后续出现分区schema不匹配的方法 #

修改表schema后，旧分区的元数据不会自动同步，这是Hive/Glue元数据模型的特性。要避免再踩坑，可以：

• 修改schema后同步所有分区：
  如果分区数量不多，手动执行ALTER TABLE mydb.mytable PARTITION (partition_0='XXXXXX') SET SERDEPROPERTIES (...)来同步每个分区的序列化属性；如果分区很多，可以用AWS CLI或Python脚本批量更新分区元数据。

• 删除旧分区后重新生成：
  像你之前那样删除所有旧分区，然后用RECOVER PARTITIONS或重新爬取的方式生成新分区，这样新分区会完全继承表的最新schema，不会出现不匹配的情况。

验证操作 #

完成上述步骤后，你可以：

1. 在Glue控制台查看表的分区列表，确认每个分区的schema和表的schema一致
2. 在Athena执行简单的查询语句（比如SELECT * FROM mydb.mytable LIMIT 10），验证是否还会出现HIVE_PARTITION_SCHEMA_MISMATCH错误

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