小文件的解决方案

  小文件指的是那些size比HDFS的block size(默认64M)小的多的文件。任何一个文件,目录和block,在HDFS中都会被表示为一个object存储在namenode的内存中,每一个object占用150 bytes的内存空间。所以,如果有10million个文件,每一个文件对应一个block,那么就将要消耗namenode 3G的内存来保存这些block的信息。如果规模再大一些,那么将会超出现阶段计算机硬件所能满足的极限。

 解决小文件的四种解决方案:

  1.应用程序自己控制

  2.archive

  3.Sequence File / Map File

  4.合并小文件,如HBase部分的compact

  5.CombineFileInputFormat

应用程序自己控制:

    final Path path = new Path("/combinedfile");
        final FSDataOutputStream create = fs.create(path);
        final File dir = new File("C:\\Windows\\System32\\drivers\\etc");
        for(File fileName : dir.listFiles()) {
            System.out.println(fileName.getAbsolutePath());
            final FileInputStream fileInputStream = new FileInputStream(fileName.getAbsolutePath());
            final List<String> readLines = IOUtils.readLines(fileInputStream);
            for (String line : readLines) {
                create.write(line.getBytes());
            }
            fileInputStream.close();
        }
        create.close();

Hadoop Archives:

  Hadoop Archives (HAR files)是在0.18.0版本中引入的,它的出现就是为了缓解大量小文件消耗namenode内存的问题。HAR文件是通过在HDFS上构建一个层次化的文件系统来工作。一个HAR文件是通过hadoop的archive命令来创建,而这个命令实 际上也是运行了一个MapReduce任务来将小文件打包成HAR。对于client端来说,使用HAR文件没有任何影响。所有的原始文件都 (using har://URL)。但在HDFS端它内部的文件数减少了。

  通过HAR来读取一个文件并不会比直接从HDFS中读取文件高效,而且实际上可能还会稍微低效一点,因为对每一个HAR文件的访问都需要完成两层 index文件的读取和文件本身数据的读取。并且尽管HAR文件可以被用来作为MapReduce job的input,但是并没有特殊的方法来使maps将HAR文件中打包的文件当作一个HDFS文件处理。

  创建文件 hadoop archive -archiveName xxx.har -p /src /dest

    

  查看内部结构 hadoop fs -lsr /dest/xxx.har

    

    _SUCCESS标示执行成功,_index标示索引文件
    命令本身是不删源文件的,谁去执行archive,谁去删

  查看内容 hadoop fs -lsr har:///dest/xxx.har

    

SequenceFile:

  通常对于“the small files problem”的回应会是:使用SequenceFile。这种方法是说,使用filename作为key,并且file contents作为value。实践中这种方式非常管用。回到10000个100KB的文件,可以写一个程序来将这些小文件写入到一个单独的 SequenceFile中去,然后就可以在一个streaming fashion(directly or using mapreduce)中来使用这个sequenceFile。不仅如此,SequenceFiles也是splittable的,所以mapreduce 可以break them into chunks,并且分别的被独立的处理。和HAR不同的是,这种方式还支持压缩。block的压缩在许多情况下都是最好的选择,因为它将多个 records压缩到一起,而不是一个record一个压缩。

  

  在存储结构上,SequenceFile主要由一个Header后跟多条Record组成。

  Header主要包含了Key classname,Value classname,存储压缩算法,用户自定义元数据等信息,此外,还包含了一些同步标识,用于快速定位到记录的边界。

  每条Record以键值对的方式进行存储,用来表示它的字符数组可依次解析成:记录的长度、Key的长度、Key值和Value值,并且Value值的结构取决于该记录是否被压缩。

  数据压缩有利于节省磁盘空间和加快网络传输,SeqeunceFile支持两种格式的数据压缩,分别是:record compression和block compression。

  record compression如上图所示,是对每条记录的value进行压缩 block compression是将一连串的record组织到一起,统一压缩成一个block,如上图。

  block信息主要存储了:块所包含的记录数、每条记录Key长度的集合、每条记录Key值的集合、每条记录Value长度的集合和每条记录Value值的集合

  注:每个block的大小是可通过io.seqfile.compress.blocksize属性来指定的。

  工作中我们使用的是SeqenceFile的block压缩,SquenceFile存在的意义:解决小文件,延迟特别大

       /**
             * 写入SequenceFile文件
             */
            Configuration conf = new Configuration();
            FileSystem fs = getFileSystem();
            FileStatus[] files = fs.listStatus(new Path("/dir1/"));
            Text key = new Text();
            Text value = new Text();
            Path outpath = new Path("/dir1/seqFile.seq");
            SequenceFile.Writer writer = SequenceFile.createWriter(fs, conf, outpath,key.getClass() , value.getClass());
            InputStream in = null;
            byte[] buffer = null;
            for(int i=0;i<files.length;i++){
                key.set(files[i].getPath().getName());
                in = fs.open(files[i].getPath());
                buffer = new byte[(int) files[i].getLen()];
                IOUtils.readFully(in, buffer, 0, buffer.length);
                value.set(buffer);
                IOUtils.closeStream(in);
                System.out.println(key.toString()+"\n"+value.toString());
                writer.append(key, value);
            }
            IOUtils.closeStream(writer);
            /**
             * 读取SequenceFile文件
             */
            SequenceFile.Reader reader = null;
            try {
              reader = new SequenceFile.Reader(fs, outpath, conf);//返回 SequenceFile.Reader 对象
              ReflectionUtils.newInstance(reader.getKeyClass(), conf);//getKeyClass()获得Sequence中使用的类型
                ReflectionUtils.newInstance(reader.getValueClass(), conf);//同上
              long position = reader.getPosition();
              while (reader.next(key, value)) { //next()方法迭代读取记录 直到读完返回false
                String syncSeen = reader.syncSeen() ? "*" : "";//替换特殊字符 同步
                System.out.printf("[%s%s]\t%s\t%s\n", position, syncSeen, key, value);
                position = reader.getPosition(); // beginning of next record
              }  

  /**  *第二种方式  */

    Configuration conf=new Configuration();
    FileSystem fs=getFileSystem();
    Path seqFile=new Path("/dir1/seqFile.seq");
    //Reader内部类用于文件的读取操作
    SequenceFile.Reader reader=new SequenceFile.Reader(fs,seqFile,conf);
    //Writer内部类用于文件的写操作,假设Key和Value都为Text类型
    SequenceFile.Writer writer=new SequenceFile.Writer(fs,conf,seqFile,Text.class,Text.class);
    //通过writer向文档中写入记录
    writer.append(new Text("key"),new Text("value"));
    IOUtils.closeStream(writer);//关闭write流
    //通过reader从文档中读取记录
    Text key=new Text();
    Text value=new Text();
    while(reader.next(key,value)){
      System.out.println(key);
      System.out.println(value);
    }
    IOUtils.closeStream(reader);//关闭read流

MapFile:

  MapFile是基于SequenceFile,和SequenceFile的区别:排序后的SequenceFile.由两部分组成,Data和Index.

  MapFile是排序后的SequenceFile,通过观察其目录结构可以看到MapFile由两部分组成,分别是data和index。

  index作为文件的数据索引,主要记录了每个Record的key值,以及该Record在文件中的偏移位置。在MapFile被访问的时候,索引文件会被加载到内存,通过索引映射关系可迅速定位到指定Record所在文件位置,因此,相对SequenceFile而言,MapFile的检索效率是高效的,缺点是会消耗一部分内存来存储index数据。

  需注意的是,MapFile并不会把所有Record都记录到index中去,默认情况下每隔128条记录存储一个索引映射。当然,记录间隔可人为修改,通过MapFIle.Writer的setIndexInterval()方法,或修改io.map.index.interval属性;

  另外,与SequenceFile不同的是,MapFile的KeyClass一定要实现WritableComparable接口,即Key值是可比较的。

       Configuration conf=new Configuration();
            FileSystem fs=FileSystem.get(conf);
            Path mapFile=new Path("/dir1/mapFile.map");
            //Writer内部类用于文件的写操作,假设Key和Value都为Text类型
            MapFile.Writer writer=new MapFile.Writer(conf,fs,mapFile.toString(),Text.class,Text.class);
            //通过writer向文档中写入记录
            writer.append(new Text("key"),new Text("value"));
            IOUtils.closeStream(writer);//关闭write流
            //Reader内部类用于文件的读取操作
            MapFile.Reader reader=new MapFile.Reader(fs,mapFile.toString(),conf);
            //通过reader从文档中读取记录
            Text key=new Text();
            Text value=new Text();
            while(reader.next(key,value)){
                System.out.println(key);
                System.out.println(value);
            }
            IOUtils.closeStream(reader);//关闭read流

    什么时候会用MapFile和SequenceFile:对小文件的处理使用SequenceFile或MapFile,对检索要求比较高使用MapFile.老的Hbase底层就是用MapFile存储数据的.

集群间复制

  在不同集群之间复制数据:hadoop disco hdfs://hadoop1:9000/out.har hdfs://hadoop2:9000/
  在什么情况下会用:一个集群压力大了,存储数据存不了了
  hdfs会在什么情况下说存储不了数据了:nameNoe的内存满了

时间: 2024-10-07 11:30:45

小文件的解决方案的相关文章

Hadoop对小文件的解决方案

小文件指的是那些size比HDFS的block size(默认64M)小的多的文件.任何一个文件,目录和block,在HDFS中都会被表示为一个object存储在namenode的内存中, 每一个object占用150 bytes的内存空间.所以,如果有10million个文件, 每一个文件对应一个block,那么就将要消耗namenode 3G的内存来保存这些block的信息.如果规模再大一些,那么将会超出现阶段计算机硬件所能满足的极限. 控制小文件的方法有: 1.应用程序自己控制 2.arc

大数据-Hadoop小文件问题解决方案

HDFS中小文件是指文件size小于HDFS上block(dfs block size)大小的文件.大量的小文件会给Hadoop的扩展性和性能带来严重的影响.HDFS中小文件是指文件size小于HDFS上block大小的文件.大量的小文件会给Hadoop的扩展性和性能带来严重的影响. 大数据学习群:716581014 小文件是如何产生的? 动态分区插入数据,产生大量的小文件,从而导致map数量剧增 reduce数量越多,小文件也越多,reduce的个数和输出文件个数一致 数据源本身就是大量的小文

HDFS2&mdash;SequenceFile(小文件的解决方案)

1.这种方法是说,使用filename作为key,并且file contents作为value.实践中这种方式非常管用. 2.和HAR不同的是,这种方式还支持压缩. 3.block的压缩在许多情况下都是最好的选择,因为它将多个 records压缩到一起,而不是一个record一个压缩. 4.在存储结构上,SequenceFile主要由一个Header后跟多条Record组成. 5.Header主要包含了Key classname,Value classname,存储压缩算法,用户自定义元数据等信

Hadoop的小文件解决方案

小文件指的是那些size比HDFS的block size(默认64M)小的多的文件.任何一个文件,目录和block,在HDFS中都会被表示为一个object存储在namenode的内存中,每一个object占用150bytes的内存空间.所以,如果有10million(一千万)个文件,每一个文件对应一个block,那么就将要消耗namenode3G的内存来保存这些block的信息,如果规模再大一些,那么将会超出现阶段计算机硬件所能满足的极限. 相同大小下,小文件越多,对namenode造成的内存

关于rsync删除大量小文件的问题?

关于网上大量的rsync删除100w小文件的解决方案.博主两台虚拟机,每个目录下有100w个小文件,以下分别为rm和rsync两种删除方法 rm 环境:CentOS release 5.8 ,内存1G,处理器单核,硬盘30G 使用rsync删除,环境:CentOS release 6.5,内存500M,处理器单核,硬盘30G 开始怀疑网上看文章的人都有尝试过么?然后在看看两台机子的配置,调高了rsync所在机子的内存为1G,环境:CentOS release 6.5,内存1G,处理器单核,硬盘3

Hive优化之小文件问题及其解决方案

小文件是如何产生的 1.动态分区插入数据,产生大量的小文件,从而导致map数量剧增. 2.reduce数量越多,小文件也越多(reduce的个数和输出文件是对应的). 3.数据源本身就包含大量的小文件. 小文件问题的影响 1.从Hive的角度看,小文件会开很多map,一个map开一个JVM去执行,所以这些任务的初始化,启动,执行会浪费大量的资源,严重影响性能. 2.在HDFS中,每个小文件对象约占150byte,如果小文件过多会占用大量内存.这样NameNode内存容量严重制约了集群的扩展. 小

[Hadoop]大量小文件问题及解决方案

1. HDFS上的小文件问题 小文件是指文件大小明显小于HDFS上块(block)大小(默认64MB)的文件.如果存储小文件,必定会有大量这样的小文件,否则你也不会使用Hadoop(If you're storing small files, then you probably have lots of them (otherwise you wouldn't turn to Hadoop)),这样的文件给hadoop的扩展性和性能带来严重问题.当一个文件的大小小于HDFS的块大小(默认64MB

Hive之小文件问题及其解决方案

小文件如何产生 1.动态分区插入数据,产生大量小文件,导致map数剧增 2.Reduce数越多,小文件越多 3.数据直接导入小文件 小文件的影响 从hive的角度看,小文件会开很多map,一个map开一个jvm去执行,所以这些任务的初始化,启动,执行浪费大量资源,严重影响集群性能 在HDFS中,每个小文件对象越占150byte,如果小文件过多会占用大量内存.这样namenode内存容量严重制约了集群的扩展. 解决思路 使用sequence file作为表的存储格式,不要用TextFile 减少R

大数据技术之_05_Hadoop学习_04_MapReduce_Hadoop企业优化(重中之重)+HDFS小文件优化方法+MapReduce扩展案例+倒排索引案例(多job串联)+TopN案例+找博客共同粉丝案例+常见错误及解决方案

第6章 Hadoop企业优化(重中之重)6.1 MapReduce 跑的慢的原因6.2 MapReduce优化方法6.2.1 数据输入6.2.2 Map阶段6.2.3 Reduce阶段6.2.4 I/O传输6.2.5 数据倾斜问题6.2.6 常用的调优参数6.3 HDFS小文件优化方法6.3.1 HDFS小文件弊端6.3.2 HDFS小文件解决方案第7章 MapReduce扩展案例7.1 倒排索引案例(多job串联)7.2 TopN案例7.3 找博客共同粉丝案例第8章 常见错误及解决方案 第6章