第2章 Hadoop HDFS 原理
构建大型网站时，随着数据的增多，数据库访问效率的下降，影响了网站的使用，为了
解决该问题人员使用分库分表手段，通过把数据库中的数据进行垂直分割和水平分割，提高
访问效率。而针对文件系统也存在同样的问题，当存储的文件大小超过单个机器的存储空间
时，就必须把文件数据通过网路分布在不同物理主机上，此时为了提供与单机系统同样的文
件系统服务，就需要扩网络的分布式文件系统。分布式文件系统是基于网络的，网络编程的
复杂性同样出现在分布式文件系统中，从而使分布式文件系统要比单机文件系统复杂的多，
比如分布式文件系统的一个挑战就是当一个节点失效时，不会造成文件数据的丢失。
分布式文件系统有很多，既包括谷歌的 GFS、微软的 DFS、腾讯的 TFS、阿里的 TFS 等
各大互联网公司自己使用的分布式文件系统，也包括 Hadoop HDFS 在内开源的分布式文件
系统。
HDFS 是 Hadoop 的旗舰文件系统，因为其所提供的对通用文件系统的抽象，因此它可
以很容易的跟本地文件系统、亚马逊 S3 在内的其他的存储系统集成。同时 HDFS 是被设计
用来运行在廉价硬件集群之上、存储非常大的文件并提供流式数据访问模式的文件系统。
其中：
“非常大的文件”：成千上万 M、G 和 T 字节大小的文件
“流式数据访问”：HDFS 的设计主要基于“一次写入，多次读取”的想法。典型情况下，
一个数据集合从源拷贝到文件系统中，后继会不断的对数据进行不同的分析。因此，读整个
数据集合的时间比读取第一条记录的延迟要重要的多。
“廉价硬件”：Hadoop 不需要昂贵的、高可用的硬件。因此集群中出现硬件故障的概率
很高，HDFS 被设计能够在硬件故障的情况下，不被用户感觉到明显的中断。
但是 HDFS 不适合如下几种应用场景：
（1） 实时性要求高：比如数据访问必须在毫秒级完成，因为 HDFS 侧重的是数据的
高吞吐，而这是以高延迟为代价的。
（2） 大量的小文件：因为 NameNode 在内存中保存文件系统元数据。一个文件系统
能支持的文件的数量是由 NameNode 节点的内存决定的。每个文件、目录及块
都要占用内存。
（3） 多次写、随机写：HDFS 不支持多次写，更不支持针对文件的随机读写。
一、HDFS 块
在磁盘文件系统中，磁盘的块是读写磁盘的基本单位。文件系统的块对应多个磁盘块。
文件系统的块一般是几个 k，而磁盘的块儿一般是 512 字节。这些对文件系统用户来说是透
明的。但 df 和 dk 可以在块层面对文件系统进行维护。
在 HDFS 中，块大小缺省为 64M，并且一个文件被分成多个各自独立的块来存储。当一
个文件比 64M 小时，不会占用该块所对应的所有物理存储。
为什么 HDFS 采用这么大的块？答案在于减少块定位的相对消耗。读磁盘的时间等于定
位时间+传输时间，所以如果通过增加块的大小使传输时间远大于定位时间，这样传输一个
由多个块构成的大文件的时间，将取决于块传输速度。
假设定位时间是 10ms，传输速率为 100MB/s，使定位时间为传输时间的 1%，那么块大
小应该是 100MB。所以一般取 64M。
当然该值也不是越大越好，因为 MR 一次处理一个块，如果分块过大，使块数远小于节
点数，将不能充分利用分布计算的效率。
HDFS 提供块级别的抽象有如下好处。首先，HDFS 其可存储超过任何一个节点磁盘大小
的文件，因为一个文件可分成多个块，每个块可分布在不同的节点上。第二，可简化存储子
系统。因此块是固定大小，所以可以很容易的计算一个磁盘可包含多少块，同时可以把文件
剩余11页未读，继续阅读
资源评论
