MapReduce shuffle阶段数据的压缩机制

介绍

在shuffle阶段，可以看到数据通过大量的拷贝，从map阶段输出的数据，都要通过网络拷贝，发送到reduce阶段，这一过程中，涉及到大量的网络IO，如果数据能够进行压缩，那么数据的发送量就会少得多，那么如何配置hadoop的文件压缩呢，以及hadoop当中的文件压缩支持哪些压缩算法呢？？接下来一一细看

MapReduce的执行流程
为什么要配置压缩：
MapReduce
input
mapper
shuffle
partitioner、sort、combiner、【compress】、group
reducer
output

hadoop当中支持的压缩算法

文件压缩有两大好处，节约磁盘空间，加速数据在网络和磁盘上的传输
前面hadoop的版本经过重新编译之后，可以看到hadoop已经支持所有的压缩格式了，剩下的问题就是该如何选择使用这些压缩格式来对MapReduce程序进行压缩
可以使用bin/hadoop checknative 来查看编译之后的hadoop支持的各种压缩，如果出现openssl为false，那么就在线安装一下依赖包
bin/hadoop checknative
yum install openssl-devel

hadoop支持的压缩算法

压缩格式	工具	算法	文件扩展名	是否可切分
DEFLATE	无	DEFLATE	.deflate	否
Gzip	gzip	DEFLATE	.gz	否
bzip2	bzip2	bzip2	bz2	是
LZO	lzop	LZO	.lzo	否
LZ4	无	LZ4	.lz4	否
Snappy	无	Snappy	.snappy	否

各种压缩算法对应使用的java类

压缩格式	对应使用的java类
DEFLATE	org.apache.hadoop.io.compress.DeFaultCodec
gzip	org.apache.hadoop.io.compress.GZipCodec
bzip2	org.apache.hadoop.io.compress.BZip2Codec
LZO	com.hadoop.compression.lzo.LzopCodec
LZ4	org.apache.hadoop.io.compress.Lz4Codec
Snappy	org.apache.hadoop.io.compress.SnappyCodec

常见的压缩速率比较

压缩算法	原始文件大小	压缩后的文件大小	压缩速度	解压缩速度
gzip	8.3GB	1.8GB	17.5MB/s	58MB/s
bzip2	8.3GB	1.1GB	2.4MB/s	9.5MB/s
LZO-bset	8.3GB	2GB	4MB/s	60.6MB/s
LZO	8.3GB	2.9GB	49.3MB/S	74.6MB/s

snappy比以上压缩算法都要快

1、如何开启压缩：

• 方式一：在代码中进行设置压缩

设置map阶段的压缩
Configuration configuration = new Configuration();
configuration.set("mapreduce.map.output.compress","true");
configuration.set("mapreduce.map.output.compress.codec","org.apache.hadoop.io.compress.SnappyCodec");
设置reduce阶段的压缩
configuration.set("mapreduce.output.fileoutputformat.compress","true");
configuration.set("mapreduce.output.fileoutputformat.compress.type","RECORD");
configuration.set("mapreduce.output.fileoutputformat.compress.codec","org.apache.hadoop.io.compress.SnappyCodec");

• 方式二：配置全局的MapReduce压缩

修改mapred-site.xml配置文件，然后重启集群，以便对所有的mapreduce任务进行压缩

map输出数据进行压缩
<property>
          <name>mapreduce.map.output.compress</name>
          <value>true</value>
</property>
<property>
         <name>mapreduce.map.output.compress.codec</name>
         <value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>


reduce输出数据进行压缩
<property>       <name>mapreduce.output.fileoutputformat.compress</name>
       <value>true</value>
</property>
<property>         <name>mapreduce.output.fileoutputformat.compress.type</name>
        <value>RECORD</value>
</property>
 <property>        <name>mapreduce.output.fileoutputformat.compress.codec</name>
        <value>org.apache.hadoop.io.compress.SnappyCodec</value> </property>

所有节点都要修改mapred-site.xml，修改完成之后记得重启集群

2、使用hadoop的snappy压缩来对数据进行压缩

第一步： 代码中添加配置

这里通过修改代码的方式来实现数据的压缩
map阶段输出压缩配置

Configuration configuration = new Configuration();
configuration.set("mapreduce.map.output.compress","true");
configuration.set("mapreduce.map.output.compress.codec","org.apache.hadoop.io.compress.SnappyCodec");

reduce阶段输出压缩配置

configuration.set("mapreduce.output.fileoutputformat.compress","true");
configuration.set("mapreduce.output.fileoutputformat.compress.type","RECORD");
configuration.set("mapreduce.output.fileoutputformat.compress.codec","org.apache.hadoop.io.compress.SnappyCodec");

第二步：重新打包测试mr程序

会发现MR运行之后的输出文件都变成了以.snappy的压缩文件

Federation一个典型的例子就是上面提到的NameNode内存过高问题,完全可以将上面部分大的文件目录移到另外一个NameNode上做管理.更重要的一点在于,这些NameNode是共享集群中所有的DataNode的,它们还是在同一个集群内的。
这时候在DataNode上就不仅仅存储一个Block Pool下的数据了,而是多个(在DataNode的datadir所在目录里面查看BP-xx.xx.xx.xx打头的目录)。
概括起来：
多个NN共用一个集群里的存储资源，每个NN都可以单独对外提供服务。
每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储。
DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况。
HDFS Federation不足
HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个，但是从单个namenode/namespace看，仍然存在单点故障：如果某个namenode挂掉了，其管理的相应的文件便不可以访问。Federation中每个namenode仍然像之前HDFS上实现一样，配有一个secondary namenode，以便主namenode挂掉一下，用于还原元数据信息。
所以一般集群规模真的很大的时候，会采用HA+Federation的部署方案。也就是每个联合的namenodes都是ha的。