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

一个输入分片 (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方法提前返回了,这样就造成了各种错误。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值