HDFS中数据块概念及设置大小的学问

HDFS数据块：

与一般文件系统一样，HDFS也有块（block）的概念，HDFS上的文件也被划分为块大小的多个分块作为独立的存储单元。

与通常的磁盘文件系统不同的是：

HDFS中小于一个块大小的文件不会占据整个块的空间（当一个1MB的文件存储在一个128MB的块中时，文件只使用1MB的磁盘空间，而不是128MB）

设置数据块的好处：

（1）一个文件的大小可以大于集群任意节点磁盘的容量

（2）容易对数据进行备份，提高容错能力

（3）使用抽象块概念而非整个文件作为存储单元，大大简化存储子系统的设计

问题：HDFS里面为什么一般设置块大小为64MB或128MB？

为什么不能远少于64MB？

（1）减少硬盘寻道时间。HDFS设计前提是应对大数据量操作，若数据块大小设置过小，那需要读取的数据块数量就会增多，从而间接增加底层硬盘的寻道时间

（2）减少NameNode内存消耗。由于NameNode记录着DataNode中的数据块信息，若数据块大小设置过小，则数据块数量增多，需要维护的数据块信息就会增多，从而消耗NameNode的内存。

为什么不能远大于64MB？

原因主要从上层的MapReduce框架来寻找。

（1）Map崩溃问题。系统需要重新启动，启动过程中需要重新加载数据，数据块越大，数据加载时间越长，系统恢复过程越长

（2）监管时间问题。主节点监管其他节点的情况，每个节点会周期性的与主节点进行汇报通信。倘若某一个节点保持沉默的时间超过一个预设的时间间隔，主节点会记录这个节点状态为死亡，并将该节点的数据转发给别的节点。而这个“预设时间间隔”是从数据块的角度大致估算的。（加入对64MB的数据块，我可以假设你10分钟之内无论如何也能解决完了吧，超过10分钟还没反应，那我就认为你出故障或已经死了。）64MB大小的数据块，其时间尚可较为精准地估计，如果我将数据块大小设为640MB甚至上G，那这个“预设的时间间隔”便不好估算，估长估短对系统都会造成不必要的损失和资源浪费。

（3）问题分解问题。数据量的大小与问题解决的复杂度呈线性关系。对于同一个算法，处理的数据量越大，时间复杂度越高。

（4）约束Map输出。在Map Reduce框架里，Map之后的数据是要经过排序才执行Reduce操作的。这通常涉及到归并排序，而归并排序的算法思想便是“对小文件进行排序，然后将小文件归并成大文件”，因此“小文件”不宜过大。

HDFS的块设置的如此之大主要还是为了减小寻址开销的，《Hadoop权威指南》中有一段话：

    “HDFS的块比磁盘块大，其目的是为了最小化寻址开销。如果块设置得足够大，从磁盘传输数据的时间可以明显大于定位这个块开始位置所需的时间。这样，传输一个由多个块组成的文件的时间就取决于磁盘传输速率。”

    “我们做一个估计计算，如果寻址时间为10ms左右，而传输速率为100MB/s，为了使寻址时间仅占传输时间的1%，我们需要设置块大小为100MB左右。而默认的块大小实际为64MB，但是很多情况下HDFS使用128MB的块设置。以后随着新一代磁盘驱动器传输速率的提升，块的大小将被设置得更大。”

    “但是，该参数也不会设置得过大。MapReduce中的map任务通常一次处理一个块中的数据，因此，如果任务数太少（少于集群中的节点数量），作业的运行速度就会变慢。”

参考：https://www.cnblogs.com/Dhouse/p/6901028.html?utm_source=itdadao&utm_medium=referral