我正在尝试运行一个非常简单的 hadoop 作业。它是对经典 wordCount 的修改，它不计算单词，而是计算文件中的行数。我想用它来清理一堆我知道有重复的大日志文件(每个大约 70GB)。每行都是一条“记录”，因此我只想获取每条记录一次。

我知道我的代码是有效的，因为当我用小的普通文件运行它时，它做了它应该做的事情。当我用大文件运行它时，Hadoop 表现得很严格。首先，它开始在 MAP 阶段正常工作，该阶段通常可以毫无问题地达到 100%。然而，在处理 REDUCE 时，它永远不会超过 50%。它可能达到 40%，然后在显示一些“设备上没有剩余空间”异常后回到 0%:

FSError: java.io.IOException: No space left on device

然后它再次尝试执行 REDUCE，当它达到 40% 时，它再次下降到 0%，依此类推。当然，在决定以失败告终之前，它会执行 2 或 3 次。

不过，此异常的问题在于它与磁盘上的实际空间无关。磁盘空间永远不会变满。不是 HDFS 上的总(全局)空间，也不是每个节点中的单个磁盘。我检查 fs 状态:

$ hadoop dfsadmin -report > report

此报告从未显示实际节点达到 100%。事实上，没有任何节点能接近这一点。

我在每个节点上有大约 60GB 的可用磁盘，我在一个有 60 个数据节点的集群中运行它，这给我的总空间超过 3TB。我要处理的文件只有 70GB。

上网查了一下，可能是Hadoop在处理大量数据的同时创建了太多文件有关。原始的 wordCount 代码大大减少了数据(因为单词重复很多)。一个 70GB 的文件可以减少到只有 7MB 的输出。但是，我预计只会减少 1/3，或者大约 20-30GB 的输出。

Unix 类型的系统限制每个进程打开 1024 个文件:

$ ulimit -n
1024

如果 hadoop 创造的不止于此，那可能是个问题。我要求系统管理员将该限制增加到 65K，即现在的限制是:

$ ulimit -n
65000

问题不断。这可能是我需要进一步增加这个限制吗？这里还有其他事情吗？

非常感谢您的帮助!

代码在这里:

package ...;

import java.io.IOException;
import java.util.StringTokenizer;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.Mapper;
import org.apache.hadoop.mapreduce.Reducer;
import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;
import org.apache.hadoop.util.GenericOptionsParser;

public class LineCountMR {

  public static class MapperClass 
       extends Mapper<Object, Text, Text, IntWritable>{

    private final static IntWritable one = new IntWritable(1);
    private Text word = new Text();
    private String token = new String();        

    public void map(Object key, Text value, Context context
                    ) throws IOException, InterruptedException {

        token = value.toString().replace(' ', '_');
        word.set(token);
        context.write(word, one);   
    }
  }

  public static class ReducerClass 
       extends Reducer<Text,IntWritable,Text,IntWritable> {
    private IntWritable result = new IntWritable();

    public void reduce(Text key, Iterable<IntWritable> values, 
                       Context context
                       ) throws IOException, InterruptedException {
      int sum = 0;
      for (IntWritable val : values) {
        sum += val.get();
      }
      result.set(sum);
      context.write(key, result);
    }
 }

  public static void main(String[] args) throws Exception {
    Configuration conf = new Configuration();;
    if (args.length != 2) {
      System.err.println("Parameters: <in> <out>");
      System.exit(2);
    }
    Job job = new Job(conf, "line count MR");
    job.setJarByClass(LineCountMR.class);
    job.setMapperClass(MapperClass.class);
    job.setCombinerClass(ReducerClass.class);
    job.setReducerClass(ReducerClass.class);
    job.setOutputKeyClass(Text.class);
    job.setOutputValueClass(IntWritable.class);
    FileInputFormat.addInputPath(job, new Path(args[0]));
    FileOutputFormat.setOutputPath(job, new Path(args[1]));
    System.exit(job.waitForCompletion(true) ? 0 : 1);
  }
}

最佳答案

我在处理 10TB 数据时在集群上看到了这个问题。此问题与 HDFS 上的可用空间无关，而是与本地文件系统 (df -h) 上的可用空间有关，该文件系统用于存储在本地而非 HDFS 中存储的 map-reduce 操作期间生成的中间数据。

关于Hadoop 无法完成作业，因为 "No space left on device"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17710996/