MapReduce中的切片问题

MapReduce中的切片问题

先看一张图，MapReduce的数据流

输入的数据在分配给MapTask之前会被切片，数据切片是在逻辑上对数据进行分片。物理上并没有发生变化。有多少切片就有多少MapTask。
hadoop的HDFS把数据在物理上分块（block）存储，那么分块和切片之间是什么关系呢？
数据块：Block是HDFS物理上把数据分成一块一块。
数据切片：数据切片只是在逻辑上对输入进行分片，并不会在磁盘上将其切分成片进行存储。

1、TextInputFormat切片机制

系统默认的切片机制，切片大小默认是128M，该切片机制是对任务按文件规划切片，不管文件多小，都会是一个单独的切片，都会交给一个MapTask，这样如果有大量小文件，就会产生大量的MapTask，导致处理效率极其低下。具体来说，假设有两个文件，一个200M的文件和一个1M的文件。那么它们会被切分成几片？
200M>128M,所以被切分为一个128M和一个72M的切片。因为该机制下按文件规划切片，所以另一个1M的文件也被划分为一个切片，总共分为3个切片。当有大量小文件时，就需要大量的MapTask来处理这些文件。切片数量和MapTask数量是对等的。这样就影响了数据处理效率。那么有没有什么解决方法呢？

2、CombineTextInputFormat切片机制

CombineTextInputFormat用于小文件过多的场景，它可以将多个小文件从逻辑上规划到一个切片中，这样，多个小文件就可以交给一个MapTask处理。这就解决了上面的问题。

CombineTextInputFormat 切片机制过程包括：虚拟存储过程和切片过程二部分

假设 setMaxInputSplitSize 值为 4M，有如下四个文件
a.txt 1.7M
b.txt 5.1M
c.txt 3.4M
d.txt 6.8M

（1）虚拟存储过程
将输入目录下所有文件大小，依次和设置的 setMaxInputSplitSize 值比较：
（1.0）如果文件大于设置的最大值，且不大于最大值的两倍，均分存储
（1.1）如果不大于设置的最大值，逻辑上划分一个块。
（1.2）如果输入文件大于设置的最大值且大于两倍，那么以最大值切割一块，当剩余数据大小超过设置的最大值且不大于最大值2倍，此时将文件均分成2个虚拟存储块（防止出现太小切片）。
1.7M < 4M 划分一块
5.1M > 4M 但是小于 24M 划分二块：块1=2.55M，块2=2.55M
3.4M < 4M 划分一块
6.8M > 4M 但是小于 24M 划分二块：块1=3.4M，块2=3.4M
最终存储的文件：
1.7M
2.55M，2.55M
3.4M
3.4M，3.4M

（2）切片过程
（2.1）判断虚拟存储的文件大小是否大于 setlMaxIputSplitSize 值，大于等于则单独形成一个切片。
（2.2）如果不大于则跟下一个虚拟存储文件进行合并，共同形成一个切片。（这样分的切片都大于setlMaxIputSplitSize小于2* setlMaxIputSplitSize）
最终会形成3个切片：
（1.7+2.55）M，（2.55+3.4）M，（34+3.4）M
（这一部分来自他人博客）

3、KeyValueTextInputFormat切片机制

KeyValueTextInputFormat切片机制与TextInputFormat切片机制非常相似，都是以行读取数据，不同之处在于KeyValueTextInputFormat切片机制可以指定切割符，把一行内容按切割符分割为键值对。
比如：a-how are you,指定切割符为“-”，则形成键值对<a,how are you>。

4、NLineInputFormat切片机制

可以指定行数对文件进行切分，比如有个10行的文件，设置三行为一个切片，那么他就可以切出3，3，3，1这样四个切片。Mapper在读取文件的时候与TextInputFormat切片机制相同，一次读取一行。

5、自定义InputFormat切片机制

在处理数据时hadoop自带的切片机制不能满足需求，这时候就需要自定义切片。自定义切片机制时需要自定义一个类继承RecordReader用来读取文件。定义一个类继承InputFormat用来设置对输入文件的切片方式。

内容系个人学习随笔，难免错漏！！！