为什么HDFS文件块（block）大小设定为128M解析.

r囧r小猫 2022-12-13 12:57 384阅读 0赞

**Table of Contents**

一.前言

二. block 大小设置原则：最小化寻址开销,减少网络传输.

三、为什么HDFS中块（block）不能设置太大，也不能设置太小？

四、 HDFS中块（block）的大小为什么设置为128M？

--------------------

# 一.前言 #

HDFS中存储数据是以块（block，这只是一个逻辑概念）的形式存储在DataNode，block大小可通过设置`HADOOP_HOME/etc/hadoop/hdfs-site.xml`中`dfs.blocksize`实现（设置时先stop集群，修改完restart集群）。在Hadoop2.x之后的版本中，文件块的默认大小是128M，老版本中默认是64M；

<property>
    	<name>dfs.block.size</name>
    	<value>134217728</value>
    </property>

# 二. block 大小设置原则：最小化寻址开销,减少网络传输. #

1.  减少硬盘寻道时间(disk seek time)：HDFS的设计是为了支持大数据操作，合适的block大小有助于减少硬盘寻道时间（平衡了硬盘寻道时间、IO时间），提高系统吞吐量。
2.  减少NameNode内存消耗：NameNode需要在内存FSImage文件中记录DataNode中数据块信息，若block size太小，那么需要维护的数据块信息会更多。而HDFS只有一个NameNode节点，内存是极其有限的。
3.  map崩溃问题：若Map任务崩溃，重新启动执行需要重新加载数据，数据块越大，数据加载时间将越长，恢复时间越长。
4.  监管时间问题：主节点监管其他节点的情况，每个节点会周期性的把完成的工作和状态的更新报告回来。若某个节点保存沉默超过预设的时间间隔，主节点“宣告”该节点状态为死亡，并把分配给这个节点的数据发到别的节点。预设的时间间隔是根据数据块 size角度估算的，若size设置不合理，容易误判节点死亡。
5.  约束Map任务输出：MapReduce框架中Map任务输出的结果是要经过排序才给reduce函数操作的。在Map任务的merge on disk和Reduce任务中合并溢写生的文件，用到归并排序算法，对小文件进行排序，然后将小文件归并成大文件。
6.  网络传输问题: 在数据读写计算的时候,需要进行网络传输.如果block过大会导致网络传输时间增长,程序卡顿/超时/无响应. 任务执行的过程中拉取其他节点的block或者失败重试的成本会过高.如果block过小,则会频繁的进行文件传输,对严重占用网络/CPU资源.

> 寻址时间：HDFS中找到目标文件块（block）所需要的时间。
> 
> **原理：**
> 
> 文件块越大，寻址时间越短，但磁盘传输时间越长；
> 
> 文件块越小，寻址时间越长，但磁盘传输时间越短。

# 三、为什么HDFS中块（block）不能设置太大，也不能设置太小？ #

**1. 如果块设置过大，**

第一点: 从磁盘传输数据的时间会明显大于寻址时间，导致程序在处理这块数据时，变得非常慢；

第二点: mapreduce中的map任务通常一次只处理一个块中的数据，如果块过大运行速度也会很慢。

第三点: 在数据读写计算的时候,需要进行网络传输.如果block过大会导致网络传输时间增长,程序卡顿/超时/无响应. 任务执行的过程中拉取其他节点的block或者失败重试的成本会过高.

第四点: namenode监管容易判断数据节点死亡.导致集群频繁产生/移除副本, 占用cpu,网络,内存资源.

**2. 如果块设置过小，**

第一点: 存放大量小文件会占用NameNode中大量内存来存储元数据，而NameNode的物理内存是有限的；

第二点: 文件块过小，寻址时间增大，导致程序一直在找block的开始位置。

第三点: 操作系统对目录中的小文件处理存在性能问题.比如同一个目录下文件数量操作100万,执行"fs -l "之类的命令会卡死.

第四点: ,则会频繁的进行文件传输,对严重占用网络/CPU资源.