太懂这种被S3拖慢Hive作业的糟心感了！之前帮好几个EMR用户排查过类似问题——Hive默认那套「先写临时目录再移动到目标S3」的逻辑，在对象存储上完全是性能杀手，毕竟S3的「移动」本质是复制+删除，和HDFS的元数据操作根本不是一个量级。针对你的问题，给你几个从根本上优化的方案：

1. 把临时目录直接放到S3上（根治移动瓶颈） #

这是最核心的优化，别让Hive在HDFS写临时文件再跨存储移动了。直接配置以下参数，让临时目录和目标表同区域S3路径：

SET hive.exec.stagingdir=s3://your-bucket/path/to/hive-staging/;
SET hive.s3.staging-directory=s3://your-bucket/path/to/s3-staging/;

这样Hive会直接在S3上完成临时写入和最终移动，避免跨存储的数据传输，速度会提升一大截。如果是分区表，记得同时开启动态分区非严格模式：

SET hive.exec.dynamic.partition.mode=nonstrict;

2. 优化文件移动的并发能力（针对Cloudera提到的参数） #

你说的hive.mv.files.threads确实有用，但得配合上面的S3临时目录一起用才见效。默认这个参数值很低（比如1），可以调到10-20（根据集群CPU/内存资源调整，别贪高导致资源竞争），同时开启Hive并行执行：

SET hive.mv.files.threads=15;
SET hive.exec.parallel=true;

这样移动文件时能多线程并发处理，减少等待时间。

3. 利用EMR专属的S3优化特性 #

AWS EMR本身对S3有不少优化，开启这些参数能进一步提升写入效率：

• 开启S3A快速上传，用多部分上传减少请求次数：

SET fs.s3a.fast.upload=true;

• 调整多部分上传的块大小（比如设为100MB，根据你的数据大小调整）：

SET fs.s3a.multipart.size=104857600;

4. 减少小文件数量，降低移动成本 #

小文件多不仅拖慢移动，还会增加S3的请求开销。可以通过以下参数合并小文件：

-- 合并Map阶段生成的小文件
SET hive.merge.mapfiles=true;
-- 合并Reduce阶段生成的小文件
SET hive.merge.mapredfiles=true;
-- 每个任务合并后的文件大小（比如256MB）
SET hive.merge.size.per.task=268435456;

另外，尽量用列式存储格式（ORC/Parquet），这类格式本身会生成更大、更高效的文件，同时压缩率高，进一步减少数据量。

5. 替代方案：用Spark SQL写入S3 #

如果Hive的优化还是达不到预期，试试Spark SQL——它对S3的写入逻辑更友好，不需要依赖Hive那套临时目录机制，并发度更高，写入速度通常比Hive快2-3倍。EMR上切换也很简单，直接把你的HiveQL改成Spark SQL执行就行，或者用Spark读取Hive表后直接写入S3外部表。

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