分布式文件系统 之 数据块(Block)
众所周知,HDFS中以数据块(block)为单位进行存储管理。本文简单介绍一下HDFS中数据块(block)的概念,以及众多分布式存储系统(不止是HDFS)使用block作为存储管理基本单位的意义。
数据块
数据块的概念并不陌生,在磁盘中,每个磁盘都有默认的数据块大小,这是磁盘进行数据读/写的最小单位,磁盘块一般为512字节。在分布式文件系统中,数据块一般远大于磁盘块的大小,并且为磁盘块大小的整数倍,例如,HDFS block size默认为64MB。
分布式存储系统中选择大block size的主要原因是为了最小化寻址开销,使得磁盘传输数据的时间可以明显大于定位这个块所需的时间。然而,在HDFS中block size也不好设置的过大,这是因为MapReduce中的map任务通常一次处理一个块中的数据,因此如果block太大,则map数就会减少,作业运行的并行度就会受到影响,速度就会较慢。
Why block
在很多分布式文件系统中我们都可以看到block的存在,这种设计的好处主要有以下几点:
- 存储的文件大小可以大于集群中任意一个磁盘的容量。这很好理解,文件被划分到多个block中存储,对磁盘透明;
- 使用block抽象而非整个文件作为存储单元,可以极大简化存储子系统的设计。因为block size是统一的,因此一个节点上可以存储多少block就是可以推算的;
- Block 非常适合用于数据备份,进而提供数据容错能力和可用性。
Why bigger block
在普通文件系统中,使用较大的磁盘块:
- 可以减少管理数据块需要的开销。如在Linux中可以减少保存在i-node中磁盘地址表中的信息链的长度;
- 在对文件进行读写时,可以减少寻址开销,即磁盘定位数据块的次数。
在HDFS中,使用大数据块:
- 可以减少名字节点上管理文件和数据块关系的开销;
- 对数据块进行读写时,可以有效减少建立网络连接需要的成本。
Block VS. Chunk
由于我也是最近才开始比较仔细的接触Hadoop,GFS中的DataNode又被称为ChuckServer,因此经常会被HDFS中的block和chunk搞得confused掉。今天看到了一个比较好的解释,在这里记录一下:
block:如上文,是HDFS中的存储管理单元,类似磁盘的block。
chuck:HDFS中存储的文件被划分为多个块(chuck),每个chuck的大小与block的大小相同(除了最后一个chuck),这些文件chuck就被存储到block中。
好啦,记录的很简单。以前很喜欢一篇文章记录的很详尽,因此很久都憋不出一篇博文,就算准备充分可以开写了,但是又会觉得好长,懒得写。所以呢,为了让自己学习得更有节奏吧,现在决定有点感悟就记录下来,方便以后查看。当然,也可以一段时间merge 整理一下 相关的短文啦!
YUKI,干巴爹 哈哈
参考
《Hadoop权威指南》(第二版)P43
《Hadoop技术内幕:深入解析Hadoop Common和HDFS架构设计与实现原理》 P218