HDFS原理总结

1. HDFS优缺点

1.1 优点

1.1.1高容错性

可以由数百或数千个服务器机器组成，每个服务器机器存储文件系统数据的一部分；
数据自动保存多个副本；
副本丢失后检测故障快速，自动恢复。

1.1.2适合批处理

移动计算而非数据；
数据位置暴露给计算框架；
数据访问的高吞吐量；
运行的应用程序对其数据集进行流式访问。

1.1.3适合大数据处理

典型文件大小为千兆字节到太字节；
支持单个实例中的数千万个文件；
10K+节点。

1.1.4 可构建在廉价的机器上

通过多副本提高可靠性；
提供了容错与恢复机制。

1.1.5跨异构硬件和软件平台的可移植性强

轻松地从一个平台移植到另一个平台。

1.1.6 简单一致性模型

应用程序需要一次写入多次读取文件的访问模型；
除了追加和截断之外，不需要更改已创建，写入和关闭的文件；
简化了数据一致性问题，并实现了高吞吐量数据访问；
高度可配置，具有非常适合于许多安装的默认配置。大多数时候，只需要为非常大的集群调整配置。

1.2 缺点

1.2.1 不适合低延迟的数据访问

HDFS设计更多的是批处理，而不是用户交互使用。重点在于数据访问的高吞吐量，而不是数据访问的低延迟。

1.2.2不适合小文件存取

占用NameNode大量内存；
寻道时间超过读取时间。

1.2.3无法并发写入、文件随即修改

一个文件只能有一个写者；
仅支持追加和截断。

• 
  

  2.  基本组成

  2.1 Namenode

  2.1.1 接受客户端的读写服务

  执行文件系统命名空间操作，如打开，关闭和重命名文件和目录。

  2.1.2 管理文件系统命名空间

  记录对文件系统命名空间或其属性的任何更改。

  2.1.3metadata组成

  Metadata是存储在Namenode上的元数据信息，它存储到磁盘的文件名为：fsimage。并且有个叫edits的文件记录对metadata的操作日志。总体来说，fsimage与edits文件记录了Metadata中的权限信息和文件系统目录树、文件包含哪些块、确定块到DataNode的映射、Block存放在哪些DataNode上(由DataNode启动时上报)。

  NameNode将这些信息加载到内存并进行拼装，就成为了一个完整的元数据信息。

  2.1.4文件系统命名空间

  HDFS支持传统的分层文件组织。用户或应用程序可以在这些目录中创建目录和存储文件。文件系统命名空间层次结构与大多数其他现有文件系统类似：可以创建和删除文件，将文件从一个目录移动到另一个目录，或重命名文件。HDFS支持用户配额和访问权限。但不支持硬链接或软链接。

  NameNode维护文件系统命名空间。对文件系统命名空间或其属性的任何更改由NameNode记录。应用程序可以指定应由HDFS维护的文件的副本数。文件的副本数称为该文件的复制因子。此信息由NameNode存储。

  2.1.5 文件系统元数据的持久性

  NameNode的metadata信息在启动后会加载到内存，由于加载到内存的数据很不安全，断电后就没有了，因此必须对内存中存放的信息做持久化处理。

  Namenode上保存着HDFS的命名空间。对于任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为Edits的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Edits中插入一条记录来表示；同样地，修改文件的副本系数也将往Edits插入一条记录。Namenode在本地操作系统的文件系统中存储这个Edits。整个文件系统的命名空间，包括数据块到文件的映射、文件的属性等，都存储在一个称为FsImage的文件中，这个文件也是放在Namenode所在的本地文件系统上。

  Namenode在内存中保存着整个文件系统的命名空间和文件数据块映射(Blockmap)的映像。这个关键的元数据结构设计得很紧凑，因而一个有4G内存的Namenode足够支撑大量的文件和目录。当Namenode启动时，它从硬盘中读取Edits和FsImage，将所有Edits中的事务作用在内存中的FsImage上，并将这个新版本的FsImage从内存中保存到本地磁盘上，然后删除旧的Edits，因为这个旧的Edits的事务都已经作用在FsImage上了。这个过程称为一个检查点(checkpoint)。

  Datanode将HDFS数据以文件的形式存储在本地的文件系统中，它并不知道有关HDFS文件的信息。它把每个HDFS数据块存储在本地文件系统的一个单独的文件中。Datanode并不在同一个目录创建所有的文件，实际上，它用试探的方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录中创建所有的本地文件并不是最优的选择，这是因为本地文件系统可能无法高效地在单个目录中支持大量的文件。当一个Datanode启动时，它会扫描本地文件系统，产生一个这些本地文件对应的所有HDFS数据块的列表，然后作为报告发送到Namenode，这个报告就是块状态报告。

• 2.2 SecondaryNameNode

  它不是NameNode的备份，但可以作为NameNode的备份，当因为断电或服务器损坏的情况，可以用SecondNameNode中已合并的fsimage文件作为备份文件恢复到NameNode上，但是很有可能丢失掉在合并过程中新生成的edits信息。因此不是完全的备份。

  由于NameNode仅在启动期间合并fsimage和edits文件，因此在繁忙的群集上，edits日志文件可能会随时间变得非常大。较大编辑文件的另一个副作用是下一次重新启动NameNode需要更长时间。SecondNameNode的主要功能是帮助NameNode合并edits和fsimage文件，从而减少NameNode启动时间。

  2.2.1 SNN执行合并时机

  • 根据配置文件配置的时间间隔fs.checkpoint.period默认1小时；

  • dfs.namenode.checkpoint.txns，默认设置为1百万，也就是Edits中的事务条数达到1百万就会触发一次合并，即使未达到检查点期间。

  2.2.2 SNN合并流程

  
  

• • 首先生成一个名叫edits.new的文件用于记录合并过程中产生的日志信息；

  • 当触发到某一时机时（时间间隔达到1小时或Edits中的事务条数达到1百万）时SecondaryNamenode将edits文件、与fsimage文件从NameNode上读取到SecondNamenode上；

  • 将edits文件与fsimage进行合并操作，合并成一个fsimage.ckpt文件；

  • 将生成的合并后的文件fsimage.ckpt文件转换到NameNode上；

  • 将fsimage.ckpt在NameNode上变成fsimage文件替换NameNode上原有的fsimage文件，并将edits.new文件上变成edits文件替换NameNode上原有的edits文件。

  SNN在hadoop2.x及以上版本在非高可用状态时还存在，但是在hadoop2.x及以上版本高可用状态下SNN就不存在了，在hadoop2.x及以上版本在高可用状态下，处于standby状态的NameNode来做合并操作。

  2.3 DataNode

  • 管理附加到它们运行的节点的存储，并允许用户数据存储在文件中；

  • 在内部，文件被分割成一个或多个块（Block），并且这些块被存储在一组DataNode中；

  • 负责提供来自文件系统客户端的读取和写入请求；

  • 执行块创建，删除；

  • 启动DN进程的时候会向NN汇报Block信息；

  • 通过向NN发送心跳保持与其联系（3秒一次），如果NN10分钟没有收到DN的心跳，则认为DN已经丢失，并且复制其上的Block到其他的DN上。

  2.3.1 HDFS存储单元（block）

  2.3.1.1文件被切分成固定大小的数据块

  • 默认数据块大小为64MB（hadoop1.x）、128MB（hadoop2.x）、256MB(hadoop3.x)，可配置；

  • 若文件大小不到一个块大小，则单独存成一个block，block块是一个逻辑意义上的概念。文件大小是多少，就占多少空间。

  2.3.1.2 一个文件存储方式

  • 按大小被切分成不同的block，存储到不同的节点上；

  • 默认情况下，每个block都有3个副本；

  • block大小与副本数通过client端上传文件时设置，文件上传成功后副本数可以变更，block size不可变更。

  2.3.1.3 设计思想

  将大文件拆分成256MB的block块，每个block块分别随机存放在不同的节点上，从而避免了数据倾斜的问题，但是在开发过程中，如果算法、程序写的不好，同样也会出现数据倾斜的问题。

  2.3.2 数据复制

  2.3.2.1 数据复制概述

  HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块，除了最后一个，所有的数据块都是同样大小的。为了容错，文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定，也可以在之后改变。HDFS中的文件都是一次性写入的，并且严格要求在任何时候只能有一个写入者。

  Namenode全权管理数据块的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。

  2.3.2.2 Block的副本放置策略

  副本的存放是HDFS可靠性和性能的关键。优化的副本存放策略是HDFS区分于其他大部分分布式文件系统的重要特性。这种特性需要做大量的调优，并需要经验的积累。HDFS采用一种称为机架感知(rack-aware)的策略来改进数据的可靠性、可用性和网络带宽的利用率。目前实现的副本存放策略只是在这个方向上的第一步。实现这个策略的短期目标是验证它在生产环境下的有效性，观察它的行为，为实现更先进的策略打下测试和研究的基础。

  大型HDFS实例一般运行在跨越多个机架的计算机组成的集群上，不同机架上的两台机器之间的通讯需要经过交换机。在大多数情况下，同一个机架内的两台机器间的带宽会比不同机架的两台机器间的带宽大。

  通过一个机架感知的过程，Namenode可以确定每个Datanode所属的机架id。一个简单但没有优化的策略就是将副本存放在不同的机架上。这样可以有效防止当整个机架失效时数据的丢失，并且允许读数据的时候充分利用多个机架的带宽。这种策略设置可以将副本均匀分布在集群中，有利于当组件失效情况下的负载均衡。但是，因为这种策略的一个写操作需要传输数据块到多个机架，这增加了写的代价。

  在大多数情况下，副本系数是3，HDFS的存放策略是将一个副本存放在本地机架的节点上，一个副本放在同一机架的另一个节点上，最后一个副本放在不同机架的节点上。这种策略减少了机架间的数据传输，这就提高了写操作的效率。机架的错误远远比节点的错误少，所以这个策略不会影响到数据的可靠性和可用性。于此同时，因为数据块只放在两个（不是三个）不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下，副本并不是均匀分布在不同的机架上。三分之一的副本在一个节点上，三分之二的副本在一个机架上，其他副本均匀分布在剩下的机架中，这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。

  2.3.2.3 副本选择

  为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。

  2.3.2.4 安全模式

  • NameNode在启动的时候会进入一个称为安全模式的特殊状态，它首先将映像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作；

  • 一旦在内存中成功建立文件系统元数据映射，则创建一个新的fsimage文件（这个操作不需要SecondNameNode来做）与一个空的编辑日志；

  • 此刻namenode运行在安全模式，即namenode的文件系统对于客户端来说是只读的，显示目录、显示文件内容等，写、删除、重命名都会失败；

  • 在此阶段namenode搜集各个datanode的报告，当数据块达到最小副本数以上时，会被认为是“安全”的，在一定比例的数据块被认为是安全的以后（可设置），再过若干时间，安全模式结束；

  • 当检测到副本数不足数据块时，该块会被复制，直到达到最小副本数，系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中。

    
    

    2.4 数据组织

    2.4.1 数据块

    HDFS被设计成支持大文件，适用HDFS的是那些需要处理大规模的数据集的应用。这些应用都是只写入数据一次，但却读取一次或多次，并且读取速度应能满足流式读取的需要。HDFS支持文件的“一次写入多次读取”语义。一个典型的数据块大小是256MB。因而，HDFS中的文件总是按照256M被切分成不同的块，每个块尽可能地存储于不同的Datanode中。

    2.4.2 分段

    客户端创建文件的请求其实并没有立即发送给Namenode，事实上，在刚开始阶段HDFS客户端会先将文件数据缓存到本地的一个临时文件。应用程序的写操作被透明地重定向到这个临时文件。当这个临时文件累积的数据量超过一个数据块的大小，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它。然后返回Datanode的标识符和目标数据块给客户端。接着客户端将这块数据从本地临时文件上传到指定的Datanode上。当文件关闭时，在临时文件中剩余的没有上传的数据也会传输到指定的Datanode上。然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到日志里进行存储。如果Namenode在文件关闭前宕机了，则该文件将丢失。

    上述方法是对在HDFS上运行的目标应用进行认真考虑后得到的结果。这些应用需要进行文件的流式写入。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。这种方法并不是没有先例的，早期的文件系统，比如AFS，就用客户端缓存来提高性能。为了达到更高的数据上传效率，已经放松了POSIX标准的要求。

    2.4.3 管道复制

    当客户端向HDFS文件写入数据的时候，一开始是写到本地临时文件中。假设该文件的副本系数设置为3，当本地临时文件累积到一个数据块的大小时，客户端会从Namenode获取一个Datanode列表用于存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分(4 KB)地接收数据，将每一部分写入本地仓库，并同时传输该部分到列表中第二个Datanode节点。第二个Datanode也是这样，一小部分一小部分地接收数据，写入本地仓库，并同时传给第三个Datanode。最后，第三个Datanode接收数据并存储在本地。因此，Datanode能流水线式地从前一个节点接收数据，并在同时转发给下一个节点，数据以流水线的方式从前一个Datanode复制到下一个。

    
    

  3.  读写流程

  3.1 HDFS读流程

  
  

• • 首先HDFS的客户端通过DistributedFileSystem；

  • 通过DistributedFileSystem来对NameNode进行请求，同时将用户信息及文件名的信息等发送给NameNode，并返回给DistributedFileSystem该文件包含的block所在的DataNode位置；

  • HDFS客户端通过FSDataInputStream按顺序去读取DataNode中的block信息（它会选择负载最低的或离客户端最近的一台DataNode去读block）；

  • FSDataInputStream按顺序一个一个的读，直到所有的block都读取完毕；

  • 当读取完毕后会将FSDataInputStream关闭。

• 3.2 HDFS写流程
  

• 首先HDFS的客户端通过Distributed FileSystem（HDFS中API里的一个对象）；

• 通过Distributed FileSystem发送客户端的请求给NameNode（NameNode主要是接受客户端请求）并且会带着文件要保存的位置、文件名、操作的用户名等信息一起发送给NameNode；

• NameNode会给客户端返回了一个FSDataOutputStream，同时也会返回文件要写入哪些DataNode上（负载较低的）；

• 通过FSDataOutputStream进行写操作，在写之前就做文件的拆分，将文件拆分成多个Block，第一个写操作写在负载比较低的DataNode上，并将这个block复制到其他的DataNode上；

• 当所有的block副本复制完成后会反馈给FSDataOutputStream；

• 当所有的block副本全都复制完成，就可以将FSDataOutputStream流关闭；

• 通过Distributed FileSystem更新NameNode中的源数据信息。

4.  架构

4.1 NameNode和DataNode

HDFS采用master/worker架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的命名空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的命名空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。

4.2 基础架构

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。

• 客户端的请求全部落到了NameNode上；

• 元数据信息存在NameNode；

• 在Hadoop集群中有且只有一个处于Active状态的NameNode；

• SecondaryNameNode不是NameNode的备份节点或从节点（确切的说它只能备份NameNode的部分内容，而不是全部）；

• NameNode与DataNode之间有心跳机制，从而NameNode可以知道DataNode的运行情况与负载情况。

4.2.1 健壮性

HDFS的主要目标就是即使在出错的情况下也要保证数据存储的可靠性。常见的三种出错情况是：Namenode出错, Datanode出错和网络分区。

4.2.1.1 磁盘数据错误，心跳检测和重新复制

每个Datanode节点周期性地向Namenode发送心跳信号。网络原因有可能导致一部分Datanode跟Namenode失去联系。Namenode通过心跳信号的缺失来检测这一情况，并将这些近期不再发送心跳信号的Datanode标记为宕机，不会再将新的IO请求发给它们。任何存储在宕机Datanode上的数据将不再有效。Datanode的宕机可能会引起一些数据块的副本系数低于指定值，Namenode不断地检测这些需要复制的数据块，一旦发现就启动复制操作。在下列情况下，可能需要重新复制：某个Datanode节点失效、某个副本遭到损坏、Datanode上的硬盘错误或者文件的副本系数增大。

4.2.1.1.1 DataNode热插拔驱动器

Datanode支持热插拔驱动器。可以添加或替换HDFS数据卷，而不必不关闭DataNode。下面简要介绍典型的热插拔驱动程序：

• 如果存在新的存储目录，则应格式化它们并适当地装载它们；

• 将数据卷目录更新到DataNode的配置dfs.datanode.data.dir中；

• 通过运行dfsadmin -reconfig datanode HOST：PORT start来使我们配置的目录生效，并且可以使用dfsadmin -reconfig datanode HOST：PORT status查询重新配置任务的运行状态；

• 一旦重新配置任务完成，我们就可以安全地卸载、删除数据卷目录并物理删除磁盘。

4.2.1.2 负载均衡

HDFS的架构支持数据均衡策略。如果某个Datanode节点上的空闲空间低于特定的临界点，按照均衡策略系统就会自动地将数据从这个Datanode移动到其他空闲的Datanode。在对特定文件的突然高需求的情况下，此方案可以动态地创建附加的副本并重新平衡群集中的其他数据。

4.2.1.2.1 平衡器

HDFS的数据也许并不是非常均匀的分布在各个DataNode中。一个常见的原因是在现有的集群上经常会增添新的DataNode节点。当新增一个数据块（一个文件的数据被保存在一系列的块中）时，NameNode在选择DataNode接收这个数据块之前，会考虑到很多因素。其中的一些考虑的是：

• 将数据块的一个副本放在正在写这个数据块的节点上；

• 尽量将数据块的不同副本分布在不同的机架上，这样集群可在完全失去某一机架的情况下还能存活；

• 一个副本通常被放置在和写文件的节点同一机架的某个节点上，这样可以减少跨越机架的网络I/O；

• 尽量均匀地将HDFS数据分布在集群的DataNode中。

4.2.1.3 数据完整性

从某个Datanode获取的数据块有可能是损坏的，损坏可能是由Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了对HDFS文件内容的校验和(checksum)检查。当客户端创建一个新的HDFS文件，会计算这个文件每个数据块的校验和，并将校验和作为一个单独的隐藏文件保存在同一个HDFS名字空间下。当客户端获取文件内容后，它会检验从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该数据块的副本。

4.2.1.3.1 回收站机制

4.2.1.3.1.1 文件的删除和恢复

如果启用了回收站功能，FS Shell删除的文件不会立即从HDFS中删除。而是将其移动到回收目录（每个用户在/user /<username>/.Trash下都有自己的回收目录）。只要文件保留在回收站中，文件就可以快速恢复。

最近删除的文件移动到当前回收目录（/user/<username>/.Trash/Current），并在可配置的时间间隔内，HDFS创建对/user/<username>/.Trash/<date>目录下的一个检查点，并在过期后删除旧检查点。

当文件在回收站期满之后，NameNode将从HDFS命名空间中删除该文件。删除文件会导致与该文件关联的块被释放。需要说明的是，文件被用户删除的时间和对应的释放空间的时间之间有一个明显的时间延迟。

4.2.1.3.1.2 减少副本

当文件的副本因子减小时，NameNode选择可以删除的多余副本。下一个心跳将此信息传输到DataNode。DataNode然后删除相应的块并且释放对应的空间。同样，在设置副本因子完成和集群中出现新的空间之间有个时间延迟。

4.2.1.4 元数据磁盘错误

FsImage和Edits是HDFS的核心数据结构。如果这些文件损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多个FsImage和Edits的副本。任何对FsImage或者Edits的修改，都将同步到它们的副本上。这种多副本的同步操作可能会降低Namenode每秒处理的命名空间事务数量。然而这个代价是可以接受的，因为即使HDFS的应用是数据密集型的，它们的元数据信息的量也不会很大。当Namenode重启的时候，它会选取最近的完整的FsImage和Edits来使用。

4.2.1.4.1 检查点节点

NameNode采用两个文件来保存命名空间的信息：fsimage，它是最新的已执行检查点的命名空间的信息：edits，它是执行检查点后命名空间变化的日志文件。当NameNode启动时，fsimage和edits合并，提供一个最新的文件系统的metadata，然后NameNode将新的HDFS状态写入fsimage，并开始一个新的edits日志。

Checkpoint节点周期性地创建命名空间的检查点。它从NameNode下载fsimage和edits，在本地合并它们，并将其发回给活动的NameNode。Checkpoint节点通常与NameNode不在同一台机器上，因为它们有同样的内存要求。Checkpoint节点由配置文件中的bin/hdfs namenode –checkpoint来启动。

Checkpoint(或Backup)节点的位置以及附带的web接口由dfs.namenode.backup.address anddfs.namenode.backup.http-address参数指定。

Checkpoint进程的运行受两个配置参数控制：

• dfs.namenode.checkpoint.period，两次连续的检查点之间的最大的时间间隔，缺省值是1小时；

• dfs.namenode.checkpoint.txns，最大的没有执行检查点的事务数目，默认设置为1百万，也就是Edits中的事务条数达到1百万就会触发一次合并，即使未达到检查点期间；

Checkpoint节点上保存的最新的检查点，其目录结构与NameNode上一样，这样，如果需要，NameNode总是可以读取这上面的已执行检查点的文件映像。多个Checkpoint节点可以在集群的配置文件中指定。

4.2.1.4.2备份节点

Backup节点与Checkpoint节点提供同样的执行检查点功能，只不过它还在内存中保存一份最新的命名空间的的拷贝，该拷贝与NameNode中的保持同步。除了接收NameNode中发送的edits并把它保存到磁盘之外，Backup还将edits用到自己的内存中，因而创建出一份命名空间的备份。

因为Backup节点在内存中保持有最新的命名空间的状态，因此它不需要从NameNode下载fsimage和edits文件来创建一个检查点，而这是Checkpoint节点或备用NameNode所必需的步骤。Backup节点的检查点进程更高效，因为它只需要将命名空间信息保存到本地的fsimage文件并重置edits就可以了。

由于Backup节点内存中维护了一份命名空间的拷贝，它的内存要求与NameNode一致。NameNode同一时刻只支持一个Backup节点。如果Backup在用，则不能注册Checkpont节点。

Backup节点的配置与Checkpoint节点一样，它采用bin/hdfs namenode –backup启动。Backup(或Checkup)节点的位置及其web接口由配置参数dfs.namenode.backup.address和 dfs.namenode.backup.http-address指定。

使用Backup节点，NameNode就可以选择不进行存储，而将保持命名空间状态的责任交给Backup节点。为此，在NameNode的配置中，采用选项-importCheckpoint来启动NameNode，并且不设置edits的存储位置选项dfs.namenode.edits.dir。

4.2.1.4.3 导入检查点

如果其它所有的映像文件和edits都丢失了，可以将最后的检查点导入到NameNode，为此，需要以下步骤：

• 创建一个空目录，在dfs.namenode.name.dir项中配置为该目录；

• 设置dfs.namenode.checkpoint.dir为检查点目录；

• 采用-importCheckpoint选项来启动NameNode。

NameNode将从dfs.namenode.checkpoint.dir设置的目录中上载检查点，并将其保存在dfs.namenode.name.dir指定的目录中。如果dfs.namenode.name.dir中存在一个映像文件，NameNode就会启动失败，NameNode要验证dfs.namenode.checkpoint.dir中的映像文件是否有问题，但在任何情况下，都不会修改该文件。

4.2.1.4.4 恢复模式

通常，你要配置多个metadata存储位置，当一个存储位置崩溃后，你可以从其它位置读取到metadata。但是，如果仅有的一个存储位置崩溃后怎么办呢？在这种情况下，有一个特别的NameNode启动模式，叫恢复模式，允许你恢复大部分数据。你可以像这样启动恢复模式：namenode –recover，在恢复模式时，NameNode以命令行的方式与你交互，显示你可能采取的恢复数据的措施。如果你不想采用交互模式，你可以加上选项-force，这个选项将强制选取第一个选择恢复，通常，这是最合理的选择。由于恢复模式可能使数据丢失，你应该在使用它之前备份edits日志文件和fsimage。

4.2.1.5 快照

HDFS快照是文件系统的只读时间点副本。利用快照，可以让HDFS在数据损坏时恢复到过去一个已知正确的时间点。可以对文件系统的子树或整个文件系统进行快照。快照的一些常见用例是数据备份，防止用户错误和灾难恢复。

HDFS快照的实现是高效的：

• 快照创建是即时的：成本是O（1）*，*不包括inode查找时间；

• 仅当相对于快照进行修改时才使用附加内存：内存使用为O（M），其中M是修改的文件/目录的数量；

• 不复制datanode中的块：快照文件记录块列表和文件大小。没有数据复制；

• 快照不会对常规HDFS操作产生不利影响：按照时间倒序顺序记录修改，以便可以直接访问当前数据。通过从当前数据中减去修改来计算快照数据。

4.2.1.5.1 Snapshottable目录

一旦目录设置为可快照，就可以对任何目录进行快照。snaphottable目录能够容纳65,536个同步快照。可快照目录的数量没有限制。管理员可以将任何目录设置为可快照。如果快照目录中有快照，则在删除所有快照之前，不能删除或重命名目录。

当前不允许嵌套snaphottable目录。换句话说，如果一个目录的祖先或后代是一个snaphottable目录，则不能将其设置为snaphottable。

5.  命令指南

所有的hadoop命令均由bin/hdfs脚本引发。不指定参数运行hdfs脚本会打印所有命令的描述。

用法：hdfs [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]

Hadoop有一个选项解析框架用于解析一般的选项和运行类。

5.1 用户命令

hadoop集群用户的常用命令。

5.1.1 classpath

打印获取Hadoop jar和所需库所需的类路径。如果无参数调用，则打印由命令脚本设置的类路径，可以在类路径条目中包含通配符。其他选项在通配符扩展后打印类路径或将类路径写入jar文件的清单。后者在不能使用通配符且扩展的类路径超过支持的最大命令行长度的环境中非常有用。

5.1.2 dfs

HDFS允许以文件和目录的形式组织用户数据。它提供了一个称为FS shell的命令行界面，允许用户与HDFS中的数据交互。此命令

集的语法类似于我们已经熟悉的shell。

5.1.3 envvars

显示计算的Hadoop环境变量。

5.1.4 fetchdt

HDFS支持fetchdt命令来获取授权标识，并将其存储在本地文件系统的一个文件中。一个“非安全”的客户端可以用这个标识来访问受限的服务器（例如NameNode）。获取这个标识，采用RPC或HTTPS(over Kerberos)方式，然后，在获取之前需要提交Kerberos凭证（运行kinit来获得凭证）。HDFS fechedt命令不是一个Hadoop shell命令。它以bin/hadoop fetchdt DTfile方式运行。当你获得授权标识后，通过指定环境变量HADOOP_TOKEN_FILE_LOCATION为授权标识文件名，你就可以运行HDFS命令，而不需要Kerberros凭证了。

5.1.5 fsck

HDFS支持fsck命令来检查系统中的各种不一致状况。这个命令被设计来报告各种文件存在的问题，比如文件缺少数据块或者副本数目不够。不同于在本地文件系统上传统的fsck工具，这个命令并不会修正它检测到的错误。一般来说，NameNode会自动修正大多数可恢复的错误。HDFS的fsck不是一个Hadoop shell命令。它通过'bin/hadoop fsck'执行。

5.1.6 getconf

从配置目录获取配置信息。

5.1.7 groups

返回给定一个或多个用户名的组信息。

5.1.8 lsSnapshottableDir

获取快照目录的列表。当它作为超级用户运行时，它返回所有可快照目录。否则，它返回那些由当前用户拥有的目录。

5.1.9 jmxget

从服务转储JMX信息。

5.1.10 oev

Hadoop离线edits查看器。

5.1.11 oiv

Hadoop离线image查看器用于Hadoop 2.4或更高版本中的映像文件。

5.1.12 oiv_legacy

Hadoop的旧版本的Hadoop离线image查看器。

5.1.13 snapshotDiff

确定HDFS快照之间的差异。

5.2 管理命令

hadoop集群管理员常用的命令。

5.2.1 balancer

运行集群平衡工具。管理员可以简单的按Ctrl-C来停止平衡过程。

5.2.2 cacheadmin

HDFS缓存管理。

5.2.3 crypto

HDFS透明加密。

5.2.4 datanode

运行HDFS datanode。

5.2.5 dfsadmin

DFSAdmin命令集用于管理HDFS集群。这些是仅由HDFS管理员使用的命令。以下是一些示例/命令对：

5.2.6 diskbalancer

运行磁盘调度程序CLI。

5.2.7 erasurecode

运行ErasureCoding CLI。

5.2.8 haadmin

在带有NFS的HDFS HA或带有QJM的HDFS HA中使用。

5.2.9 journalnode

这个命令启动一个journalnode用于带有QJM的HDFS HA。

5.2.10 mover

运行数据迁移实用程序。

5.2.11 namenode

运行namenode。以及升级和回滚。

5.2.12 nfs3

这个comamnd启动NFS3网关用于HDFS NFS3服务。

5.2.13 portmap

这个comamnd启动RPC portmap用于HDFS NFS3服务。

5.2.14 secondarynamenode

运行HDFS辅助节点。

5.2.15 storagepolicies

列出所有/获取/设置/取消设置存储策略。

5.2.16 zkfc

这个命令启动一个Zookeeper故障转移控制器过程与带有QJM的HDFS HA一起使用。