数据块
每个磁盘都有默认的数据块大小，这是磁盘进行数据读写的最小单位。构建与单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的快。该文件系统块的大小可以使磁盘块的整数倍。文件系统块一般为几千字节，而磁盘块一般为512字节。
HDFS同样也有块(block)的概念，但是大得多，默认为64MB（Hadoop1系列为64MB，Hadoop2系列为128MB）。与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块(chunk)，作为独立的存储单元。与其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。
为何HDFS中的块如此之大？
HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。如果块设置得足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需要的时间。因而，传输一个由多个块组成的文件的时间取决于磁盘的传输速率。
但是块大小也不会设置的过大。MapReduce中的map任务通常一次只处理一个块中的数据，因此如果任务数太少（少于集群中的节点数量），作业的运行速度就会比较慢。
对分布式文件系统中的块进行抽象会带来很多好处。第一个最明显的好处是，一个文件的大小可以大于网络中任意一个磁盘的容量。文件的所有块并不需要存储在同一个磁盘上，因此它们可以利用集群上的任意一个磁盘进行存储。
第二个好处是，使用抽象块而非整个文件作为存储单元，大大简化了存储子系统的设计。简化是所有系统的目标，但是这对于故障种类繁多的分布式系统来说尤为重要。将存储子系统控制单元设置为块，可简化存储管理(由于块的大小是固定的，因此计算单个磁盘能存储多少个块就相对容易)。同时也消除了对元数据的顾虑(块只是存储数据的一部分，而文件的元数据，如权限信息，并不需要与块一同存储，这样一来，其他系统就可以单独管理这些元数据)。
不仅如此，块还非常适合用于数据备份进而提供数据容错能力和提高可用性。将每个块复制到少数几个独立的机器上(默认为3个)，可以确保在块、磁盘或机器发生故障后数据不会丢失。如果发现一个块不可用，系统会从其他地方读取另一个复本，而这个过程对用户是透明的。一个因损坏或机器故障而丢失的块可以从其他候选地点复制到另一台可以正常运行的机器上，以保证复本的数量回到正常水平。
HDFS中fsck指令可以显示块信息。
hadoop fsck / -files -blocks
namenode和datanode
HDFS集群有两类节点以管理者-工作者模式运行，即一个namenode(管理者)和多个datanode(工作者)。Namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件(fsimage)和编辑日志文件(editslog)。Namenode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时由数据节点重建。
客户端(client)代表用户通过与namenode与datanode交互来访问整个文件系统。客户端提供一个类似于POSIX(可移植操作系统界面)的文件系统接口，因此用户在编程时无需知道namenode和datanode也可以实现其功能
datanode是文件系统的工作节点。他们根据需要存储并检索数据块(受客户端或namenode调度)，并且定期向namenode发送它们所在存储额块的列表
没有namenode，文件系统将无法使用。如果运行namenode服务的机器毁坏，文件系统上所有的文件将丢失，因为我们不知道如何根据datanode的块重建文件。
Hadoop提供了两种机制实现namenode的容错
1. 备份那些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使namenode在多个文件系统上保存元数据的持久状态。这些写操作是实时同步的，是原子操作。一般的配置使，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统(NFS)
2. 运行一个辅助namenode，但它不能被用作namenode。这个辅助namenode的重要作用是定期通过边记日志合并命名空间镜像，以防止边记日志过大。这个辅助namenode一般在另一台单独的物理计算机上运行，因为它需要占用大量CPU时间与namenode相同容量的内存来执行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。但是，辅助namenode保存的状态总是滞后于主节点，所以在主节点全部失效时，难免会丢失部分数据。这种情况下，一般把存储在NFS上的namenode元数据复制到辅助namenode并作为新的主namenode运行。
联邦HDFS
namenode在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈。在2.x发行版本系列中引入的联邦HDFS允许系统通过添加namenode实现扩展，其中每个namenode管理文件系统命名空间中的一部分。
在联邦环境下，每个namenode维护一个命名空间卷(namespace volume)，包括命名空间的源数据和该命名空间下的文件的所有数据块的数据块池。命名空间卷之间是相互独立的，两两之间并不互相通信，甚至其中一个namenode的失效也不会影响其他namenode维护的命名空间的可用性。数据块池不再进行切分，因此集群中的datanode需要注册到每个namenode，并且存储着来自多个数据块池中的数据块。
要想访问联邦HDFS集群，客户端需要使用客户端挂载数据表将文件路径映射到namenode。
HDFS的高可用性
通过联合使用在多个文件系统中备份namenode的元数据和铜鼓备用namenode创建监测点能防止数据丢失，但是依旧无法实现文件系统的高可用性。Namenode依旧存在单点失效(SPOF)的问题。如果namenode失效了，那么所有的客户端-包括MapReduce作业-均无法读写或列文件，因为namenode是唯一存储元数据与文件到数据块映射的地方。
Hadoop2.x发行版系列在HDFS中增加了对高可用性（HA）的支持。配置了一对活动-备用(active-standby)namenode。当活动namenode失效，备用namenode就会接管它的任务并开始服务于来自客户端的请求，不会有任何明显中断。
1. namenode之间需要通过高可用的共享存储实现编辑日志的共享。当备用namenode接管工作之后，它将通读编辑日志直至末尾，以实现与活动namenode的状态同步，并继续读取由活动namenode写入的条目
2. datanode需要同时向两个namenode发送数据块处理报告。因为数据块的映射信息存储在namenode的内存中，而非磁盘
3. 客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的
在活动namenode失效之后，备用namenode能够快速实现任务接管，因为最新的状态存储在内存中:包括最新的编辑日志条目和最新的数据块映射信息。
故障切换与规避
一个称为故障转移控制器(failover controller)的系统中有一个新实体管理着将活动namenode转移为备用namenode的转换过程。故障转移控制器是可插拔的，但其最初的实现是基于Zookeeper的并由此确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器，其工作就是监视宿主namenode是否失效(通过一个简单的心跳机制实现)并在namenode失效时进行故障切换。
在非平稳故障转移的情况下，无法确切知道失效namenode是否已经停止运行。例如，在网速非常慢或者网络被分隔的情况下，同样也可能激发故障转移，但是先前的namenode依然运行着并且依旧是活动namenode。高可用实现做了更进一步的优化，以确保先前活动的namenode不会执行危害系统并导致系统崩溃的操作-该方法称为规避(fencing)。系统引入了一系列的规避机制，包括杀死namenode进程，收回访问共享存储目录的权限，以远程管理命令以屏蔽相应网络端口。
补充
位："位(bit)"是电子计算机中最小的数据单位。每一位的状态只能是0或1。
字节：8个二进制位构成1个"字节(Byte)"，它是存储空间的基本计量单位。1个字节可以储存1个英文字母或者半个汉字，换句话说，1个汉字占据2个字节的存储空间。
字："字"由若干个字节构成，字的位数叫做字长，不同档次的机器有不同的字长。例如一台8位机，它的1个字就等于1个字节，字长为8位。如果是一台16位机，那么，它的1个字就由2个字节构成，字长为16位。字是计算机进行数据处理和运算的单位。
