分布式文件系统——HDFS
HDFS概述HDFS发展历史HDFS的设计目标HDSF应用场景
适合的应用场景不适合的应用场景 HDFS架构HDFS的基本原理
NameNode
概念：作用： DataNode HDFS的工作机制
HDFS写数据流程HDFS读数据流程HDFS 在读取文件的时候，如果其中一个块突然损坏了怎么办HDFS 在上传文件的时候，如果其中一个 DataNode 突然挂掉了怎么办 HDFS故障类型和其检测方法
HDFS读写故障的处理：DataNode 故障处理 HDFS副本机制
HDFS文件副本机制HDFS副本放置策略（机架感知）： HDFS的元数据辅助管理
FsImage和EditsSecondaryNameNode的作用SecondaryNameNode出现的原因**SecondaryNameNode唤醒合并的规则**SecondaryNameNode工作过程fsimage 中的文件信息查看edits中的文件信息查看NameNode元数据恢复 HDFS的shell命令
Shell命令行客户端Shell命令选项常用的Shell命令 HDFS的高级使用命令
HDFS的安全模式HDFS基准测试
测试写入速度测试读取速度清除测试数据 HDFS的API操作
HDFS的JAVA API操作配置Windows下Hadoop环境导入Maven依赖使用文件系统方式访问数据
涉及的主要类获取FileSystem方式获取HDFS上某一个路径下的所有文件在HDFS中创建一个目录在HDFS中创建一个文件文件下载文件的上传合并小文件hdfs访问权限控制 HDFS的高可用机制
高可用简介：组件介绍 Hadoop的联邦机制(Federation)
**背景概述**Federation架构设计**HDFS Federation不足** HDFS的其他功能
不同集群之间的数据复制集群内部文件拷贝scp
本地复制到远程远程复制到本地 跨集群之间的数据拷贝distcpArchive档案的使用
如何创建Archive如何查看Archive如何解压ArchiveArchive注意事项 Snapshot快照的使用
快照使用基本语法快照操作实际案例 HDFS的Trash回收站功能
配置检查点恢复回收站数据清空回收站注意点 参考资料
HDFS概述The Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems. However, the differences from other distributed file systems are significant. HDFS is highly fault-tolerant and is designed to be deployed on low-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large data sets. HDFS relaxes a few POSIX requirements to enable streaming access to file system data. HDFS was originally built as infrastructure for the Apache Nutch web search engine project. HDFS is part of the Apache Hadoop Core project.
HDFS（Hadoop Distributed File System）是 Apache Hadoop 项目的一个子项目. Hadoop 非常适于存储大型数据 (比如 TB 和 PB), 其就是使用 HDFS 作为存储系统. HDFS 使用多台计算机存储文件, 并且提供统一的访问接口, 像是访问一个普通文件系统一样使用分布式文件系统.
分布式文件系统解决的问题就是大数据存储。它们是横跨在多台计算机上的存储系统。分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理超大规模数据提供所需的扩展能力。
HDFS发展历史Doug Cutting 在做 Lucene 的时候, 需要编写一个爬虫服务, 这个爬虫写的并不顺利, 遇到 了一些问题, 诸如: 如何存储大规模的数据, 如何保证集群的可伸缩性, 如何动态容错等。2003年的时候, Google 发布了三篇论文, 被称作为三驾马车, 其中有一篇叫做 GFS, 是描述了 Google 内部的一个叫做 GFS 的分布式大规模文件系统, 具有强大的可伸缩性和容错。Doug Cutting 后来根据 GFS 的论文, 创造了一个新的文件系统, 叫做 HDFS。 HDFS的设计目标
硬件是不可靠的：HDFS将有成千上万台机器组成，每一个组成部分，都有可能出现故障，因此，故障检测和自动恢复是HDFS的核心设计目标。流式的数据访问：HDFS上的应用于一般的应用程序不同，他们只要是以流式的读取文件数据，HDFS被设计成适合批量处理，而不是用户交互式的，相较于数据访问的反应时间，更注重于数据访问的高吞吐量。支持超大文件存储：典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。简单的一致性模型：大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。移动计算的代价比之移动数据的代价更低：一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好。可移植性：在异构的硬件和软件平台上的可移植性。这将推动需要大数据集的应用更广泛地采用HDFS作为平台。 HDSF应用场景 适合的应用场景
存储非常大的文件：这里非常大指的是几百M、G、或者TB级别，需要高吞吐量，对延时没有要求。采用流式的数据访问方式: 即一次写入、多次读取，数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作 ，且不支持文件的随机修改。正因为如此，HDFS适合用来做大数据分析的底层存储服务，并不适合用来做网盘等应用，因为，修改不方便，延迟大，网络开销大，成本太高。运行于商业硬件上: Hadoop不需要特别贵的机器，可运行于普通廉价机器，可以处节约成本需要高容错性为数据存储提供所需的扩展能力 不适合的应用场景
低延时的数据访问：对延时要求在毫秒级别的应用，不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时大量小文件 文件的元数据保存在NameNode****的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。 经验而言，一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件块，则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。多方读写，需要任意的文件修改 HDFS采用追加（append-only）的方式写入数据。不支持文件任意offset的修改，HDFS适合用来做大数据分析的底层存储服务，并不适合用来做.网盘等应用，因为，修改不方便，延迟大，网络开销大，成本太高。 HDFS架构
HDFS采用Master/Slave架构，一个HDFS集群有两个重要的角色，分别是Namenode和Datanode。Namenode是管理节点，负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。Datanode是实际存储数据的节点。HDFS暴露了文件系统的命名空间，用户能够以操作文件的形式在上面操作数据。
HDFS的四个基本组件:HDFS Client、NameNode、DataNode 和 Secondary NameNode。
Client：就是客户端。
文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储与 NameNode 交互，获取文件的位置信息。与 DataNode 交互，读取或者写入数据。Client 提供一些命令来管理 和访问HDFS，比如启动或者关闭HDFS。
NameNode：就是 master，它是一个主管、管理者。
管理 HDFS 的名称空间管理数据块（Block）映射信息配置副本策略处理客户端读写请求。
DataNode：就是Slave。NameNode 下达命令，DataNode 执行实际的操作。
存储实际的数据块。执行数据块的读/写操作。Secondary NameNode：并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。辅助 NameNode，分担其工作量。定期合并 fsimage和fsedits，并推送给NameNode。在紧急情况下，可辅助恢复 NameNode。
NameNode在内存中保存着整个文件系统的名称空间和文件数据块的地址映射整个HDFS可存储的文件数受限于NameNode的内存大小NameNode元数据信息 文件名，文件目录结构，文件属性(生成时间，副本数，权限)每个文件的块列表。 以及列表中的块与块所在的DataNode之间的地址映射关系 在内存中加载文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息) 数据会定期保存到本地磁盘（fsImage文件和edits文件）NameNode文件操作 NameNode负责文件元数据的操作 DataNode负责处理文件内容的读写请求，数据流不经过NameNode，会询问它跟那个DataNode联系NameNode副本文件数据块到底存放到哪些DataNode上，是由NameNode决定的，NameNode根据全局情况做出放置副本的决定NameNode心跳机制全权管理数据块的复制，周期性的接受心跳和块的状态报告信息（包含该DataNode上所有数据块的列表） 若接受到心跳信息，NameNode认为DataNode工作正常，如果在10分钟后还接受到不到DataNode的心跳，那么NameNode认为DataNode已经宕机 ,这时候NN准备要把DN上的数据块进行重新的复制。 块的状态报告包含了一个DataNode上所有数据块的列表，blocks report 每个1小时发送一次. 作用：
- NameNode是HDFS的核心。NameNode也称为Master。NameNode仅存储HDFS的元数据：文件系统中所有文件的目录树，并跟踪整个集群中的文件。NameNode不存储实际数据或数据集。数据本身实际存储在DataNodes中。NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。NameNode并不持久化存储每个文件中各个块所在的DataNode的位置信息，这些信息会在系统启动时从数据节点重建。NameNode对于HDFS至关重要，当NameNode关闭时，HDFS / Hadoop集群无法访问。NameNode是Hadoop集群中的单点故障。NameNode所在机器通常会配置有大量内存（RAM）。
- Data Node以数据块的形式存储HDFS文件DataNode也称为Slave。NameNode和DataNode会保持不断通信。DataNode启动时，它将自己发布到NameNode并汇报自己负责持有的块列表。当某个DataNode关闭时，它不会影响数据或群集的可用性。NameNode将安排由其他DataNode管理的块进行副本复制。DataNode所在机器通常配置有大量的硬盘空间。因为实际数据存储在DataNode中。DataNode会定期（dfs.heartbeat.interval配置项配置，默认是3秒）向NameNode发送心跳，如果NameNode长时间没有接受到DataNode发送的心跳， NameNode就会认为该DataNode失效。block汇报时间间隔取参数dfs.blockreport.intervalMsec,参数未配置的话默认为6小时.
NameNode负责管理整个文件系统元数据；
DataNode负责管理具体文件数据块存储；
Secondary NameNode协助NameNode进行元数据的备份。
HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向NameNode申请来进行。
HDFS写数据流程漫画图解
详细步骤解析：
- client发起文件上传请求，通过RPC与NameNode建立通讯，NameNode检查目标文件是否已存在，父目录是否存在，返回是否可以上传；client请求第一个 block该传输到哪些DataNode服务器上；NameNode根据配置文件中指定的备份数量及副本放置策略进行文件分配，返回可用的DataNode的地址，如：A，B，C；client请求3台DataNode中的一台A上传数据（本质上是一个RPC调用，建立pipeline），A收到请求会继续调用B，然后B调用C，将整个pipeline建立完成，后逐级返回client；client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（默认64K），A收到一个packet就会传给B，B传给C；A每传一个packet会放入一个应答队列等待应答。数据被分割成一个个packet数据包在pipeline上依次传输，在pipeline反方向上，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipeline ack发送给client;当一个block传输完成之后，client再次请求NameNode上传第二个block到服务器。
漫画图解：
图解：
详细步骤解析：
- Client向NameNode发起RPC请求，来确定请求文件block所在的位置；NameNode会视情况返回文件的部分或者全部block列表，对于每个block，NameNode都会返回含有该block副本的DataNode地址；这些返回的DN地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离Client近的排靠前；心跳机制中超时汇报的DN状态为STALE，这样的排靠后；Client选取排序靠前的DataNode来读取block，如果客户端本身就是DataNode,那么将从本地直接获取数据；底层上本质是建立Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，直到这个块上的数据读取完毕；当读完列表的block后，若文件读取还没有结束，客户端会继续向NameNode获取下一批的block列表；读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，客户端会通知NameNode，然后再从下一个拥有该block副本的DataNode继续读。read方法是并行的读取block信息，不是一块一块的读取；NameNode只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；最终读取来所有的block会合并成一个完整的最终文件。
客户端读取完 DataNode 上的块之后会进行 checksum 验证，也就是把客户端读取 到本地的块与 HDFS 上的原始块进行校验，如果发现校验结果不一致，客户端会 通知 NameNode，然后再从下一个拥有该 block 副本的 DataNode 继续读。 HDFS 在上传文件的时候，如果其中一个 DataNode 突然挂掉了怎么办
客户端上传文件时与 DataNode 建立 pipeline 管道，管道的正方向是客户端向 DataNode 发送的数据包，管道反向是 DataNode 向客户端发送 ack 确认，也就是 正确接收到数据包之后发送一个已确认接收到的应答。 当 DataNode 突然挂掉了，客户端接收不到这个 DataNode 发送的 ack 确认，客户 端会通知 NameNode，NameNode 检查该块的副本与规定的不符，NameNode 会通知 DataNode 去复制副本，并将挂掉的 DataNode 作下线处理，不再让它参与文件上 传与下载。 HDFS故障类型和其检测方法
HDFS读写故障的处理： DataNode 故障处理 HDFS副本机制 HDFS文件副本机制HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块，这个数据块被称为block，除了最后一个，所有的数据块都是同样大小的。
为了容错，文件的所有block都会有副本。每个文件的数据块大小和副本系数都是可配置的。所有的文件都是以 block 块的方式存放在 HDFS 文件系统当中,作用如下
- 一个文件有可能大于集群中任意一个磁盘，引入块机制,可以很好的解决这个问题使用块作为文件存储的逻辑单位可以简化存储子系统块非常适合用于数据备份进而提供数据容错能力副本优点是安全，缺点是占空间。
在 Hadoop1 当中, 文件的 block 块默认大小是 64M, hadoop2 当中, 文件的 block 块大小**默认是 128M（134217728字节）。**假设文件大小是100GB，从字节位置0开始，每128MB字节划分为一个block，依此类推，可以划分出很多的block。每个block就是128MB大小。
block块的大小可以通过 hdfs-site.xml 当中的配置文件进行指定，Hadoop默认的副本数为3,也就是每个block会存三份。
dfs.block.size 块大小以字节为单位
注意当一个文件的大小不足128M时，比如文件大小为2M，那么这个文件也占用一个block，但是这个block实际只占2M的空间，所以从某种意义上来讲，block只是一个逻辑单位。 HDFS副本放置策略（机架感知）：
HDFS分布式文件系统的内部有一个副本存放策略，默认副本数为3,在这里以副本数=3为例：
第一副本：优先放置到离写入客户端最近的DataNode节点，如果上传节点就是DataNode，则直接上传到该节点，如果是在集群外提交，则随机挑选一台磁盘不太慢，CPU不太忙的节点。
第二个副本：放置在与第一个同机架的不同机器中
第三个副本：放置在另一个机架中, 某一个服务器中
通过机架感知的过程，NameNode可以确定每一个 DataNode所属的机架id。一个简单但没有优化的策略就是将副本存放在不同的机架上（上边介绍的这种），这样可以防止当整个机架失效时数据的丢失，并且允许读数据的时候充分利用多个机架的带宽。这种策略设置可以将副本均匀分布在集群中，有利于当组件失效的情况下的均匀负载。
也就是说， HDFS系统的机架感知策略的优势是防止由于某个机架失效导致数据丢失，并且允许读取数据时充分利用多个机架的带宽。HDFS会尽量让读取任务去读取距离客户端最近的副本数据来减少整体带宽消耗，从而实现降低整体的带宽延时。
对于副本距离的计算公式，HDFS采用如下约定：
Distance(Rack 1/D1 Rack1/D1)=0 //同一台服务器的距离为0Distance(Rack 1/D1 Rack1/D3)=2 //通机架不同服务器的距离为2Distance(Rack 1/D1 Rack2/D1)=4 //不同机架服务器距离为4
通常而言，一个Rack共享一个电源，一根网线，一个交换机，HDFS备份通常在同一个Rack上存储一份，在另外一个Rack上存储两份（另外：HDFS以block为单位，备份也要以block为单位）
通过机架感知，处于工作状态的HDFS总是设法确保数据块的三个副本(或者更多)中至少有两个在同一机架，至少有一个处在不同机架。
HDFS的元数据辅助管理当 Hadoop 的集群当中, NameNode的所有元数据信息都保存在了 FsImage 与 Eidts 文件当中, 这两个文件就记录了所有的数据的元数据信息, 元数据信息的保存目录配置在了 hdfs-site.xml 当中
FsImage和Editsdfs.namenode.name.dir file:///export/serverss/hadoop2.7.5/hadoopDatas/namenodeDatas > dfs.namenode.edits.dir file:///export/serverss/hadoop-2.7.5/hadoopDatas/nn/edits
edits:
edits 是在NameNode启动时对整个文件系统的快照存放了客户端最近一段时间的操作日志
客户端对 HDFS 进行写文件时会首先被记录在 edits文件中edit 修改时元数据也会更新
fsimage：
fsimage是在NameNode启动时对整个文件系统的快照
NameNode 中关于元数据的镜像, 一般称为检查点, fsimage存放了一份比较完整的元数据信息
因为 Fsimage是 NameNode 的完整的镜像, 如果每次都加载到内存生成树状拓扑结构，这是非常耗内存和CPU, 所以一般开始时对 NameNode 的操作都放在 edits 中
fsimage 内容包含了 NameNode 管理下的所有 DataNode 文件及文件 block 及 block 所在的 DataNode 的元数据信息.
随着edits`内容增大, 就需要在一定时间点和 fsimage合并
SecondaryNameNode的作用SecondaryNameNode的作用是合并fsimage和edits文件。
NameNode的存储目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候会首先读取整个fsimage文件，将信息装载到内存中。
Edits文件存储日志信息，在NameNode上所有对目录的操作，增加，删除，修改等都会保存到edits文件中，并不会同步到fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并。
所以当NameNode启动的时候，首先装载fsimage文件，然后按照edits中的记录执行一遍所有记录的操作，最后把信息的目录树写入fsimage中，并删掉edits文件，重新启用新的edits文件。
SecondaryNameNode出现的原因但是如果NameNode执行了很多操作的话，就会导致edits文件会很大，那么在下一次启动的过程中，就会导致NameNode的启动速度很慢，慢到几个小时也不是不可能，所以出现了SecondNameNode。
SecondaryNameNode唤醒合并的规则SecondaryNameNode 会按照一定的规则被唤醒，进行fsimage和edits的合并，防止文件过大。
合并的过程是，将NameNode的fsimage和edits下载到SecondryNameNode 所在的节点的数据目录，然后合并到fsimage文件，最后上传到NameNode节点。合并的过程中不影响NameNode节点的操作
SecondaryNameNode被唤醒的条件可以在core-site.xml中配置：
fs.checkpoint.period：单位秒，默认值3600，检查点的间隔时间，当距离上次检查点执行超过该时间后启动检查点
fs.checkpoint.size：单位字节，默认值67108864，当edits文件超过该大小后，启动检查点core-site.xml
fs.checkpoint.period 3600 fs.checkpoint.size 67108864
SecondaryNameNode一般处于休眠状态，当两个检查点满足一个，即唤醒SecondaryNameNode执行合并过程。
SecondaryNameNode工作过程第一步：将hdfs更新记录写入一个新的文件——edits.new。第二步：将fsimage和editlog通过http协议发送至secondary namenode。第三步：将fsimage与editlog合并，生成一个新的文件——fsimage.ckpt。这步之所以要在secondary namenode中进行，是因为比较耗时，如果在namenode中进行，或导致整个系统卡顿。第四步：将生成的fsimage.ckpt通过http协议发送至namenode。第五步：重命名fsimage.ckpt为fsimage，edits.new为edits。第六步：等待下一次checkpoint触发SecondaryNameNode进行工作，一直这样循环操作。
fsimage 中的文件信息查看注意:SecondaryNameNode 在合并 edits 和 fsimage 时需要消耗的内存和 NameNode 差不多, 所以一般把 NameNode 和 SecondaryNameNode 放在不同的机器上。
使用命令 hdfs oiv
cd /export/servers/hadoop2.7.5/hadoopDatas/namenodeDatas hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xmledits中的文件信息查看
使用命令 hdfs oev
cd /export/servers/hadoop2.7.5/hadoopDatas/namenodeDatas hdfs oev -i edits_0000000000000000865-0000000000000000866 -p XML -o myedit.xmlNameNode元数据恢复
当NameNode发生故障时,我们可以通过将SecondaryNameNode中数据拷贝到NameNode存储数据的目录的方式来恢复NameNode的数据
操作步骤:
1、杀死NameNode进程
kill -9 NameNode进程号
2、删除NameNode存储的数据
rm /export/servers/hadoop-2.7.5/hadoopDatas/namenodeDatas
Configuration conf = new Configuration();
// 如果我们什么都不指定，就默认连接本地的文件系统
FileSystem fileSystem1 = FileSystem.get(conf);
System.out.println(fileSystem1.toString());
System.out.println("------------------------");
// 注意：默认情况下，windows操作hsfs，使用的是当前windows的用户名
conf= new Configuration();
conf.set("fs.defaultFS","hdfs://node1:8020");
FileSystem fileSystem2 = FileSystem.get(conf);
System.out.println(fileSystem2.toString());
System.out.println("---------------------");
// 伪装用户的操作
URI uri = new URI("hdfs://node1:8020");
conf = new Configuration();
FileSystem fileSystem3 = FileSystem.get(uri, conf, "root");
System.out.println(fileSystem3.toString());
System.out.println("------------------");
uri = new URI("hdfs://node1:8020");
conf = new Configuration();
FileSystem fileSystem4 = FileSystem.get(uri, conf);
System.out.println(fileSystem4.toString());
}
获取HDFS上某一个路径下的所有文件
// 获取HDFS上某一个路径下的所有文件
@Test
public void test02() throws Exception {
// 获取HDFS的客户端对象
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node1:8020"), new Configuration(), "root");
// 执行相关的操作(获取某一个路径下的所有文集)
RemoteIterator listFiles = fileSystem.listFiles(new Path("/aaa"), true);
while (listFiles.hasNext()){
LocatedFileStatus fileStatus = listFiles.next();
Path path = fileStatus.getPath();
System.out.println(path);
System.out.println(path.getName());
}
// 释放资源
fileSystem.close();
}
在HDFS中创建一个目录
// 在HDFS中创建一个目录
@Test
public void test03() throws Exception {
// 获取一个HDFS的客户端对象
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node1:8020"), new Configuration(), "root");
//执行相关的操作--在HDFS中创建一个目录
boolean mkdirs = fileSystem.mkdirs(new Path("/test/bbb/test1"));
System.out.println(mkdirs);
// 释放资源
fileSystem.close();
}
在HDFS中创建一个文件
// 在HDFS创建一个文件
@Test
public void test04() throws Exception {
// 获取HDFS的客户端对象
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node1:8020"), new Configuration(), "root");
// 执行相关词操作-- 向HDFS中写一个文件
FSDataOutputStream outputStream = fileSystem.create(new Path("/test/bbb/test1/test.txt"));
outputStream.write("你好，我是李旭飞".getBytes());
outputStream.flush();
// 释放资源
fileSystem.close();
}
文件下载
// 使用HDFS完成文件的下载的操作
@Test
public void test05() throws IOException {
// 获取HDFS客户端对象
Configuration conf = new Configuration();
conf.set("fs.defaultFS","hdfs://node1:8020");
FileSystem fileSystem = FileSystem.get(conf);
// 执行相关的操作
// 参数一：HDFS的地址，参数二：本地的文件路径：一定要加file:///
fileSystem.copyToLocalFile(new Path("/test/bbb/test1/test.txt"),new Path("file:///C:\Users\Dell\Desktop"));
// 释放资源
fileSystem.close();
}
文件的上传
// 完成HDFS文件的上传操作
@Test
public void test06() throws IOException {
// 获取HDFS的客户端对象
Configuration conf = new Configuration();
conf.set("fs.defaultFS","hdfs://node1:8020");
FileSystem fileSystem = FileSystem.get(conf);
// 执行相关操作-- 上传文件
fileSystem.copyFromLocalFile(new Path("file:///C:\Users\Dell\Desktop\bigSchool.txt"),new Path("/test/bbb/test1/"));
// 释放资源
fileSystem.close();
}
合并小文件
由于 Hadoop 擅长存储大文件，因为大文件的元数据信息比较少，如果 Hadoop 集群当中有大量的小文件，那么每个小文件都需要维护一份元数据信息，会大大的增加集群管理元数据的内存压力，所以在实际工作当中，如果有必要一定要将小文件合并成大文件进行一起处理,可以在上传的时候将小文件合并到一个大文件里面去。
// 假设在本地有几个小文件，需要传递到HDFS中，HDFS不推荐传递小文件，将这些个小文件合并为一个大文件，同时上传到HDFS
@Test
public void test07() throws Exception {
// 创建HDFD客户端对象
FileSystem hdfsFileSystem = FileSystem.get(new URI("hdfs://node1:8020"), new Configuration());
// 执行相关操作，创建一个文件，获取这个文件的输出流
FSDataOutputStream outputStream = hdfsFileSystem.create(new Path("/test/merge.txt"));
// 获取一个本地文件系统输入流
LocalFileSystem localFileSystem = FileSystem.getLocal(new Configuration());
// 获取某个路径下所有的小文件
RemoteIterator locatFileSystem = localFileSystem.listFiles(new Path("file:///C:\Users\Dell\Desktop\xiaowenjian"), false);
while (locatFileSystem.hasNext()){
LocatedFileStatus fileStatus = locatFileSystem.next();
Path path = fileStatus.getPath();
// FileInputStream fileInputStream = new FileInputStream(path.toString());
FSDataInputStream inputStream = localFileSystem.open(path);
IOUtils.copy(inputStream, outputStream);
IOUtils.closeQuietly(inputStream);
}
outputStream.flush();
hdfsFileSystem.close();
localFileSystem.close();
}
hdfs访问权限控制
HDFS权限模型和Linux系统类似。每个文件和目录有一个所有者（owner）和一个组（group）。文件或目录对其所有者、同组的其他用户以及所有其他用户（other）分别有着不同的权限。对文件而言，当读取这个文件时需要有r权限，当写入或者追加到文件时需要有w权限。对目录而言，当列出目录内容时需要具有r权限，当新建或删除子文件或子目录时需要有w权限，当访问目录的子节点时需要有x权限。但hdfs的文件权限需要开启之后才生效，否则在HDFS中设置权限将不具有任何意义!
HDFS的权限设置是通过hdfs-site.xml文件来设置，在搭建Hadoop集群时，将HDFS的权限关闭了，所以对HDFS的任何操作都不会受到影响的。
接下来我们将HDFS的权限开启，测试下HDFS的权限控制。
停止hdfs集群，在node1机器上执行以下命令
stop-dfs.sh
修改node1机器上的hdfs-site.xml当中的配置文件
vim hdfs-site.xml
dfs.permissions.enabled true
修改完成之后配置文件发送到其他机器上面去
scp hdfs-site.xml node2:$PWD scp hdfs-site.xml node3:$PWD
重启hdfs集群
start-dfs.sh
随意上传一些文件到我们hadoop集群当中准备测试使用
cd /export/servers/hadoop-2.7.5/etc/hadoop hadoop fs -mkdir /config hadoop fs -put *.xml /config hadoop fs -chmod 600 /config/core-site.xml
经过以上操作之后,core-site.xml文件的权限如下:
这个权限是当前所属用户root具有对core-site.xml文件的可读，可写权限。
- 使用代码准备下载文件
@Test
public void getConfig()throws Exception{
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node01:8020"), new Configuration(),"root");
fileSystem.copyToLocalFile(new Path("/config/core-site.xml"),new Path("file:///c:/core-site.xml"));
fileSystem.close();
}
当HDFS的权限开启之后，运行以上代码发现权限拒绝，不允许访问。
这是因为我们在Windows下运行HDFS的客户端，用户名一般不是root，是其他用户，所以对core-site.xml文件没有任何操作权限。
解决方法:
方式1-修改core-site.xml的文件权限
hadoop fs -chmod 777/config/core-site.xml
方式2-伪造用户
在这里，我们可以以root用户的身份去访问文件
@Test
public void getConfig()throws Exception{
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node01:8020"), new Configuration(),"root");
fileSystem.copyToLocalFile(new Path("/config/core-site.xml"),new Path("file:///c:/core-site.xml"));
fileSystem.close();
}
执行结果如下：
执行成功
HDFS的高可用机制 高可用简介：在Hadoop 中，NameNode 所处的位置是非常重要的，整个HDFS文件系统的元数据信息都由NameNode 来管理，NameNode的可用性直接决定了Hadoop 的可用性，一旦NameNode进程不能工作了，就会影响整个集群的正常使用。
在典型的HA集群中，两台独立的机器被配置为NameNode。在工作集群中，NameNode机器中的一个处于Active状态，另一个处于Standby状态。Active NameNode负责群集中的所有客户端操作，而Standby充当从服务器。Standby机器保持足够的状态以提供快速故障切换（如果需要）。
组件介绍ZKFailoverController
是基于Zookeeper的故障转移控制器，它负责控制NameNode的主备切换，ZKFailoverController会监测NameNode的健康状态，当发现Active NameNode出现异常时会通过Zookeeper进行一次新的选举，完成Active和Standby状态的切换
HealthMonitor
周期性调用NameNode的HAServiceProtocol RPC接口（monitorHealth 和 getServiceStatus），监控NameNode的健康状态并向ZKFailoverController反馈
ActiveStandbyElector
接收ZKFC的选举请求，通过Zookeeper自动完成主备选举，选举完成后回调ZKFailoverController的主备切换方法对NameNode进行Active和Standby状态的切换.
DataNode
NameNode包含了HDFS的元数据信息和数据块信息（blockmap），其中数据块信息通过DataNode主动向Active NameNode和Standby NameNode上报
共享存储系统
共享存储系统负责存储HDFS的元数据（EditsLog），Active NameNode（写入）和 Standby NameNode（读取）通过共享存储系统实现元数据同步，在主备切换过程中，新的Active NameNode必须确保元数据同步完成才能对外提供服务
Hadoop的联邦机制(Federation) 背景概述单NameNode的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NameNode进程使用的内存可能会达到上百G，NameNode成为了性能的瓶颈。因而提出了namenode水平扩展方案-- Federation。
Federation中文意思为联邦,联盟，是NameNode的Federation,也就是会有多个NameNode。多个NameNode的情况意味着有多个namespace(命名空间)，区别于HA模式下的多NameNode，它们是拥有着同一个namespace。既然说到了NameNode的命名空间的概念,这里就看一下现有的HDFS数据管理架构,如下图所示:
从上图中,我们可以很明显地看出现有的HDFS数据管理,数据存储2层分层的结构.也就是说,所有关于存储数据的信息和管理是放在NameNode这边,而真实数据的存储则是在各个DataNode下.而这些隶属于同一个NameNode所管理的数据都是在同一个命名空间下的.而一个namespace对应一个block pool。Block Pool是同一个namespace下的block的集合.当然这是我们最常见的单个namespace的情况,也就是一个NameNode管理集群中所有元数据信息的时候.如果我们遇到了之前提到的NameNode内存使用过高的问题,这时候怎么办?元数据空间依然还是在不断增大,一味调高NameNode的jvm大小绝对不是一个持久的办法.这时候就诞生了HDFS Federation的机制.
Federation架构设计HDFS Federation是解决namenode内存瓶颈问题的水平横向扩展方案。
Federation意味着在集群中将会有多个namenode/namespace。这些namenode之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的datanode被用作通用的数据块存储存储设备。每个datanode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。
Federation一个典型的例子就是上面提到的NameNode内存过高问题,我们完全可以将上面部分大的文件目录移到另外一个NameNode上做管理.更重要的一点在于,这些NameNode是共享集群中所有的DataNode的,它们还是在同一个集群内的。
这时候在DataNode上就不仅仅存储一个Block Pool下的数据了,而是多个(在DataNode的datadir所在目录里面查看BP-xx.xx.xx.xx打头的目录)。
概括起来：
多个NN共用一个集群里的存储资源，每个NN都可以单独对外提供服务。
每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储。
DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况。
HDFS Federation不足HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个，但是从单个namenode/namespace看，仍然存在单点故障：如果某个namenode挂掉了，其管理的相应的文件便不可以访问。Federation中每个namenode仍然像之前HDFS上实现一样，配有一个secondary namenode，以便主namenode挂掉一下，用于还原元数据信息。
所以一般集群规模真的很大的时候，会采用HA+Federation的部署方案。也就是每个联合的namenodes都是ha的。
HDFS的其他功能 不同集群之间的数据复制在我们实际工作当中，极有可能会遇到将测试集群的数据拷贝到生产环境集群，或者将生产环境集群的数据拷贝到测试集群，那么就需要我们在多个集群之间进行数据的远程拷贝，hadoop自带也有命令可以帮我们实现这个功能。
集群内部文件拷贝scp 本地复制到远程方式1：指定用户名，命令执行后需要再输入密码；
scp -r local_folder remote_username@remote_ip:remote_folder
方式2:没有指定用户名，命令执行后需要输入用户名和密码；
scp -r local_folder remote_ip:remote_folder
注意，如果实现了ssh免密登录之后，则不需要输入密码即可拷贝。
#复制文件-将 /root/test.txt 拷贝到 192.168.88.161 的 /root/ 目录下，文件名还是 text.txt，使用 root 用户，此时会提示输入远程 root 用户的密码。 scp /root/test.txt root@192.168.88.161:/root/ #复制文件并重命名-将 /root/test.txt 拷贝到 192.168.88.161 的 /root/ 目录下，文件名还是 text1.txt，使用 root 用户，此时会提示输入远程 root 用户的密码。 scp /root/test.txt root@192.168.88.161:/root/test1.txt #复制目录-将整个目录 /root/test/ 复制到 192.168.88.161 的 /root/ 下，即递归的复制，使用 root 用户，此时会提示输入远程 root 用户的密码。 scp -r /root/test/ root@192.168.88.161:/root/远程复制到本地
远程复制到本地 与 从本地复制到远程命令类似，不同的是 远程文件作为源文件在前，本地文件作为目标文件在后。
#复制文件-将192.168.88.162的/root目录下的test.txt拷贝到当前主机的/root/目录下，文件名不变 scp root@192.168.88.162:/root/test.txt /root/test.txt跨集群之间的数据拷贝distcp
DistCp（distributed copy）是一款被用于大型集群间/集群内的复制工具,该命令的内部原理是MapReduce。
cd /export/serverss/hadoop-2.7.5/ bin/hadoop distcp hdfs://node1:8020/jdk-8u241-linux-x64.tar.gz hdfs://cluster2:8020/Archive档案的使用
HDFS并不擅长存储小文件，因为每个文件最少一个block，每个block的元数据都会在NameNode占用内存，如果存在大量的小文件，它们会吃掉NameNode节点的大量内存。
Hadoop Archives可以有效的处理以上问题，它可以把多个文件归档成为一个文件，归档成一个文件后还可以透明的访问每一个文件。
如何创建ArchiveUsage: hadoop archive -archiveName name -p *
其中-archiveName是指要创建的存档的名称。比如test.har，archive的名字的扩展名应该是*.har。 -p参数指定文件存档文件（src）的相对路径。
例如：如果你只想存档一个目录/input下的所有文件:
hadoop archive -archiveName test.har -p /config /outputdir
这样就会在/outputdir目录下创建一个名为test.har的存档文件。
如何查看Archive首先我们来看下创建好的har文件。使用如下的命令：
hadoop fs -ls /outputdir/test.har
这里可以看到har文件包括：两个索引文件，多个part文件（本例只有一个）以及一个标识成功与否的文件。part文件是多个原文件的集合，根据index文件去找到原文件。
例如上述的/input目录下有很多小的xml文件。进行archive操作之后，这些小文件就归档到test.har里的part-0一个文件里。
hadoop fs -cat /outputdir/test.har/part-0
archive作为文件系统层暴露给外界。所以所有的fs shell命令都能在archive上运行，但是要使用不同的URI。Hadoop Archives的URI是：
har://scheme-hostname:port/archivepath/fileinarchive
scheme-hostname格式为hdfs-域名:端口，如果没有提供scheme-hostname，它会使用默认的文件系统。这种情况下URI是这种形式：
har:///archivepath/fileinarchive
如果用har uri去访问的话，索引、标识等文件就会隐藏起来，只显示创建档案之前的原文件：
查看归档文件中的小文件,使用har uri
hadoop fs -ls har://hdfs-node1:8020/outputdir/test.har
查看归档文件中的小文件,不使用har uri
hadoop fs -ls har:///outputdir/test.har
查看har归档文件中小文件的内容
hadoop fs -cat har:///outputdir/test.har/core-site.xml如何解压Archive
hadoop fs -mkdir /config2 hadoop fs -cp har:///outputdir/test.haruser/**用户名/.Trash/current，每一个被用户通过Shell删除的文件/目录，在系统回收站中都一个周期，也就是当系统回收站中的文件/目录在一段时间之后没有被用户恢复的话，HDFS就会自动的把这个文件/目录彻底删除，之后，用户就永远也找不回这个文件/目录了。如果检查点已经启用，会定期使用时间戳重命名Current目录。.Trash中的文件在用户可配置的时间延迟后被永久删除。回收站中的文件和目录可以简单地通过将它们移动到.Trash目录之外的位置来恢复。
配置HDFS的回收站就像Windows操作系统中的回收站一样。它的目的是防止你无意中删除某些东西。你可以通过设置如下属性来启用此功能(默认是不开启的)：
fs.trash.interval 10080 Number of minutes after which the checkpoint gets deleted. If zero, the trash feature is disabled. fs.trash.checkpoint.interval 0 Number of minutes between trash checkpoints. Should be smaller or equal to fs.trash.interval. If zero, the value is set to the value of fs.trash.interval.
| 属性 | 说明 |
|---|---|
| fs.trash.interval | 分钟数，回收站文件的存活时间, 当超过这个分钟数后文件会被删除。如果为零，回收站功能将被禁用。 |
| fs.trash.checkpoint.interval | 检查点创建的时间间隔(单位为分钟)。其值应该小于或等于fs.trash.interval。如果为零，则将该值设置为fs.trash.interval的值。 |
检查点仅仅是用户回收站下的一个目录，用于存储在创建检查点之前删除的所有文件或目录。如果你想查看回收站目录，可以在/user/${username}/.Trash/{timestamp_of_checkpoint_creation}处看到:
最近删除的文件被移动到回收站Current目录，并且在可配置的时间间隔内，HDFS会为在Current回收站目录下的文件创建检查点/user/${username}/.Trash/<``日期>，并在过期时删除旧的检查点。
恢复回收站数据hadoop fs -mv /user/root/.Trash/200523093000/hadoop-env.sh /config清空回收站
首先想到的是只要删除整个回收站目录，将会清空回收站。诚然，这是一个选择。但是我们有更好的选择。`HDFS提供了一个命令行工具来完成这个工作：
hadoop fs -expunge
该命令使NameNode永久删除回收站中比阈值更早的文件，而不是等待下一个emptier窗口。它立即从文件系统中删除过期的检查点。
注意点回收站功能默认是禁用的。对于生产环境，建议启用回收站功能以避免意外的删除操作。启用回收站提供了从用户操作删除或用户意外删除中恢复数据的机会。但是为fs.trash.interval和fs.trash.checkpoint.interval设置合适的值也是非常重要的，以使垃圾回收以你期望的方式运作。例如，如果你需要经常从HDFS上传和删除文件，则可能需要将fs.trash.interval设置为较小的值，否则检查点将占用太多空间。
当启用垃圾回收并删除一些文件时，HDFS容量不会增加，因为文件并未真正删除。
回收站功能默认只适用于使用Hadoop shell 删除的文件和目录。使用其他接口(例如Web HDF或 `java API)以编程的方式删除的文件或目录不会移动到回收站，即使已启用回收站，除非程序已经实现了对回收站功能的调用。
有时你可能想要在删除文件时临时禁用回收站，也就是删除的文件或目录不用放在回收站而直接删除，在这种情况下，可以使用-skipTrash选项运行rm命令。例如：
hadoop fs -rm -skipTrash /dir1/a.txt参考资料
1. 传智播客博学谷.大数据课程HDFS笔记 2. 翻译经典 HDFS 原理讲解漫画](https://blog.csdn.net/hudiefenmu/article/details/37655491) 3. HDFS的Trash回收站功能](https://www.cnblogs.com/cyfighting/p/4678384.html) 4. 大讲台大数据研习社.Hadoop大数据技术基础及应用[M].北京：机械工业出版社，2018.12 5. 林子雨. 大数据技术原理与应用（第二版）[M].北京：人民邮电出版社，2017.1
