hadoop关于block方面的相关总结【转】
1.如何修改hdfs块大小?
2.修改之后,之前的block是否发生改变?
1.修改hdfs块大小的方法
在hdfs-site.xml文件中修改配置块大小的地方,dfs.block.size节点。
重启集群后,重新上传文件到hadoop集群上,新增的文件会按照新的块大小存储,旧的不会改变。
2.hadoop指定某个文件的blocksize,而不改变整个集群的blocksize
文件上传的时候,使用下面的命令即可
hadoop fs -D fs.local.block.size=134217728 -put local_name remote_location
参考
http://stackoverflow.com/questio ... -dfs-file-in-hadoop
经过验证,上述命令在0.21版本上不行,需要改为
hadoop dfs -D dfs.blocksize=134217728 -copyFromLocal local_name remote_location
3.hadoop的dfs.block.size分析
1、场景
map task的数目同split的数目相关(一般是相等),split的数目由map input文件的大小与dfs.block.size共同确定;
mapper、reducer消耗的内存、执行的效率也同其输入文件的大小紧密相关,而输入文件大小的上限是由dfs.block.size确定的;
dfs.block.size还同文件存储效率、容错、网络带宽消耗等相关(只是看文档提及过,没有深入学习呢)。
所以,有多种场景,是需要修改dfs.block.size的。我目前遇到的是场景2.
2、问题重现
hadoop fs -put local-file-path hadoop-file-path
执行mapreduce程序,发现由于split过小,map task 数目很多,每个执行时间都比较短,影响到效率
修改hadoop/conf/hdfs-site.xml(也可以放置在其他路径,通过-conf指定),设置dfs.block.size为64M
再次执行mapreduce程序,查看task的webUI界面,发现map input的大小仍然是512k左右(split不保证严格精确,趋近于block size);再查看当前job的webUI中的xml配置文件,发现dfs.block.size已经被修改为64M了。
3、问题分析
为什么 配置已经生效,但是hdfs中文件的分片貌似不变呢?使用下面的命令查看具体文件的分片效果:
% hadoop fsck /user/ms/hadoop-file-path -files -blocks -racks
发现其文件的分片的len不变,同修改配置之前一样。
查阅《OReilly.Hadoop.The.Definitive.Guide》,发现input的存放时候的分片实际上是在hadoop fs -put的时候执行的!
也就是说,修改dfs.block.size会影响到reducer的输入,但是map的输入,是不会被影响到的(如果没有重新put的话)。所以map的task num也不会变。
以上尝试的是把dfs.block.size从小改为大,那么如果是从大改为小呢?结论也是一样:没有影响到map 输入的分片大小。
所以,猜测,map的输入,是不计算block size,不尝试再分片的。直接从-input路径下读取分片好的blocks。
4、结论
如果修改dfs.block.size的目的是要影响map的input size,那么就需要重新put文件到input中去!