MapReduce仅Map任务单文件任务OOM故障处理方案问询

刚好碰到过类似的场景，给你一套落地性强的方案，完美适配你这种仅Map阶段的MapReduce作业需求：

1. 先搞定核心容错配置，让作业允许部分失败 #

首先得通过MR的内置参数，让作业不会因为单个Map任务OOM就直接挂掉，而是标记为成功但带警告：

• 设置mapreduce.map.failures.maxpercent为10（你有10个文件，刚好允许10%的Map任务失败，也就是1个异常文件的情况）。这个参数控制允许失败的Map任务占总任务数的比例，超过这个值作业才会彻底失败。
• 同时把mapreduce.job.fail-fast设为false，关闭快速失败模式，这样其他正常的Map任务能继续跑完，不会因为一个任务失败就全部终止。

你可以在作业提交代码里加这些配置：

Configuration conf = new Configuration();
conf.setInt("mapreduce.map.failures.maxpercent", 10);
conf.setBoolean("mapreduce.job.fail-fast", false);
// 其他作业相关配置（比如指定Mapper类、输入输出格式等）
Job job = Job.getInstance(conf, "Your_MapOnly_Job_Name");

或者提交作业时用命令行参数指定：

hadoop jar your-job-jar-file.jar com.your.package.YourMapperJob \
-Dmapreduce.map.failures.maxpercent=10 \
-Dmapreduce.job.fail-fast=false \
-Disolation.dir=/path/to/your/isolation/dir \
/input/source/dir /output/result/dir

2. 在Map任务里捕获OOM，顺便把异常文件移去隔离目录 #

因为OOM属于OutOfMemoryError（不是普通的Exception），得在Map代码里显式捕获它，同时拿到当前处理的文件路径，直接迁移到隔离目录：

public class YourCustomMapper extends Mapper<LongWritable, Text, Text, Text> {
    private FileSystem hdfs;
    private Path isolationDirPath;

    @Override
    protected void setup(Context context) throws IOException, InterruptedException {
        super.setup(context);
        Configuration conf = context.getConfiguration();
        hdfs = FileSystem.get(conf);
        // 从配置里拿提前指定的隔离目录路径
        isolationDirPath = new Path(conf.get("isolation.dir"));
        // 隔离目录不存在就自动创建
        if (!hdfs.exists(isolationDirPath)) {
            hdfs.mkdirs(isolationDirPath);
        }
    }

    @Override
    protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
        // 先拿到当前Map任务处理的文件路径
        Path currentProcessingFile = ((FileSplit) context.getInputSplit()).getPath();
        try {
            // 这里写你的正常业务处理逻辑
            // 比如解析文本、生成输出键值对等
            // ...
            context.write(outputKey, outputValue);
        } catch (OutOfMemoryError oomErr) {
            // 捕获到OOM了，赶紧把这个麻烦文件移去隔离目录
            Path targetIsolationPath = new Path(isolationDirPath, currentProcessingFile.getName());
            // 如果隔离目录里已经有同名文件，先删掉再迁移
            if (hdfs.exists(targetIsolationPath)) {
                hdfs.delete(targetIsolationPath, true);
            }
            hdfs.rename(currentProcessingFile, targetIsolationPath);
            
            // 打个醒目的警告日志，后面排查的时候一眼就能看到
            LOG.warn("⚠️ Map任务OOM触发！已将异常文件 {} 迁移至隔离目录 {}", currentProcessingFile, isolationDirPath);
            
            // 抛出中断异常，让MR框架把这个任务标记为失败，但不会影响整个作业
            throw new InterruptedException("OOM occurred, problematic file moved to isolation");
        }
    }
}

⚠️ 划重点：捕获OOM之后别硬撑着继续处理业务，直接迁移文件然后抛异常让任务失败就行，毕竟我们已经配置了允许部分失败，这样其他正常任务能顺利完成。

3. 作业完成后的状态与日志标记 #

• 作业跑完后，MR框架会把整体状态标记为SUCCEEDED，但在作业的Web UI或者日志里，会显示有1个Map任务失败，加上我们自己打印的警告日志，很容易就能知道哪个文件被隔离了。
• 你还可以在客户端的作业提交代码里加个判断，给使用者明确的警告提示：

boolean jobSuccess = job.waitForCompletion(true);
if (jobSuccess) {
    int failedMapTasks = job.getJobState().getFailedMaps();
    if (failedMapTasks > 0) {
        System.err.println("⚠️ 警告：作业已成功完成，但有 " + failedMapTasks + " 个Map任务因OOM失败，对应的异常文件已迁移至隔离目录");
    }
}

4. 一些额外注意事项 #

• 确保你的Map任务有足够的权限访问输入目录和隔离目录，不然迁移文件的时候会碰权限问题。
• 如果OOM发生在Mapper的setup或者cleanup阶段，记得在这些方法里也加对应的try-catch逻辑，确保能捕获到并迁移文件。
• 隔离目录里的文件别忘后续处理，比如分析为什么会OOM（是不是文件太大？格式有问题？），或者拆分大文件后重新跑作业。

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