1. Blocks（块）

硬盘上有块，代表能够读取和写入的最小的data单位，通常是512字节。

基于单硬盘的文件系统也有块的概念，通常是把硬盘上的一组块集合在一起成为一个块，一般有几KB大小。

这些对于文件系统的使用者都是透明的，使用者只知道往硬盘上写了一定大小的文件，或从硬盘上读了一定大小的文件。当然有些维护命令，比如df和fsck，就是在块级上的操作。

HDFS也有块（blocks），但比之前提到的大得多，默认是64MB。与单硬盘文件系统的块相同的是，HDFS上的文件会被切分成多个块大小的碎片存储，所不同的是，如果文件的大小小于一个块，它在硬盘上实际的存储空间不是一个块那么大。

为什么HDFS的blocks这么大呢？这是出于减少寻址时间考虑的，不是说块大了就寻址快了，而是让寻址时间相对于传输时间占用的比例较小。因为HDFS是基于网络的，数据会在机器之间传输，寻到该块的地址后，就向该机器读或写这个块，所以块越大，传输时间越长，寻址时间就相对较小，如果块设置成很小，那么寻址时间占比例就更高，寻址次数也更多。

块的抽象为HDFS带来许多好处。

首先，也是最明显的，文件可以比网络上的任意一台计算机的硬盘空间大。因为没有要求一个文件的所有块必须存在一台计算机上。甚至一个文件的块可以遍布集群中的每一台计算机。

其次，块的抽象，使得存储子系统更简单。简单是所有系统的追求，尤其是状况百出的分布式系统。因为块的大小是固定的，管理metadata的计算机可以很容易算出一块硬盘能存多少块，也不必担心文件元信息的存储，因为块只存储数据，文件的元信息（比如权限等）存在独立的计算机上，单独操作。

另外，块存储方便容错机制。为了保证在任意存储节点出现故障时，数据不会丢失，数据一般都是按块做备份的，通常一台机器上的块会在另外两台机器上备份，也就是一共有3份。如果一个块的数据读不到了，可以在另外一台机器上读取到，这些对HDFS的使用者是透明的。如果一个数据块不可用，它的内容会从备份机上读出并拷贝到另一个机器上，以保证备份数又恢复到设置的值。

HDFS像Linux的命令一样，也有fsck命令

%hadoop fsck / -files -blocks

在hadoop 2.x中，这个命令不建议使用，而是使用

%hdfs fsck / -files -blocks

这个命令将列出HDFS系统中每个文件被分成的块。

2. Namenodes和Datanodes

HDFS集群有两种节点类型，Namenodes和Datanodes，它们工作于master-worker模式。一个namenode是master，一组datanodes是workers。namenode管理整个文件系统的namespace。它维护一棵文件树和所有文件/目录的元信息。这些信息在namenode的本地磁盘上存成两个文件，一个是该namespace的镜像，另一个是编辑日志（edit log）。namenode也知道每个文件的每个块都存在哪个datanode上了，但这个信息不会被持久化下来，因为每次启动时，这个信息会被重新生成。

客户端程序通过访问namenode和datanodes来访问HDFS文件系统。但是用户代码根本不知道namenode和datanodes的存在，就像访问POSIX一样（Portable Operating System Interface：便携计算机系统接口）。

Datanodes是干苦力活的。当被客户端或namenode命令时，它存储和检索文件块（blocks）。它还会定期向namenode汇报它们存储的文件块列表。

没有namenode，整个文件系统就没法用了。如果把namenode移除，整个文件系统里的文件就都丢失了，因为没办法知道如何重新组装存在各个datanodes里的文件块。因此有必要保证namenode足够可靠，Hadoop提供了两种机制保证namenode里的数据安全。

第一个机制是备份namenode上的持久化信息。可以配置hadoop，让namenode写持久化信息时写到多个地方，并且这些写操作是串行的并且是原子操作。通常的做法是写到本地磁盘一份，同时写到远程NFS上。

另一个机制是配一个secondary namenode。虽然名字上叫namenode，但secondary namenode根本不做namenode的工作，它就是定期把namenode上的namespace镜像和编辑日志（edit log）合并到自己身上，以避免编辑日志过大。secondary namenode通常是一台单独的机器，因为合并工作需要大量的CPU和内存资源。因为它的状态迟于namenode，所以，当namenode发生事故时，肯定是会有数据丢失的。通常的做法是把namenode在NFS上的metadata文件拷贝到secondary namenode，然后启动这个secondary namenode，让它成为namenode。

3. HDFS Federation

namenode把HDFS文件系统中的文件和块的信息都存在内存里，这就使得当集群规模扩大时，内存资源成为了限制。因此在Hadoop 2.x中，引入了HDFS Federation的概念，允许通过增加更多的namenodes节点来扩大HDFS规模，每一个namenode管理一个namespace，比如一个namenode管理/usr下的所有文件，另一个namenode管理/share下的所有文件。这个/usr或/share叫namespace volume。namespace volumes之间彼此独立，互相不通信，一个namenode死掉了，其它namenode也不知道，也不影响对其它namenode上管理的文件的访问。

访问一个federated HDFS集群时，客户端使用一个存储在客户端的mount table（挂载表）来映射文件路径和namenodes的对应关系。用ViewFileSystem和viewfs://URIs来配置。

4. HDFS高可用性（HA：High-Availability）

前面在（2. Namenodes和Datanodes）提到的通过备份namenode上的持久化信息，或者通过secondary namenode的方式，只能解决数据不丢失，但是不能提供HA（高可用性），namenode仍然是“单点失败”（SPOF：single point of failure）。如果namenode死掉了，所有的客户端都不能访问HDFS文件系统里的文件了，不能读写也不能列出文件列表。

新的namenode必须做下面三件事才能再次提供服务：

i) 加载namespace镜像

ii) 重做编辑日志（edit log）里的操作

iii) 接收所有datanodes上的文件块信息汇报，退出安全模式

对于一个大型集群来讲，一次这样的冷启动可能要花费30分钟的时间。

在Hadoop 2.x版本中引入了active-standby模式的一对namenodes。当灾难发生时，standby的机器会取代active的机器，成为新的namenode。为了实现这样的结构，需要新的架构：

- 两个namenodes之间要有一块共享的存储空间，以便共享编辑日志（edit log）。早期实现需要一个高可用的NFS，在后来的版本中有更多的选择，例如可以使用ZooKeeper解决方案。

- 另外，因为文件块的映射关系是存在内存里的，不是存在磁盘上的，因此datanodes必须向两个namenodes同时汇报自己的存储情况。

- 客户端需要配置成能够自动处理namenode失败的情况，对使用者透明。

当active namenode死掉了，standby namenode替换上去的时间很快，也就是几十秒的样子。因为standby namenode上有最新的文件块映射信息和最新的编辑日志（edit log），一切都是时刻准备着的。但是确定active namenode是不是真的死了是个大麻烦，会花费更长时间（大概一分钟左右）。

如果active namenode和standby namenode都死了怎么办？没关系，就花30分钟冷启动一下就好了，跟没有active-standby一样，不会更坏。因此，active-standby是一个改进性的优化，不会带来副作用。

判断active是不是还活着，其实就是用心跳请求的方式的。但是，管理员还有另外一个工具可以在active还活着的情况下，优雅地切换到standby上，让standby成为新的active，这在定期维护的情况下非常有用。这种切换之所以被称为“优雅失败”（graceful failover），因为两个namenodes会按顺序切换角色，一个成为active，一个变成standby。

在不优雅的切换中，就是active死掉了，不得已换成了standby来服务，这时，原来的active不一定真的死了，可能是网络慢啊或者什么原因，导致它后来又能提供服务了，最麻烦的是它自己不知道自己曾经死了，它要是再冒出来服务就麻烦了，因此，有一系列的动作会阻止它再次加入系统，比如杀掉进程啊，关闭端口啊什么的，最后一招就是STONITH（暴头：shoot the other node in the head）。

所有这些都是对客户端透明的。客户端配置namenode时是把一个hostname映射到两个IP上的，然后分别试两个IP，哪个通就用哪个。