2021-05-13

HDFS block的若干问题

1.小文件BLOCK占用

​ 小于block大小的小文件不会占用整个HDFS block空间，但是较多的小文件会占用更多的NAMENODE的内存（记录了文件的位置等信息）；再者，在文件处理时，可能会有较大的网络开销。

2.一个常被问到的一个问题是： 如果一个HDFS上的文件大小(file size) 小于块大小(block size) ，那么HDFS会实际占用Linux file system的多大空间？

答案：实际的文件大小，而非一个块的大小。

​ 1）可以使用命令来查看文件的实际占用情况，如 hadoop dfs -stat、hadoop fsck
如果hdfs占用Linux file system的磁盘空间按实际文件大小算，那么这个”块大小“有必要存在吗？其实块大小还是必要的，一个显而易见的作用就是当文件通过append操作不断增长的过程中，可以通过来block size决定何时split文件。以下是Hadoop Community的专家给我的回复： “The block size is a meta attribute. If you append to the file later, it still needs to know when to split further - so it keeps that value as a mere metadata it can use to advise itself on write boundaries.”

​ 2）一般情况下，任何磁盘都有‘最小读写单位’的概念，可以理解为该磁盘的‘block’。建立在该磁盘之上的文件系统也有‘block’的概念，一般为磁盘‘block’大小的整数倍。对于用户来说，这些读写限制都是透明的。（即，用户感觉自己可以读写任意大小的文件。）然而有些应用则是运行在文件系统block层级的，可以感知到block的存在，比如 df 和 fsck。

​ 3）HDFS 作为一种文件系统，当然也需要有‘block’的概念。不过HDFS的block一般比较大，默认为128MB。与普通的管理单个磁盘的文件系统一样，HDFS也将文件分割成block，每个block都作为一个独立的单元分别保存。不同点在于，在HDFS中，小于block的文件不会占用一个block的空间。（比如，文件大小为1MB，那么它会占用一个HDFS的block，但是只使用底层磁盘1MB的空间，而不是128MB。）

3.为什么HDFS的block相较于传统文件系统来说大很多

​ 1）因为HDFS的的一个设计目标就是能够快速读取。而对于磁盘来说，读取一个数据块涉及到三种时间开销，寻道时间、旋转时间和传输时间。传输时间是磁盘本身的特性，不可能通过人工手段来改变，但是对于寻道时间和旋转时间，则可以通过增大一次读取的数据量来减少寻道和旋转的次数。这样的话，就可以将读取数据的速率设计为接近真实的磁盘传输速率。

​ 2）举个例子，假设某磁盘的寻道时间和旋转时间之和为10ms，传输速率为100MB/s。那么，如果想设计一种读取方式让寻道时间与旋转时间总和 不高于总读取时间的1%的话，则需要将block的大小设置为100MB。

​ 3）当然，这个观点不可能长期成立。在MapReduce中，一个Map任务一般一次只处理一个block。那么，当Map任务的数量少于集群中节点的个数时，完成此job所需时间就会慢于其他情况

4.HDFS设置BLOCK的目的

​ 1）减少硬盘寻道时间(disk seek time)。HDFS设计前提是支持大容量的流式数据操作，所以即使是一般的数据读写操作，涉及到的数据量都是比较大的。假如数据块设置过少，那需要读取的数据块就比较多，由于数据块在硬盘上非连续存储，普通硬盘因为需要移动磁头，所以随机寻址较慢，读越多的数据块就增大了总的硬盘寻道时间。当硬盘寻道时间比io时间还要长的多时，那么硬盘寻道时间就成了系统的一个瓶颈。合适的块大小有助于减少硬盘寻道时间，提高系统吞吐量。
​ 2）减少Namenode内存消耗。对于HDFS，他只有一个Namenode节点，他的内存相对于Datanode来说，是极其有限的。然而，namenode需要在其内存FSImage文件中中记录在Datanode中的数据块信息，假如数据块大小设置过少，而需要维护的数据块信息就会过多，那Namenode的内存可能就会伤不起了。