hadoop无法完成作业,因为“设备上没有剩余空间”

blmhpbnm  于 2021-06-03  发布在  Hadoop
关注(0)|答案(2)|浏览(648)

我正在尝试运行一个非常简单的hadoop作业。它是对经典wordcount的一种修改,它不计算单词,而是计算文件中的行数。我想用它来清理一堆我知道有重复的大日志文件(每个大约70gb)。每一行都是一个“记录”,因此我只对每一条记录获取一次感兴趣。
我知道我的代码是有效的,因为当我用普通的小文件运行它时,它做了它应该做的事情。当我用大文件运行它时,hadoop的行为非常严格。首先,它在map阶段开始正确工作,通常达到100%,没有问题。然而,在处理reduce时,它从未超过50%。它可能达到40%,然后在显示一些“设备上没有剩余空间”异常后返回到0%:

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

然后,它试图再次降低,当它达到40%时,它再次下降到0%,以此类推。当然,在决定以失败告终之前,它会这样做两三次。
但这个例外的问题是,它不能与磁盘上的实际空间相关联。磁盘空间永远不会满。不是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);
  }
}
2jcobegt

2jcobegt1#

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

kdfy810k

kdfy810k2#

在我的例子中是hadoop缓存目录

ubuntu@ip-*-*-*-*:/tmp/hadoop-ubuntu/mapred/local/localRunner/ubuntu/jobcache

清理一下就解决了问题。

相关问题