EMR上Hive跨库复制分区表数据报错求助

你遇到的这个报错(States, Previous writer likely failed to write... so I am unlikely to write too)，通常是因为之前的写入操作异常中断，在目标分区目录留下了未清理的临时文件或锁资源，导致新的写入请求被阻塞。结合你执行的HQL语句，我整理了几个实用的排查和解决步骤：

第一步：清理目标分区的残留临时资源 #

Hive在写入数据时会生成以.hive-staging-开头的临时目录，如果之前的任务失败，这些目录可能没有被自动清理，会阻塞后续写入。

• 如果目标表是HDFS上的外部表，执行命令删除临时目录：

hdfs dfs -rm -r /your-target-table-path/load_date=2018-04-23/.hive-staging*

• 如果是S3上的外部表，可以通过AWS控制台或者CLI删除对应分区下的临时目录：

aws s3 rm s3://your-bucket/path/to/Target/exttbl_user_identification_details/load_date=2018-04-23/.hive-staging* --recursive

第二步：尝试覆盖写入而非追加 #

如果目标分区已经存在数据，且之前的写入残留了损坏数据，用insert overwrite强制覆盖分区数据，可能绕过残留问题：

insert overwrite Target.exttbl_user_identification_details PARTITION(load_date="2018-04-23") 
select * from Source.exttbl_user_identification_details;

⚠️ 注意：这个操作会删除目标分区的所有现有数据，执行前请确认数据可以被覆盖。

第三步：检查表权限与存储兼容性 #

因为你操作的是外部表（exttbl_前缀），需要确保：

• EMR集群的EC2实例角色拥有目标存储路径（S3/HDFS）的读写权限；
• 源表和目标表的存储格式完全一致（比如都是Parquet、ORC或TextFile）。可以用以下命令查看表的存储信息：

desc formatted Target.exttbl_user_identification_details;
desc formatted Source.exttbl_user_identification_details;

如果格式不一致，需要调整select语句适配格式，或者修改目标表的存储配置。

第四步：排查集群资源与任务日志 #

有时候集群资源不足（比如内存、CPU耗尽）也会导致写入失败：

• 登录EMR控制台，查看节点状态，是否有节点异常退出或资源使用率过高；
• 查看Hive任务的完整日志（EMR的Logs页面或HiveServer2日志），看看是否有OOM（内存溢出）等更具体的错误；
• 可以尝试调整Hive的资源参数，比如增大mapreduce.map.memory.mb和mapreduce.reduce.memory.mb，给任务更多资源。

第五步：验证源表数据完整性 #

如果源表本身存在损坏数据，读取时出错也会导致写入失败。先执行以下命令验证源表是否可以正常读取：

select count(*) from Source.exttbl_user_identification_details;

如果这个查询失败，需要先修复源表的问题（比如修复损坏的文件或分区）。

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