HDFS(Hadoop分布式文件系统)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System）。它是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS早期是作为Apache Nutch搜索引擎项目的基础架构而开发的。

硬件故障是常态而不是异常。HDFS可能由成百上千台服务器构成，每台服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数量是巨大的，而且任一组件都有可能失效，这意味着随时都可能有一部分HDFS组件处于故障状态。因此，故障检测和快速、自动的恢复是HDFS架构的核心目标。

运行在HDFS之上的程序有很大量的数据集。典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件存储和访问。

大部分的HDFS程序对文件操作需要的是一次写多次读取的操作模式。一个文件一旦创建、写入、关闭之后就不需要修改了。这个假定简单化了数据一致的问题，并使高吞吐量的数据访问变得可能。一个Map-Reduce程序或者网络爬虫程序都可以完美地适合这个模型。

在靠近数据所存储的位置来进行计算是最理想的状态，尤其是在数据集特别巨大的时候。这样就能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比将数据移动到应用所在位置显然更好。HDFS提供了接口让程序将自己移动到离数据存储更近的位置来执行计算。

HDFS在设计的时候就考虑到平台的可移植性，这种特性方便了HDFS作为大规模数据应用平台的推广。

Namenode 是HDFS的守护进程，用来管理文件系统的命名空间，负责记录文件是如何分割成数据块，以及这些数据块分别被存储到哪些数据节点上，它的主要功能是对内存及IO进行集中管理。
Namenode上保存着HDFS的名字空间。任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为Editlog的事务日志进行记录。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样地，修改文件的副本系数也将往Editlog中插入一条记录。Namenode在本地操作系统的文件系统中存储这个Editlog。整个文件系统的名字空间，包括数据块到文件的映射、文件的属性等，都存储在一个称为FsImage的文件中，这个文件也是放在Namenode所在的本地文件系统上。
Namenode在内存中保存着整个文件系统的名字空间和文件数据块映射的映像。这个关键的元数据结构设计得很紧凑，因而一个有4GB内存的Namenode足够支撑大量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用在内存中的FsImage上，并将这个新版本的FsImage从内存中保存到本地磁盘上，然后删除旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为一个检查点（checkpoint）。

文件系统的数据存储节点和工作节点，响应Namenode 命令存储和检索数据块，并且定期向Namenode发送它们所存储的块的列表。
Datanode将HDFS数据以文件的形式存储在本地的文件系统中。

Secondary Namenode 不是备用 Namenode。它是一个辅助后台进程，与NameNode进行通信，以便定期保存HDFS元数据的快照，用以备份和恢复数据。Secondary Namenode负责定时（默认1小时）从Namenode上获取DFS元数据的快照(fsimage和editLog)进行合并，然后再发送给Namenode，减少Namenode的工作量。

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

• 客户端向Namenode发起文件写入的请求；
• Namenode根据文件大小和文件块配置情况，返回给客户端所管理部分Datanode的信息；
• 客户端将文件划分为多个块，根据Datanode的地址信息，按顺序写入到每一个Datanode块中。

• 客户端向Namenode发起文件读取的请求；
• Namenode返回文件存储的Datanode的信息；
• 客户端读取Datanode上的文件信息。

为了容错，文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的，副本系数默认是3。
Namenode全权管理数据副本的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了该Datanode上所有数据块的列表。
副本的存放是HDFS可靠性和性能的关键。优化的副本存放策略是HDFS区分于其他大部分分布式文件系统的重要特性。HDFS采用一种称为机架感知（rack-aware）的策略来改进数据的可靠性、可用性和网络带宽的利用率。副本系数默认是3，HDFS的存放策略是将一个副本存放在本地机架的节点上，一个副本存放在同一机架的另一个节点上，最后一个副本存放在不同机架的节点上。
这种策略减少了机架间的数据传输，提高了写操作的效率。机架的错误远远比节点的错误少，所以这个策略不会影响到数据的可靠性和可用性。与此同时，因为数据块只放在两个（不是三个）不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下，副本并不是均匀分布在不同的机架上。
三分之一的副本在一个节点上，三分之二的副本在一个机架上，这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。

HDFS的主要目标就是即使在出错的情况下也要保证数据存储的可靠性。常见的三种出错情况是Namenode故障、Datanode故障和网络故障，HDFS提供了多种错误恢复手段，保障了系统的健壮性。

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

HDFS的架构支持数据均衡策略。如果某个Datanode节点上的空闲空间低于临界点，就会按照均衡策略系统就会自动地将数据从这个Datanode移动到其他空闲的Datanode。当对某个文件的请求突然增加时，也可能启动一个计划创建该文件新的副本，并且同时重新平衡集群中的其他数据。

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

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

快照支持某一特定时刻的数据的复制备份。利用快照，可以让HDFS在数据损坏时恢复到过去一个已知正确的时间点。

HDFS数据组织包括HDFS的数据块存储、流水线复制、文件的删除和恢复等机制，保障了HDFS高效和可靠地存储数据。

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

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

当用户或应用程序删除某个文件时，这个文件并没有立刻从HDFS中删除。实际上，HDFS会将这个文件重命名转移到/trash目录。只要文件还在/trash目录中，该文件就可以被迅速地恢复。文件在/trash中保存的时间是可配置的，目前的默认策略是6小时，当超过这个时间时，Namenode就会将该文件从名字空间中删除。删除文件会使得该文件相关的数据块被释放。只要被删除的文件还在/trash目录中，用户就可以恢复这个文件。

NN切换
hdfs haadmin -transitionToActive/transitionToStandby

RM切换
yarn rmadmin -transitionToActive/transitionToStandby

但是，这种方式在启用了ZKFC做自动失效恢复的状态下是不允许修改的，提示信息里只说了可以强制执行，但是没有提供命令，其实强制切换主备命令很简单。加个forcemanual就好了。

强制切换
yarn rmadmin -transitionToActive --forcemanual rm1