您的位置:首页 > 运维架构

3.MR输入格式和分片相关

2015-12-11 11:13 197 查看
一个输入分片(split)就是由单个
map
处理的输入块。

每一个map操作只处理一个输入分片。

每个分片被划分为若干个记录,每条记录就是一个键/值对,map一个接一个地处理每条记录。

(输入分片—>若干个记录—>每条记录)

注:(一个split对应一个map)<一个块128m>默认一个split对一个块,所以导致一个块一个map的概念。但split数可改变,(见下)

一个map启动到关闭10-20s,分太多的话会导致得不偿失

//InputFormat  —>   //InputSplit 
 —>    //RecordReader

选择输入格式  然后分片。

最大的分片大小     计算公式:

max(minsize,min(maxisize,blocksize))

200M—>2block—>2split—>2map

200M—>…—>20split—>20map

文件被切片后(原本大文件就在不同的block上&&在不同的节点上),给各切片的节点上分发复制mr的jar程序,并启动节点上的jvm并运行map进程

IOUtils中read和readFull区别

1)、read(byte[] b)方法和readFully(byte []b)都是利用InputStream中read()方法,每次读取的也是一个字节,只是读取字节数组的方式不同。

2)、read(byte[] b)方法实质是读取流上的字节直到流上没有字节为止,如果当声明的字节数组长度大于流上的数据长度时就提前返回,而readFully(byte[] b)方法是读取流上指定长度的字节数组,也就是说如果声明了长度为len的字节数组,readFully(byte[]
b)方法只有读取len长度个字节的时候才返回,否则阻塞等待,如果超时,则会抛出异常 EOFException。

3)、那么当发送了长度为len的字节,那么为什么用read方法用户收不全呢,揪其原因发现消息在网络中传输是没那么理想的,我们发的那部分字节数组在传送过程中可能在接受信息方的缓存当中或者在传输线路,极端情况下可能在发送方的缓存当中,这样就不在流上,所以read方法提前返回了,这样就造成了各种错误。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  hadoop mapreduce