HDFS Block块大小限定依据及原则

小学僧来啦

已于 2024-04-01 15:56:53 修改

阅读量8k

点赞数 13

分类专栏： Hadoop Hive 文章标签： hadoop 大数据

于 2021-08-17 11:18:11 首次发布

本文链接：https://blog.csdn.net/bocai8058/article/details/119300121

版权

Hadoop 同时被 2 个专栏收录

15 篇文章 4 订阅

订阅专栏

Hive

7 篇文章 1 订阅

订阅专栏

@Author  : Spinach | GHB
@Link    : http://blog.csdn.net/bocai8058

文章目录

前言

前言

Hadoop集群中的文件存储都是以块（block）的形式存储在HDFS中的。其中从Hadoop2.7.3版本开始，文件块（block size）的默认值是128MB，之前版本默认值是64MB

Hadoop2.7.3版本DataBlock为128MB（Apache Hadoop 2.7.3官方文档）
在这里插入图片描述

存储中block size与实际文件size关系

在HDFS中存储是以块（block）的形式存储在DataNode中的。那么在真实存储中实际文件大小和block块大小是怎么一个关系呢？

下面举例来讲述（默认HDFS块大小为128MB，文件副本为3份）。

问题1：若从客户端上传一个大小为128MB的文件，会产生多少个block块，占用多少实际物理存储

根据块大小，此时应该有1个block块，但由于副本的存在，总共有3个block块；
实际占用物理存储为128MB，同样由于副本的存在，总共占用物理存储为128MB*3；
块信息位置等元数据信息是存储在NameNode中的，会存1条记录。

问题2：若从客户端上传一个大小为130MB的文件，会产生多少个block块，占用多少实际物理存储

根据块大小，此时应该有2个block块，其中1个块大小是128MB，1个块大小是2MB，后者占用的真实存储空间也是2MB，并不是128MB，同样由于副本的存在，总共有6个block块，其中3个块大小是128MB，3个块大小是2MB；
实际占用物理存储为130MB，其中1个文件大小是128MB，1个文件大小是2MB，同样由于副本的存在，总共占用物理存储为128MB * 3 + 2MB * 3；
块信息位置等元数据信息是存储在NameNode中的，会存2条记录。

问题3：若从客户端再上传一个大小为 24MB 的文件，那么这个block块会与问题 2 中的那个 2MB 的block块进行合并吗？

不会，block块不会合并，block块只是一个逻辑概念，实际占用的物理存储空间是以文件大小为准的，所以这个24MB 的文件上传后是一个独立的文件块，占用物理存储空间大小为24MB。

说明如下：

block块只是在HDFS存储中的一个逻辑概念；
小于块（block）大小的小文件不会占用整个块（block）空间，而是实际大小的物理存储空间；
在追加文件过程中，可以通过block size决定何时split文件，可参考 Hadoop Community 的解释说明：
The block size is a meta attribute. If you append tothe 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.
block块位置信息时记录在元数据信息中的，而元数据信息是由NameNode负责存储的，那么若存在较多的小文件，那么就会占用较多的NameNode存储空间，加大了存储压力和集群性能开销。因此针对出现大量小文件的情况也是需要治理的，具体治理参考《Hive表小文件治理方案》。

如何修改默认块（block）大小

从Hadoop2.7.3版本开始，文件块（block size）的默认值是128MB，之前版本默认值是64MB

block大小可以通过修改hdfs-site.xml文件中的dfs.blocksize对应的值来实现，若设置block大小为256MB如下：

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

注意：在修改HDFS的数据块大小时，首先停掉集群hadoop的运行进程，修改完毕后重新启动。

block块大小设置原则

原则：最小化寻址开销，减少网络传输

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

减少磁盘寻道时间(disk seek time)：HDFS的设计是为了支持大数据操作，合适的block大小有助于减少硬盘寻道时间（平衡了硬盘寻道时间、IO时间），提高系统吞吐量。
减少NameNode内存消耗：NameNode需要在内存FSImage文件中记录DataNode中数据块信息，若block size太小，那么需要维护的数据块信息会更多。而HDFS只有一个NameNode节点，内存是极其有限的。
影响map端失败时重启时间：若map端任务出现崩溃，那么在重新启动拉起任务时会重新加载数据，而数据块的大小直接影响了加載数据的时间，例如数据块（block）越大，数据加载时间就会越长，进而该map任务的恢复时间越长。
考虑网络传输问题：在数据读写过程中，需要进行网络传输。如果block块过大，会导致网络传输的时间边长，也会因网络不稳定等因素造成程序卡顿、超时、无响应等。如果block块过小，会频繁的进行文件传输，初始化的map端对象会变多，资源占用变高、jvm增高、网络占用变多。
考虑监管时间问题：主节点监管其他节点的情况，每个节点会周期性的把完成的工作和状态的更新报告回来。若某个节点保存沉默超过预设的时间间隔，主节点“宣告”该节点状态为死亡，并把分配给这个节点的数据发到别的节点。预设的时间间隔是根据数据块 size角度估算的，若size设置不合理，容易误判节点死亡。

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

主要取决于磁盘/网络的传输速率。[其实就是CPU、磁盘、网卡之间的协同效率，即跨物理机/机架之间文件传输速率]

如果块设置过大，

从磁盘传输数据的时间会明显大于寻址时间，导致程序在处理这块数据时，变得非常慢；
mapreduce中的map任务通常一次只处理一个块中的数据，如果块过大运行速度也会很慢；
在数据读写计算的时候,需要进行网络传输。如果block过大会导致网络传输时间增长，程序卡顿/超时/无响应。任务执行的过程中拉取其他节点的block或者失败重试的成本会过高；
namenode监管容易判断数据节点死亡。导致集群频繁产生/移除副本，占用cpu、网络、内存资源。

如果块设置过小，

存放大量小文件会占用NameNode中大量内存来存储元数据，而NameNode的物理内存是有限的；
文件块过小，寻址时间增大，导致程序一直在找block的开始位置；
操作系统对目录中的小文件处理存在性能问题，比如同一个目录下文件数量操作100万，执行"fs -l "之类的命令会卡死；
会频繁的进行文件传输，严重占用网络/CPU资源。

为什么block块大小设置为128MB

实际中，磁盘传输速率为200MB/s时，一般设定block大小为256MB

首先HDFS中平均寻址时间大概为10ms；
经过前人的大量测试发现，寻址时间为传输时间的1%时，为最佳状态，所以最佳传输时间为：
10ms/0.01=1000ms=1s
目前磁盘的传输速度普遍为100MB/s，最佳block大小计算：
100MB/s*1s=100MB
所以我们设置block大小为128MB

而在实际中，
磁盘传输速率为200MB/s时，一般设定block大小为256MB；
磁盘传输速率为400MB/s时，一般设定block大小为512MB。

引言：
https://blog.csdn.net/wx1528159409/article/details/84260023
https://blog.csdn.net/zhanglong_4444/article/details/109018998
https://blog.51cto.com/snglw/1643587
https://www.playpi.org/2017040101.html