MR案例:小文件合并SequeceFile

SequeceFile是Hadoop API提供的一种二进制文件支持。这种二进制文件直接将<key, value>对序列化到文件中。可以使用这种文件对小文件合并,即将文件名作为key,文件内容作为value序列化到大文件中。这种文件格式有以下好处:

1). 支持压缩,且可定制为基于Record或Block压缩(Block级压缩性能较优)
2). 本地化任务支持:因为文件可以被切分,因此MapReduce任务时数据的本地化情况应该是非常好的。
3). 难度低:因为是Hadoop框架提供的API,业务逻辑侧的修改比较简单。

坏处:是需要一个合并文件的过程,且合并后的文件将不方便查看。

package test0820;

import java.io.IOException;
import java.io.InputStream;
import java.net.URI;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IOUtils;
import org.apache.hadoop.io.SequenceFile;
import org.apache.hadoop.io.Text;

public class TestSF {

    public static void main(String[] args) throws IOException, Exception{
        Configuration conf = new Configuration();

        FileSystem fs = FileSystem.get(new URI("hdfs://10.16.17.182:9000"), conf);
        //输入路径:文件夹        FileStatus[] files = fs.listStatus(new Path(args[0]));

        Text key = new Text();
        Text value = new Text();
        //输出路径:文件        SequenceFile.Writer writer = SequenceFile.createWriter(fs, conf, new Path(args[1]),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);
    }
}

注意,待完善的地方:以Block方式压缩。

时间: 2024-11-07 05:32:00

MR案例:小文件合并SequeceFile的相关文章

Hive merge(小文件合并)

当Hive的输入由很多个小文件组成时,如果不涉及文件合并的话,那么每个小文件都会启动一个map task. 如果文件过小,以至于map任务启动和初始化的时间大于逻辑处理的时间,会造成资源浪费,甚至发生OutOfMemoryError错误. 因此,当我们启动一个任务时,如果发现输入数据量小但任务数量多时,需要注意在Map前端进行输入小文件合并操作. 同理,向一个表写数据时,注意观察reduce数量,注意输出文件大小. 1. Map输入小文件合并 #每个Map处理的最大输入文件大小(256MB) s

HDFS小文件合并问题的优化:copyMerge的改进

1.问题分析 用fsck命令统计 查看HDFS上在某一天日志的大小,分块情况以及平均的块大小,即 [[email protected] jar]$ hadoop fsck /wcc/da/kafka/report/2015-01-11 DEPRECATED: Use of this script to execute hdfs command is deprecated. Instead use the hdfs command for it. 15/01/13 18:57:23 WARN ut

hive压缩之小文件合并

Hive压缩之二 小文件合并 调研背景 当Hive输入由很多个小文件组成,由于每个小文件都会启动一个map任务,如果文件过小,以至于map任务启动和初始化的时间大于逻辑处理的时间,会造成资源浪费,甚至OOM.为此,当我们启动一个任务,发现输入数据量小但任务数量多时,需要注意在Map前端进行输入合并.当然,在我们向一个表写数据时,也需要注意输出文件大小. 输入合并 合并输入小文件,减少map数? 主要的决定因素有: input的文件总个数,input的文件大小,集群设置的文件块大小. 举例: a)

HDFS操作及小文件合并

小文件合并是针对文件上传到HDFS之前 这些文件夹里面都是小文件 参考代码 package com.gong.hadoop2; import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FSDataInputStream; import or

将小文件合并大文件上传

自定义方法将本地多个小文件合并成一个大文件上传到HDFS上. package test; import java.net.URI; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FSDataInputStream; import org.apache.hadoop.fs.FSDataOutputStream; import org.apache.hadoop.fs.FileStatus; impo

hive小文件合并设置参数

Hive的后端存储是HDFS,它对大文件的处理是非常高效的,如果合理配置文件系统的块大小,NameNode可以支持很大的数据量.但是在数据仓库中,越是上层的表其汇总程度就越高,数据量也就越小.而且这些表通常会按日期进行分区,随着时间的推移,HDFS的文件数目就会逐渐增加. 小文件带来的问题 关于这个问题的阐述可以读一读Cloudera的这篇文章.简单来说,HDFS的文件元信息,包括位置.大小.分块信息等,都是保存在NameNode的内存中的.每个对象大约占用150个字节,因此一千万个文件及分块就

hadoop小文件合并

1.背景 在实际项目中,输入数据往往是由许多小文件组成,这里的小文件是指小于HDFS系统Block大小的文件(默认128M), 然而每一个存储在HDFS中的文件.目录和块都映射为一个对象,存储在NameNode服务器内存中,通常占用150个字节. 如果有1千万个文件,就需要消耗大约3G的内存空间.如果是10亿个文件呢,简直不可想象.所以在项目开始前, 我们选择一种适合的方案来解决本项目的小文件问题 2.介绍 本地 D:\data目录下有 2012-09-17 至 2012-09-23 一共7天的

hadoop 将HDFS上多个小文件合并到SequenceFile里

背景:hdfs上的文件最好和hdfs的块大小的N倍.如果文件太小,浪费namnode的元数据存储空间以及内存,如果文件分块不合理也会影响mapreduce中map的效率. 本例中将小文件的文件名作为key,其内容作为value生成SequenceFile 1.生成文件 //将目标目录的所有文件以文件名为key,内容为value放入SequenceFile中 //第一个参数是需要打包的目录,第二个参数生成的文件路径和名称 private static void combineToSequenceF

Facebook图片存储系统Haystack——存小文件,本质上是将多个小文件合并为一个大文件来降低io次数,meta data里存偏移量

转自:http://yanyiwu.com/work/2015/01/04/Haystack.html 一篇14页的论文Facebook-Haystack, 看完之后我的印象里就四句话: 因为[传统文件系统的弊端] 因为[缓存无法解决长尾问题] 所以[多个图片信息(Needle)存在同一个文件(SuperBlock)中] 所以[显著提高性能] 传统文件系统的弊端 传统的 POSIX 文件系统不适合高性能的图片存储, 主要原因是基于该文件系统来存储的话,是讲每个图片存储成某目录下的一个文件, 每次