Hadoop分布式文件系统(HDFS)用于支持数据处理程序要处理的大文件。这样的程序在处理数据的时候，有一次写、多次读的特点。
HDFS文件系统由以下几个守护进程协调地运行来提供服务：
名称节点进程
辅助名称节点进程
数据节点进程
HDFS系统也是主从架构的。运行名称节点进程的服务器为主节点，运行数据节点进程的服务器为从节点。一般情况下，集群中的每个从节点都会运行一个数据节点进程。这个数据节点进程管理着挂载到这个数据节点上的存储设备。HDFS系统提供一个统一的文件系统命名空间，用户就像使用一个文件系统一样来存取集群节点上的数据。名称节点进程负责管理这些存储在集群上的文件的元数据。
1. Hadoop文件的本质是块存储
首先，你应该理解集群中文件的物理存储方式。在Hadoop系统中，每个文件被分隔为多个数据块。一个典型的数据块大小为64MB，也可以将其配置为32MB或者128MB。在HDFS中，文件块的大小是按照文件的大小来配置的。如果一个文件的大小不是一个文件块大小的整数倍，空间也不会浪费很多，因为只是最后一个文件块未被完全占满。一个大文件会被分隔为多个数据块来存储。
每个数据块存储在数据节点上。为了防止节点故障，这些数据块是有备份的。在Hadoop系统中，备份数量默认配置为3。具备机架感知功能的Hadoop系统把文件的一个数据块存放在本地机架上的一台计算节点上（假设Hadoop客户端运行在本地机架中的一台数据节点上，否则，Hadoop客户端会随机选择一个机架）。这个数据块的第二个备份会被存放在另外一个远程机架上的计算节点中。这个数据块的第三个备份会被存放在第二个数据块备份机架上的另一台计算节点中。Hadoop系统借助一个单独配置的网络拓扑文件实现机架感知功能，这个网络拓扑文件配置了机架到计算节点的域名系统（DNS）名称之间的映射，该网络拓扑文件的路径配置在Hadoop配置文件中。
许多Hadoop系统会把文件备份因子降为2。运行在EMC 公司的Isilon硬件之上的Hadoop系统就是这样一个例子。这样做的原因是这套硬件系统使用了RAID 5的技术，这个技术本身就内置了数据的冗余备份，从而可以降低Hadoop系统的文件备份因子。降低文件备份因子的一个很明显的好处就是提高了系统I/O性能（少写一个备份）。这个链接中的白皮书讲解了这样的系统架构设计：http://www.emc.com/collateral/software/white-papers/h10528-wp-hadoop-on-isilon.pdf。
为什么不把三个文件数据块的备份分别存放到不同的机架上呢？毕竟，这样做可以增加数据冗余度。这样做的话，抵御机架故障的能力更强，而且还可以增加机架的数据吞吐量。但是，机架故障的概率远低于计算节点故障的概率，而且把数据块备份到不同的机架可导致Hadoop系统写性能的大幅下降。所以，一个折中的方案就是把两个数据块的备份存放在同一个远程机架上的不同计算机点中，以此换取Hadoop系统写性能的提高。这种基于Hadoop系统性能限制的巧妙设计在Hadoop系统中是很常见的。
2.文件元数据和名称节点
当客户端向HDFS请求读取或者存储一个文件的时候，它需要知道要访问的数据节点是哪一个。知道这个信息之后，客户端可以直接访问那个数据节点。文件的元数据信息由名称节点来负责维护。
HDFS系统提供一个统一的文件系统命名空间，用户就像使用一个文件系统一样来存取集群节点上的数据。HDFS把存储在目录中的文件按照一定的层级展示出来，目录是可以嵌套的。所有文件和目录的元数据信息都由名称节点来负责管理。
名称节点管理所有的文件操作，包括文件/目录的打开、关闭、重命名、移动等等。数据节点就负责存储实际的文件数据。这是一个非常重要的区别。当客户点请求或者发送文件数据，文件的数据在物理上是不经过名称节点传输的。否则这将是一个极其严重的瓶颈。客户端仅仅是简单地从名称节点获取文件的元数据，然后根据其元数据信息直接从数据节点获取文件的数据块。
名称节点存储的一些元数据包括：
文件/目录名称及相对于其父目录的位置。
文件和目录的所有权及权限。
各个数据块的文件名。所有数据块以文件的形式存放在数据节点的本地文件系统的目录中，该目录可以被Hadoop系统管理员配置。
需要注意的是名称节点并不存储每个数据块的位置（数据节点的身份信息）。数据节点的身份信息（DataNode identity）在集群启动的时候从每个数据节点获取。名称节点维护的信息是，HDFS上的文件由哪些数据块（数据节点上每个数据块的文件名）组成。
元数据存储在名称节点的本地磁盘上，但是为了快速访问，在集群操作的时候会把这些元信息加载到内存。这个策略对于提高Hadoop系统的操作性能是很关键的，但是同时也成为了Hadoop系统的一个瓶颈，由此催生出了Hadoop 2.x系统。
每个元数据信息大约占用200字节的RAM。假设一个1GB大小的文件，数据块的大小为64MB。这么大的一个文件需要16×3（包括文件备份数量）＝48个数据块的存储量。现在假设有1000个文件，每个文件的大小为1MB。这么大的一个文件需要1000×3（包括文件备份数量）＝3000 个数据块的存储量（每个文件只需要占用数据块1MB的存储空间即可，但是多个文件不能存储在同一个数据块中）。这样的话，元数据的数据量将会大幅增长。这将会导致名称节点更大量的内存占用。这个例子也解释了为什么Hadoop系统更适合存储大文件，而不适合存储大量的小文件。海量的小文件会轻易地拖垮名称节点服务器。
名称节点服务器上存放元数据的文件为fsimage。Hadoop系统运行期间任何涉及对元数据修改的操作都保存在内存中，并且被持久存储到另外一个名为edits的文件。辅助名称节点会周期性地把edits文件中的信息合并到fsimage文件中。（当我们在讲解辅助名称节点的时候，会深入细致地分析这个合并过程。）保存到HDFS上的实际文件数据并不会存放在fsimage和edits文件中，实际的数据存放在运行着数据节点守护进程的从节点的数据块中。正如前文讲到的，这些数据块以文件的形式存放在集群的从节点中。这些数据块中存放的是文件的原始数据，不存放文件元数据。但是，如果名称节点中保存的元数据丢失了，会导致整个集群不可用。名称节点中的元数据为客户端提供了数据块的信息，这些存放在从节点中的数据块存有文件的真实数据。
数据节点守护进程周期性的发送心跳信息给名称节点。这使得名称节点可以感知所有数据节点的健康状况，从而，客户端的请求不会被发送到故障数据节点。
3. HDFS系统写文件的机制
一个HDFS文件系统的写操作涉及文件的创建。从客户端的角度来看，HDFS系统不支持文件的更新。（这样说并不十分准确，因为在HBase中已经使用了HDFS系统的文件追加特性。但是，不建议客户端使用这样的功能。）在下文的讲述中，我们假定HDFS文件系统的默认备份因子为3。
图2-3用图表的形式描述了HDFS文件系统写操作过程，通过这张图表我们对整个操作过程有了一个大致的认识。
客户端把一个文件写入到HDFS文件系统需要经过以下几个步骤：
1）客户端在联系名称节点之前，会把文件数据流式地读入（streaming the file contents）到客户端本地文件系统中的一个临时文件中。
2）当文件数据的大小达到一个数据块的大小时，客户端就联系名称节点。
3）名称节点会在HDFS文件系统的层级结构中创建一个文件，然后把数据块的标识符和数据节点上的位置信息发送给客户端。这个数据节点数据块信息列表里面还包括了其备份节点的数据块信息列表。
4）进行完上述的步骤之后，客户端就会根据上一步的数据块信息把本地临时文件中的数据刷新（flush）到集群上的数据块中（只写入到第一个数据节点中）。这样，真实的文件数据就放在了集群数据节点本地文件存储系统中。
5）当文件（客户端可以访问的HDFS文件）被关闭时，名称节点会执行一个提交操作，从而使得该文件在集群中为可见状态。如果在提交操作完成之前名称节点挂掉了，这个文件就丢失了。
其中步骤4我们要拿出来详细讲解一下，这个步骤中的刷新操作过程如下：
1）第一个数据节点以数据包（其大小一般为4KB）的形式从客户端接收数据。当这一小部分数据写入到第一个数据节点的本地存储中时，它还会被传送到第二个数据节点中保存。
2）当第二个数据节点开始把数据块写入到本地磁盘时，这个包含文件数据块的数据包会被同时传送到第三个数据节点。
3）最终，这个包含文件数据的数据包写入到第三个数据节点中，此时，这部分的文件数据及其备份就以数据管道的方式存放到HDFS文件系统中。
4）保存包含文件数据的数据包成功之后，其确认包（acknowledgment packet）会从保存了该数据包的计算节点通过数据管道返回给前一个保存了该数据包的计算节点。最后，第一个数据节点会发送确认包到客户端。
5）当客户端接收到了数据块保存成功的确认，数据块就被认为是持久地存储到了集群中的计算节点上。客户端会发送最终的确认信息给名称节点。
6）在数据管道中的任何数据节点发生故障，数据管道就会关闭。文件数据将会被写入其他数据节点。名称节点会感知到文件数据没有备份完成，就会执行重新备份的过程，把数据备份到状态良好的节点，以确保达到要求的文件备份水平。
7）每个数据块都会有一个校验和，这个校验和用来检测数据块的完整性。这些校验和存放在HDFS中另外一个隐藏的文件中，当读取数据块的时候用来校验数据块的完整性。
4. HDFS系统读文件的机制
现在我们来讲解如何从HDFS中读取一个文件。图2-4展示了HDFS系统读文件的过程。
客户端从HDFS中读取文件的步骤为：
1）客户端访问名称节点，名称节点返回组成文件的数据块列表及数据块的位置（包括备份数据块的位置）。
2）客户端会直接访问数据节点以获取数据块中的数据。如果此时其访问的数据节点出现故障，就会访问存放备份数据块的数据节点。
3）读取数据块的时候会计算该数据块的校验和，并将该校验和与写入文件时的校验和作比较。如果检验失败，则从其他数据节点获取备份数据块。
5. HDFS系统删除文件的机制
在HDFS系统上删除一个文件，遵从以下步骤：
1）名称节点仅仅重命名了文件路径，使其移动到了/trash目录。需要注意的是，这个操作过程是链接到重命名文件路径的元数据的更新操作。这个执行过程非常迅速。/trash 目录中的文件会保存一段时间，这个保存时间是预先确定的（当前设定为6小时而且当前不可配置）。在这段时间内，把删除的文件从/trash目录中移动出来即可迅速地恢复该文件。
2）当/trash目录中的文件超过了保存时间时，名称节点就会将该文件从HDFS命名空间中删除。
3）删除文件会使得该文件相关的数据块被释放，HDFS系统随后会显示增加了一些空闲空间。
HDFS系统中的文件备份因子是可变的，它可以减小。通过一次心跳信息，这个文件备份因子的变化信息就可以由名称节点发出，数据节点就会动态地从本地存储系统中删除相应的数据块，这样一来，集群就会有更多的空闲存储空间了。所以，名称节点可以动态维护文件的备份数量。
6.确保HDFS系统的可靠性
Hadoop系统和HDFS系统都有很强的抗故障能力。在以下两种情况下会造成数据丢失：
数据节点故障：每个数据节点周期性地发送心跳信息到名称节点（默认3秒钟一次）。如果名称节点在预先设定的时间段内没有收到心跳信息，它就会认为数据节点有故障了。此刻，名称节点就会主动地对存储在故障数据节点上的数据块重新备份，把相关数据块（从其他健康节点的备份数据块获取）转移到状态健康的数据节点。这样就可以确保数据块备份数量不变。
位腐（bit rot）现象导致的数据损坏：这是指当电荷（在传输过程中）发生衰减而导致的数据丢失的情况。在HDFS系统读取数据块的操作过程中会进行数据校验和核对，这种情况的数据损坏就会被发现。如果数据块的校验失败了，便认为这个数据块已经损坏，就会读取该数据块的备份，然后名称节点会重新备份这个损坏了数据块，使得数据块的备份数量达到预先设定的数据块备份数量。
