随着全球经济的不断发展，大数据时代早已悄悄到来，而Hadoop又是大数据环境的基础，想入门大数据行业首先需要了解Hadoop的知识。2017年年初apache发行了Hadoop3.0，也意味着一直有一群人在对Hadoop不断的做优化，不仅如此，各个Hadoop的商业版本也有好多公司正在使用，这也印证了它的商业价值。
读者可以通过阅读“一文读懂Hadoop”系列文章，对Hadoop技术有个全面的了解，它涵盖了Hadoop官网的所有知识点，并且通俗易懂，英文不好的读者完全可以通过阅读此篇文章了解Hadoop。
本期独家内容“一文读懂Hadoop”系列文章将根据先介绍Hadoop，继而分别详细介绍HDFS、MAPREDUCE、YARN的所有知识点的框架，分为四期内容在近几天推送。敬请关注后续内容。
本期内容为大家详解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.3 metadata组成
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上所有数据块的列表。
HDFS数据节点
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的统一调度下进行数据块的创建、删除和复制。
HDFS架构
Namenode和Datanode被设计成可以在普通的商用机器上运行。这些机器一般运行着GNU/Linux操作系统(OS)。HDFS采用Java语言开发，因此任何支持Java的机器都可以部署Namenode或Datanode。由于采用了可移植性极强的Java语言，使得HDFS可以部署到多种类型的机器上。一个典型的部署场景是一台机器上只运行一个Namenode实例，而集群中的其它机器分别运行一个Datanode实例。这种架构也可以在一台机器上运行多个Datanode，但这样的情况比较少见。
集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的管理者，用户数据永远不会流过Namenode。
4.1.1 通信协议
所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode，通过ClientProtocol协议与Namenode交互。而Datanode使用DatanodeProtocol协议与Namenode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。在设计上，Namenode不会主动发起RPC，而是响应来自客户端或 Datanode 的RPC请求。
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.2.2 磁盘平衡器
Diskbalancer是一个命令行工具，可以将数据均匀分布在数据节点的所有磁盘上。此工具不同于平衡器，它负责群集范围的数据平衡。由于几个原因，数据可能在节点上的磁盘之间具有不均匀分布。这可能是由于大量的写入和删除或由于更换磁盘而发生的。该工具针对给定的数据编码进行操作，并将块从一个磁盘移动到另一个磁盘。
4.2.1.2.2.1 架构
磁盘平衡器通过创建计划进行操作，然后在数据节点上执行该计划。一个计划是一组描述两个磁盘之间移动数据的语句。一个计划由多个步骤组成。移动步骤具有源磁盘，目标磁盘和要移动的字节数。可以针对操作数据节点执行计划。
一共包含3个阶段,Discover(发现)到Plan(计划),再从Plan(计划)到Execute(执行):
4.2.1.2.2.1.1 Discover
发现阶段做的事情实际上就是通过计算各个节点内的磁盘使用情况,然后得出需要数据平衡的磁盘列表.这里会通过Volume Data Density磁盘使用密度的概念作为一个评判的标准,这个标准值将会以节点总使用率作为比较值.举个例子,如果一个节点,总使用率为75%,就是0.75,其中A盘使用率0.5(50%),那么A盘的volumeDataDensity密度值就等于0.75-0.5=0.25.同理,如果超出的话,则密度值将会为负数.于是我们可以用节点内各个盘的volumeDataDensity的绝对值来判断此节点内磁盘间数据的平衡情况,如果总的绝对值的和越大,说明数据越不平衡,这有点类似于方差的概念.Discover阶段将会用到如下的连接器对象:
DBNameNodeConnector
JsonConnector
NullConnector
其中第一个对象会调用到Balancer包下NameNodeConnector对象,以此来读取集群节点,磁盘数据情况。
4.2.1.2.2.1.2 Plan
拿到上一阶段的汇报结果数据之后,将会进行执行计划的生成.Plan并不是一个最小的执行单元,它的内部由各个Step组成.Step中会指定好源、目标磁盘.这里的磁盘对象是一层经过包装的对象:DiskBalancerVolume,并不是原来的FsVolume.这里顺便提一下DiskBalancer中对磁盘节点等概念的转化:
DiskBalancerCluster.通过此对象可以读取到集群中的节点信息,这里的节点信息以DiskBalancerDataNode的方式所呈现；
DiskBalancerDataNode.此对象代表的是一个包装好后的DataNode；
DiskBalancerVolume和DiskBalancerVolumeSet.DataNode磁盘对象以及磁盘对象集合.DiskBalancerVolumeSet内的磁盘存储目录类型需要是同种StorageType。
4.2.1.2.2.1.3 Execute
最后一部分是执行阶段,所有的plan计划生成好了之后,就到了执行阶段.这些计划会被提交到各自的DataNode上,然后在DiskBalancer类中进行执行.DiskBalancer类中有专门的类对象来做磁盘间数据平衡的工作,这个类名称叫做DiskBalancerMover.在磁盘间数据平衡的过程中,高使用率的磁盘会移动数据块到相对低使用率的磁盘,等到满足一定阈值关系的情况下时,DiskBalancer会渐渐地退出.在DiskBalancer的执行阶段,有以下几点需要注意：
带宽的限制.DiskBalancer中同样可以支持带宽的限制,默认是10M,通过配置dfs.disk.balancer.max.disk.throughputInMBperSec进行控制；
失败次数的限制.DiskBalancer中会存在失败次数的控制.在拷贝block数据块的时候,出现IOException异常,会进行失败次数的累加计数,如果超出最大容忍值,DiskBalancer也会退出；
数据平衡阈值控制.DiskBalancer中可以提供一个磁盘间数据的平衡阈值,以此作为是否需要继续平衡数据的标准,配置项为dfs.disk.balancer.block.tolerance.percent。
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.4.5 离线Edits文件视图
离线Edits文件视图是解析Edits日志文件的工具。当前处理器主要用于不同格式之间的转换，包括可读且比本地二进制格式更容易编辑的XML。该工具可以解析Edits日志文件格式（大致Hadoop 0.19）和更高版本。该工具仅对文件操作，它不需要运行Hadoop集群。
支持的输入格式：
binary：Hadoop在内部使用的本地二进制格式；
xml：XML格式，由xml处理器生成，如果filename具有.xml（不区分大小写）扩展名，则使用。
离线Edits文件视图提供了多个输出处理器（除非另有说明，否则处理器的输出可以转换回原始Edits日志文件）：
binary：Hadoop在内部使用的本地二进制格式；
xml：XML格式；
stats：打印出统计信息，不能转换回Edits日志文件。
4.2.1.4.6 离线Image文件视图
离线Image文件视图是一个工具，用于将hdfs fsimage文件的内容转储为可读的格式，并提供只读WebHDFS API，以允许离线分析和检查Hadoop集群的命名空间。该工具能够相对快速地处理非常大的image文件。该工具处理Hadoop版本2.4及更高版本中包含的布局格式。如果要处理较早的布局格式，可以使用oiv_legacy Command的离线Image文件视图。如果该工具无法处理fsimage文件，它会完全退出。另外，离线Image文件视图不需要运行Hadoop集群。它完全离线运行。
离线Image文件视图提供了几个输出处理器：
Web是默认的输出处理器。它启动一个HTTP服务器，公开只读WebHDFS API。用户可以通过使用HTTP REST API交互地查看命名空间；
XML创建fsimage的XML文档，并包含fsimage中的所有信息。此处理器的输出可通过XML工具进行自动处理和分析；
FileDistribution是用于分析命名空间Image中文件大小的工具。为了运行工具，应该通过指定maxSize和一个步骤来定义整数[0，maxSize]的范围。整数范围被分成指定步长的段：[0，s [1]，...，s [n-1]，maxSize]，并且处理器计算系统中有多少文件落入每个段（s [i -1]，s [i]）。请注意，大于maxSize的文件总是落入最后一个段。默认情况下，输出文件格式化为一个制表符分隔的两个列表：Size和NumFiles。其中Size代表段的开始，numFiles是形成Image的文件数，该大小落在该段中。通过指定选项-format，输出文件将以可读的方式格式化；
分隔：生成一个文本文件，其中包含inode和inode下的inode所共有的所有元素，用分隔符分隔。默认分隔符为\t，但可以通过-delimiter参数更改；
ReverseXML：与XML处理器功能相反，它从XML文件重建fsimage。此处理器可以轻松地创建fsimages进行测试。
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。
4.2.2 辅助功能
4.2.2.1 浏览器界面
典型的HDFS安装配置Web服务器以通过可配置的TCP端口公开HDFS命名空间。这允许用户使用web浏览器导航HDFS命名空间并查看其文件的内容。
NameNode和DataNode每个都运行内部Web服务器，以显示有关集群当前状态的基本信息。如果使用默认配置，NameNode 首页位于http://namenode-name:9870/(http://namenode-name:9870/(hadoop3.x)（hadoop3.X）。它列出集群中的DataNode和集群的基本统计信息。Web界面也可以用于浏览文件系统（使用NameNode首页上的“浏览文件系统”链接）。
4.2.2.2 插件
有一种用插件访问其内部数据的方式，将hadoop-eclipse-plugin-version.jar包拷贝到eclipse中的plugins目录下，并进行相应的配置，即可直接用eclipse访问HDFS的数据，已及对其进行操作，操作方式与在windows环境操作文件相似。
4.2.2.3 JAVA编程
HDFS提供了一个FileSystem Java API,支持用写java代码的方式来访问HDFS的数据。
4.2.3 可扩展性
现在，Hadoop已经运行在上千个节点的集群上。HDFS集群只有一个NameNode节点。目前，NameNode上可用内存大小是一个主要的扩展限制。在超大型的集群中，增大HDFS存储文件的平均大小能够增大集群的规模，而不需要增加NameNode的内存。默认配置也许并不适合超大规模的集群。
4.2.4 文件权限和安全性
这里的文件权限和其他常见平台如Linux的文件权限类似。R:read w:write x:execute权限x对于文件忽略，对于文件夹表示是否允许访问其内容。如果zhangsan在linux系统中使用hadoop命令创建一个文件，那么这个文件在HDFS中的owner就是zhangsan。
目前，安全性不仅仅限于简单的文件权限。HDFS还支持网络验证协议（比如Kerberos）来对用户身份进行验证和对数据进行加密传输。
4.2.4.1 HDFS权限指南
Hadoop分布式文件系统（HDFS）为共享大多数POSIX模型的文件和目录实现了一个权限模型。每个文件和目录都与所有者和组相关联。文件或目录对作为所有者的用户，对于该组成员的其他用户以及对所有其他用户具有单独的权限。对于文件，读取文件需要r权限，并且需要w权限写入或附加到文件。对于目录，需要r权限列出目录的内容，需要w权限才能创建或删除文件或目录，并且需要x权限才能访问目录的子目录。
与POSIX模型相反，没有针对文件的setuid或setgid位，因为没有可执行文件的概念。对于目录，没有setuid或setgid bits目录作为简化。防止除超级用户、目录所有者或文件所有者之外的任何人删除或移动目录中的文件。总的来说，文件或目录的权限是它的模式。通常，将使用用于表示和显示模式的Unix习惯，包括使用八进制数。创建文件或目录时，其所有者是客户端进程的用户标识，其组是父目录（BSD规则）的组。
HDFS还为POSIX ACL（访问控制列表）提供了可选的支持，以通过针对特定命名用户或命名组的细粒度规则扩充文件权限。访问HDFS的每个客户端进程都具有由用户名和组列表组成的两部分身份。每当HDFS必须对客户端进程访问的文件或目录foo执行权限检查时：
如果用户名与foo的所有者匹配，则测试所有者权限;
否则，如果foo的组匹配组列表的任何成员，则测试组权限；
否则，将测试foo的其他权限。
如果权限检查失败，则客户端操作失败。
4.3 HDFS高可用性（QJM）
在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个集群都有一个NameNode，如果该机器或进程不可用，则作为整体的集群将不可用，直到NameNode被重新启动或在单独的机器上启动。
这会以两种主要方式影响HDFS集群的总可用性：
在计划外事件（如计算机崩溃）的情况下，群集将不可用，直到操作员重新启动NameNode；
计划的维护事件（如NameNode计算机上的软件或硬件升级）将导致集群停机时间的窗口。
HDFS高可用性功能通过在具有热备份的主/从配置中提供在同一集群中运行两个（以及3.0.0或更多个）冗余NameNode的选项来解决上述问题。这允许在机器崩溃的情况下快速故障切换到新的NameNode，或者出于计划维护的目的，由管理员主动发起故障切换。
4.3.1 原理
hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager，这是一个基于Paxos算法实现的HDFS HA方案，它给出了一种较好的解决思路和方案, 在典型的HA群集中，两个或多个单独的计算机配置为NameNode。在任何时间点，只有一个NameNode处于活动状态，而其他的处于待机状态。活动NameNode负责集群中的所有客户端操作，而Standby只维护足够的状态以在必要时提供快速故障转移。示意图如下：
为了使备用节点保持其与活动节点同步的状态，两个节点都与一组称为“日志节点”（JN）的独立守护进程通信。当活动节点执行任何命名空间修改时，它持久地将修改的记录记录到这些JN中的大多数。备用节点能够从JN读取编辑。
基本原理就是用2N+1台 JN 存储Edits，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功。当然这个算法所能容忍的是最多有N台机器挂掉，如果多于N台挂掉，这个算法就失效了。这个原理是基于Paxos算法。
在HA架构里面SecondaryNameNode这个角色已经不存在了，为了保持standby NN时时的与主Active NN的元数据保持一致，他们之间交互通过一系列守护的轻量级进程JournalNode
任何修改操作在 Active NN上执行时，JN进程同时也会记录修改log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log，然后同步到自己的的目录镜像树里面，如下图：
当发生故障时，Active的 NN 挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。
为了提供快速故障转移，还必需备用节点具有关于集群中块的位置的最新信息。为了实现这一点，DataNode被配置有所有NameNode的位置，并且向所有NameNode发送块位置信息和心跳。
4.3.2 QJM的主要优势
不需要配置额外的高共享存储，降低了复杂度和维护成本；
消除spof；
系统健壮的程度是可配置的；
JN不会因为其中一台的延迟而影响整体的延迟，而且也不会因为JN的数量增多而影响性能（因为NN向JN发送日志是并行的）。
4.3.3 只有一个NN能命令DN
每个NN改变状态的时候，向DN发送自己的状态和一个序列号；
DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active；
如果这时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。
4.3.4 只有一个NN响应客户端
访问standby nn的客户端直接失败。在RPC层封装了一层，通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN，对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试次数和时间。
Hadoop提供了ZKFailoverController角色，部署在每个NameNode的节点上，作为一个deamon进程, 简称zkfc，示例图如下：
4.3.5 FailoverController组成
HealthMonitor：监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成；
ActiveStandbyElector：管理和监控自己在ZK中的状态；
ZKFailoverController：它订阅HealthMonitor 和ActiveStandbyElector 的事件，并管理NameNode的状态。
4.3.6 ZKFailoverController职责
健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态；
会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN，将会得到这把锁，升级为主NN，同时标记状态为Active；
当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠，目前可以支持两个以上NN；
master选举：如上所述，通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断哪个NameNode为Active状态。
注意，在HA群集中，Standby NameNode还执行命名空间状态的检查点，因此不需要在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。
4.4 HDFS高可用性（NFS）
NFS的方式的HA的配置与启动，和QJM方式基本上是一样，唯一不同的地方就是active namenode和standby namenode共享edits文件的方式。QJM方式是采用journalnode来共享edits文件，而NFS方式则是采用NFS远程共享目录来共享edits文件。
NFS允许用户像访问本地文件系统一样访问远程文件系统，而将NFS引入HDFS后，用户可像读写本地文件一样读写HDFS上的文件，大大简化了HDFS使用，这是通过引入一个NFS gateway服务实现的，该服务能将NFS协议转换为HDFS访问协议，具体如下图所示。
4.5 HDFS Federation
4.5.1 HDFS的两个主要层
命名空间
由目录，文件和块组成；
它支持所有与命名空间相关的文件系统操作，如创建，删除，修改和列出文件和目录。
块存储服务
包括两部分：
块管理（在Namenode中执行）
①通过处理注册和定期心跳提供Datanode集群成员身份；
②处理并维护块的位置；
③支持块相关操作，如创建，删除，修改和获取块位置；
④管理副本放置，低复制块的块复制，以及删除超过复制的块。
存储
由Datanodes通过在本地文件系统上存储块并允许读/写访问来提供。
先前的HDFS架构仅允许整个集群使用单个命名空间。在该配置中，单个Namenode管理命名空间。HDFS Federration通过向HDFS添加对多个Namenodes /命名空间的支持来解决此限制。
4.5.2 原理
单Active NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，NN成为了性能的瓶颈。
常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。
为了水平扩展名称服务，Federration使用多个独立的Namenodes/命名空间。Namenodes之间管理的数据是共享的，但同时也是独立的，不需要彼此协调。Datanodes被所有Namenode用作块的公共存储。每个Datanode注册集群中的所有Namenode。Datanodes发送定期心跳和块报告。它们还处理来自Namenode的命令。
为了解决这个问题,Hadoop 2.x、Hadoop 3.x提供了HDFS Federation, 示意图如下：
多个NN共用一个集群里的存储资源，每个NN都可以单独对外提供服务。
每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储。
DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况。
如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录。
4.5.3 设计优势
改动最小，向前兼容；现有的NN无需任何配置改动；如果现有的客户端只连某台NN的话，代码和配置也无需改动；
分离命名空间管理和块存储管理；
客户端挂载表：通过路径自动对应NN、使Federation的配置改动对应用透明。
4.5.4 ViewF
View文件系统（ViewFs）提供了一种管理多个Hadoop文件系统命名空间（或命名空间卷）的方法。它对于在HDFS Federation中具有多个命名空间的集群特别有用。ViewF类似于一些Unix/Linux系统中的客户端安装表。ViewF可用于创建个性化命名空间视图以及每个集群的常见视图。
View文件系统具有多个集群的Hadoop系统的上下文中显示，每个集群可以联合到多个命名空间中，以提供每个群集的全局命名空间，以便应用程序可以以类似于联合前的方式运行。
4.5.4.1 单个Namenode集群
在HDFS联合之前，集群具有单个命名空间，为该集群提供单个文件系统命名空间。如果有多个集群。则每个集群的文件系统命名空间是完全独立和不相交的。此外，物理存储不是在集群之间共享（即Datanodes不是跨集群共享的）。
4.5.4.2 Federation和ViewF
如果有多个集群。每个集群都有一个或多个命名空间。每个namenode都有自己的命名空间。namenode属于一个且仅一个集群。但是与单个namenode集群不同的是：同一集群中的namenode共享该集群的物理存储。集群中的命名空间与前面一样是独立的。
操作根据存储需求决定群集中每个namenode上存储的内容。例如，他们可以将所有用户数据（/user/<username>）放在一个命名空间中，将所有feed数据（/data）放置在另一个命名空间中，将所有项目（/projects）放在另一个命名空间等等。
4.5.4.3 使用ViewF的每个集群的全局命名空间
为了提供透明度，ViewF文件系统（即客户端装载表）用于创建每个集群独立的集群命名空间视图，这与单个Namenode集群中的命名空间类似。客户端安装表（如Unix安装表），并使用旧的命名约定安装新的命名空间卷。下图显示了装载四个命名空间卷/user，/data，/projects和/tmp的装载表：
ViewF实现了Hadoop文件系统接口，就像HDFS和本地文件系统一样。这是一个普通的文件系统，它只允许链接到其他文件系统。所有shell命令与ViewFS一起使用，与HDFS和本地文件系统一样。
5. 命令指南
所有的hadoop命令均由bin/hdfs脚本引发。不指定参数运行hdfs脚本会打印所有命令的描述。
用法：hdfs [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]
Hadoop有一个选项解析框架用于解析一般的选项和运行类。
由于字数限制，本文分为上下两篇分别在头条和二条推送，后半部分内容请见今日二条推送。
原文发布时间为：
本文作者：
本文来自云栖社区合作伙伴“数据派THU”，了解相关信息可以关注“数据派THU”微信公众号
