HADOOP中HDFS工作原理

àì夳堔傛蜴生んèń 2022-09-29 05:23 189阅读 0赞

转载：http://www.weixuehao.com/archives/596

http://www.cnblogs.com/iloveyouforever/p/4303903.html

http://www.cnblogs.com/iloveyouforever/p/4304355.html

HDFS（Hadoop Distributed File System ）Hadoop分布式文件系统。是根据google发表的论文翻版的。论文为GFS（Google File System）Google 文件系统（[中文][Link 1]，[英文][Link 2]）。

HDFS有很多特点：

? ? ①?保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。

? ? ②?运行在廉价的机器上。（商用机）

? ? ③?适合大数据的处理。多大？多小？HDFS默认会将文件分割成block，64M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中。如果小文件太多，那内存的负担会很重。

[![26104230-8109ac513de14fe1b115b775581751f2][]][26104230-8109ac513de14fe1b115b775581751f2 1]

如上图所示，HDFS也是按照Master和Slave的结构。分NameNode、SecondaryNameNode、DataNode这几个角色。

NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；

SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。

DataNode：Slave节点，奴隶，干活的。负责存储client发来的数据块block；执行数据块的读写操作。

热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。

冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。

fsimage:元数据镜像文件（文件系统的目录树。）

edits：元数据的操作日志（针对文件系统做的修改操作记录）

namenode内存中存储的是=fsimage+edits。

SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量。所以讲secondarynamenode，单独放置到一台机器上，可以增大冗余，但是有可能会丢失一小时内处理的数据。

--------------------

工作原理

写操作：

[![26162921-2de9d28df9b54fe6a97a6fd88f1cb03f.jpg][]][26162921-2de9d28df9b54fe6a97a6fd88f1cb03f.jpg]

有一个文件FileA，100M大小。Client将FileA写入到HDFS上。

HDFS按默认配置。

HDFS分布在三个机架上Rack1，Rack2，Rack3。

a. Client将FileA按64M分块。分成两块，block1和Block2;

b. Client向nameNode发送写数据请求，如图蓝色虚线①——>。

c. NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②———>。

??? Block1: host2,host1,host3

??? Block2: host7,host8,host4

??? 原理：

??????? NameNode具有RackAware机架感知功能，这个可以配置。

??????? 若client为DataNode节点，那存储block时，规则为：副本1，同client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选。

??????? 若client不为DataNode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1，机架上；副本3，同副本2相同的另一个节点上；其他副本随机挑选。

d. client向DataNode发送block1；发送过程是以流式写入。

? ? 流式写入过程，

? ? ? ? 1>将64M的block1按64k的package划分;

? ? ? ? 2>然后将第一个package发送给host2;

? ? ? ? 3>host2接收完后，将第一个package发送给host1，同时client想host2发送第二个package；

? ? ? ? 4>host1接收完第一个package后，发送给host3，同时接收host2发来的第二个package。

? ? ? ? 5>以此类推，如图红线实线所示，直到将block1发送完毕。

? ? ? ? 6>host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。

? ? ? ? 7>client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线

? ? ? ? 8>发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示。

? ? ? ? 9>发送完block2后，host7,host8,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。

? ? ? ? 10>client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。

分析，通过写过程，我们可以了解到：

? ? ①写1T文件，我们需要3T的存储，3T的网络流量贷款。

? ? ②在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行保存通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去。

? ? ③挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份。

读操作：

?[![26163017-fc613879835c402886b75e0593ca52ed.jpg][]][26163017-fc613879835c402886b75e0593ca52ed.jpg]

读操作就简单一些了，如图所示，client要从datanode上，读取FileA。而FileA由block1和block2组成。?

那么，读操作流程为：

a. client向namenode发送读请求。

b. namenode查看Metadata信息，返回fileA的block的位置。

? ? block1:host2,host1,host3

? ? block2:host7,host8,host4

c. block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取；

上面例子中，client位于机架外，那么如果client位于机架内某个DataNode上，例如,client是host6。那么读取的时候，遵循的规律是：

优选读取本机架上的数据。

--------------------

HDFS中常用到的命令

1、hadoop fs

hadoop fs -ls /
    hadoop fs -lsr
    hadoop fs -mkdir /user/hadoop
    hadoop fs -put a.txt /user/hadoop/
    hadoop fs -get /user/hadoop/a.txt /
    hadoop fs -cp src dst
    hadoop fs -mv src dst
    hadoop fs -cat /user/hadoop/a.txt
    hadoop fs -rm /user/hadoop/a.txt
    hadoop fs -rmr /user/hadoop/a.txt
    hadoop fs -text /user/hadoop/a.txt
    hadoop fs -copyFromLocal localsrc dst 与hadoop fs -put功能类似。
    hadoop fs -moveFromLocal localsrc dst 将本地文件上传到hdfs，同时删除本地文件。

2、hadoop fsadmin?

hadoop dfsadmin -report
    hadoop dfsadmin -safemode enter | leave | get | wait
    hadoop dfsadmin -setBalancerBandwidth 1000

3、hadoop fsck

4、start-balancer.sh

## 注意，看了hdfs的布局，以及作用，这里需要考虑几个问题： ##

1、既然NameNode，存储小文件不太合适，那小文件如何处理？

2、NameNode在内存中存储了meta等信息，那么内存的瓶颈如何解决？

3、Secondary是NameNode的冷备份，那么SecondaryNamenode和Namenode不应该放到一台设备上，因为Namenode宕掉之后，SecondaryNamenode一般也就死了，那讲SecondaryNameNode放到其他机器上，如何配置？

4、NameNode宕机后，如何利用secondaryNameNode上面的备份的数据，恢复Namenode？

5、设备宕机，那么，文件的replication备份数目，就会小于配置值，那么该怎么办？

1、HDFS简介

HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集合的应用带来了很多便利。

Hadoop整合了众多文件系统，在其中有一个综合性的文件系统抽象，它提供了文件系统实现的各类接口，HDFS只是这个抽象文件系统的一个实例。Hadoop提供了一个高层的文件系统抽象类org.apache.hadoop.fs.FileSystem，这个抽象类展示了一个分布式文件系统，并有几个具体的实现，如表1-1所示。

表1-1 Hadoop文件系统

![271630215644342.jpg][]

Hadoop提供了许多文件系统的接口，用户可以使用URI方案选取合适的文件系统实现交互。

2、HDFS基础概念

2.1 数据库（block）

*  HDFS（Hadoop Disturbbuted File System）默认的最基本的存储单位是64M的数据块；
 *  和普通文件系统相同的是，HDFS的文件是被分成64M的数据块存储的；
 *  不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间；

2.2 NameNode和DataNode

HDFS体系结构中有两类节点，一类是NameNode，又叫“元数据节点”；另一类是DataNode，又叫“数据节点”。这两类节点分别是承担Master和Worker具体任务的执行节点。

1）元数据节点用来管理文件系统的命名空间

*  其将所有的文件和文件夹的元数据保存在一个文件系统树中；
 *  这些信息也会在硬盘上保存成以下文件：命名空间镜像（namespace image）及修改日志（edit log）；
 *  其还保存了一个文件包括哪些数据块，分布在哪些数据节点上，然而这些信息并不存储在硬盘上，而是在系统启动的时候从数据节点收集而成的；

2）数据节点是文件系统中真正存储数据的地方

*  客户端（client）或者元数据信息（namenode）可以向数据节点请求写入或者读出数据块；
 *  其周期性的向元数据节点汇报其存储的数据块信息；

3）从元数据节点（secondary namenode）

*  从元数据节点并不是元数据节点出现问题时候的备用节点，它和元数据节点负责不同的事情；
 *  其主要功能就是周期性将元数据节点的命名空间镜像文件盒修改日志合并，以防日志文件过大（这点在下面会详细叙述）；
 *  合并过后的命名空间镜像文件也在元数据节点保存了一份，以防元数据节点失败的时候，可以恢复；

2.3 元数据节点目录结构

![271644020802602.jpg][]

VERSION文件是java properties文件，保存了HDFS的版本号。

*  layoutVersion是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号；
 *  namespaceID是文件系统的唯一标识符，是在文件系统初次格式化时生成的；
 *  Ctime此处为0；
 *  storageType表示此文件夹中保存的是元数据节点的数据结构；

![271646487528649.jpg][]

2.4 数据节点的目录结构

![271647406276968.jpg][]

*  blk\_<id>保存的是HDFS的数据块，其中保存了具体的二进制数据；
 *  blk\_<id>.meta保存的是数据块的熟悉信息：版本信息、类型信息、checksum；
 *  当一个目录中的数据块到达一定数量的时候，则创建子文件夹来保存数据块及数据块属性信息；

2.5 文件系统命名空间映像文件及修改日志

*  当文件系统客户端（client）进行写操作时，首先把它记录在修改日志中（edit log）；
 *  元数据节点在内存中保存了文件系统的元数据信息，在记录了修改日志后，元数据节点在修改内存中的数据结构；
 *  每次写操作成功之前，修改日志都会同步（sync）到文件系统；
 *  fsimage文件，也即命名空间映像文件，是内存中的元数据在硬盘上的checkpoint，它是一种序列化的格式，并不能在硬盘上直接修改；
 *  同数据的机制相似，当元数据节点失败时，则最新checkpoint的元数据信息从fsimage加载到内存中，然后逐一重新执行修改日志中的操作；
 *  从元数据节点就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的；
 *  checkpoint的过程如下：
    
     *  从元数据节点通知元数据节点生成新的日志文件，以后的日志都写到新的日志文件中；
     *  从元数据节点用http get从元数据节点获取fsimage文件及旧的日志文件；
     *  从元数据节点将fsimage文件加载到内存中，并执行日志文件中的操作，然后生成新的fsimage文件；
     *  从元数据节点将新的fsimage文件用http post传回元数据节点；
     *  元数据节点可以将旧的fsimage文件及旧的日志文件，换为新的fsimage文件盒新的日志文件（第一步生成的），然后更新fsimage文件，写入此次checkpoint的时间；
     *  这样元数据节点中的fsimage文件保存了最新的checkpoint的元数据信息，日志文件也重新开始，不会变的很大了；

![271659040649774.jpg][]

3、HDFS体系结构

HDFS是一个主/从（Master/Slave）体系结构，从最终用户的角度来看，它就像传统的文件系统一样，可以通过目录路径对文件执行CRUD（Create、Read、Update、Delete）操作。但由于分布式存储的性质，HDFS集群拥有一个NameNode和一些DataNode。NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端通过同NameNode和DataNodes的交互访问文件系统。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。

![271702502364876.jpg][]

图3-1 Hadoop的体系结构

1）NameNode、DataNode和Client

*  NameNode可以看作是分布式文件系统中的管理者，主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Metadata存储在内存中，这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等；
 *  DataNode是文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Metadata，同时周期性的将所有存在的Block的信息发送给NameNode；
 *  Client就是需要获取分布式文件系统文件的应用程序；

2）文件写入

*  Client向NameNode发起文件写入的请求；
 *  NameNode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息；
 *  Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中；

3）文件读取

*  Client向NameNode发起文件读取的请求；
 *  NameNode返回文件存储的DataNode的信息；
 *  Client读取文件信息；

HDFS典型的部署是在一个专门的机器上运行的NameNode，集群中的其他机器各运行一个DataNode；也可以在运行NameNode的机器上同时运行DataNode，或者一台机器上运行多个DataNode。一个集群只有一个NameNode的设计大大简化了系统架构。

4、HDFS的优缺点

4.1 HDFS的优点

1）处理超大文件

这里的超大文件通常是指百MB、甚至数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

2）流式的访问数据

HDFS的设计建立在更多地响应“一次写入、多次读写”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

3）运行于廉价的商用机器集群上

Hadoop设计对硬件需求比较低，只须要运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机器也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性、安全性及高可用性。

4.2 Hadoop的缺点

1）不适合低延迟数据访问

如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。

改进策略：对于那些有低延迟要求的应用程序，HBase是一个更好的选择。通过上层数据管理项目来尽可能地补充这个不足。在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延迟。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延迟了，HDFS不是万能的。

2）无法高效存储大量小文件

因为NameNode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由NameNode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300M内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没办法实现了。还有一个问题就是，因为Map task的数据是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减少很多。

改进策略：要想让HDFS能处理好小文件，有不少方法。

*  利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件的内容，那就必须得知道与归档文件的映射关系；
 *  横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。
 *  多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊；
 *  附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成；

3）不支持多用户写入及任意修改文件

在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一个文件的写操作，以及在文件任意位置进行修改。

5、HDFS常用操作

先说一下“hadoop fs”和“hadoop dfs”的区别，看两本Hadoop书上各有用到，但效果一样，求证与网络发现下面一解释比较中肯。  
　　粗略的讲，fs是个比较抽象的层面，在分布式环境中，fs就是dfs，但在本地环境中，fs是local file system，这个时候dfs就不能用。

5.1 文件操作

1）列出HDFS文件

![271750077526567.jpg][]

2）列出HDFS目录下某个文档中的文件

![271751552369828.jpg][]

3）上传文件到HDFS

![271752538463958.jpg][]

4）将HDFS中文件复制到本地系统中

![271753466894348.jpg][]

5）删除HDFS下的文档

![271754328613440.jpg][]

6）查看HDFS下某个文件

![271755541588937.jpg][]

“hadoop fs”的命令远远不止这些，本小节的命令可以再HDFS上完成大多数常规操作。对于其他操作，可以通过“-help commandName”命令所列出的清单来进一步学习与探索。

5.2 管理与更新

1）报告HDFS的基本统计情况

此处为你展示通过“-report”命令如何查看HDFS的基本统计信息：

![271838517834892.jpg][]

执行结果如下所示。

![271840063461280.jpg][]

2）退出安全模式

NameNode在启动时会自动进入安全模式。安全模式是NameNode的一种状态，在这个阶段，文件系统不允许有任何修改。安全模式的目的是在系统启动时检查各个DataNode上数据块的有效性，同时根据策略对数据块进行必要的复制或删除，当数据块最小百分比数满足的最小副本数条件时，会自动退出安全模式。

系统显示“Name node is in safe mode”，说明系统正处于安全模式，这时只需要等待17秒即可，也可以通过下面的命令退出安全模式。

![271845089556697.jpg][]

成功退出安全模式的结果如下所示。

![271848008305355.jpg][]

3）进入安全模式

在必要的情况下，可以通过以下命令把HDFS置于安全模式。

![271848441116165.jpg][]

执行结果如下所示。

![271849035807051.jpg][]

4）添加节点

可扩展性是HDFS的一个重要特性，向HDFS集群中添加节点是很容易实现的。添加一个新的DataNode节点，首先在新加节点上安装好Hadoop，要和NameNode使用相同的配置（可以直接从NameNode复制），修改"/usr/hadoop/conf/master"文件，加入NameNode主机名。然后在NameNode节点上修改"/usr/hadoop/conf/slaves"文件，加入新节点主机名，再建立到新加点无密码的SSH连接，运行启动命令：

![271851150969639.jpg][]

5）负载均衡

HDFS的数据在各个DataNode中的分布肯定很不均匀，尤其是DataNode节点出现故障或者新增DataNode节点时。新增数据块NameNode对DataNode节点的选择策略也有可能导致数据块分布的不均匀。用户可以使用命令重新平衡DataNode的数据块的分布：

![271853033777258.jpg][]

执行命令前，DataNode节点上数据分布情况，如下所示。

![271855000966901.jpg][]

负载均衡完毕后，DataNode节点上数据的分布情况，如下所示。

![271854251745669.jpg][]

执行负载均衡命令，如下所示。

![271856080025221.jpg][]

6、HDFS API详解

Hadoop中关于文件操作类疾病上全部在“org.apache.hadoop.fs”包中，这些API能够支持的操作包含：打开文件、读写文件、删除文件等。

Hadoop类库中最终面向用户提供的接口类是FileSystem，该类是个抽象类，只能通过该类的get方法得当具体的类。get方法存在几个重载版本，常用的是这个：

![271953138619401.jpg][]

该类几乎封装了所有的文件操作，例如mkdir、delete等。综上基本上可以得出操作文件的程序库框架：

![271954230495465.jpg][]

6.1 上传本地文件

通过“FileSystem.copyFromLocalFile(Path src, Path dst)”可将本地文件上传到HDFS的指定位置上，其中src和dst均为文件的完成路径。具体事例如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileStatus;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class CopyFile {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
           
            //本地文件
    
            Path src =new Path("D:\\HebutWinOS");
    
            //HDFS为止
    
            Path dst =new Path("/");
    
    
            hdfs.copyFromLocalFile(src, dst);
    
            System.out.println("Upload to"+conf.get("fs.default.name"));
    
           
            FileStatus files[]=hdfs.listStatus(dst);
    
            for(FileStatus file:files){
    
                System.out.println(file.getPath());
    
            }
    
        }
    
    }

![复制代码][copycode.gif]

运行结果可以通过控制台、项目浏览器和SecureCRT查看，如下图所示。

1）控制台结果

![271959402058371.jpg][]

2）项目浏览器

![272000049246853.jpg][]

3）SecureCRT结果

![272000369866857.jpg][]

6.2 创建HDFS文件

通过“FileSystem.create(Path f)"可在HDFS上创建文件，其中f为文件的完整路径。具体实现如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
     
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FSDataOutputStream;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    
    public class CreateFile {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            byte[] buff="hello hadoop world!\n".getBytes();
    
            Path dfs=new Path("/test");
    
            FSDataOutputStream outputStream=hdfs.create(dfs);
    
            outputStream.write(buff,0,buff.length);
        }
    
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）项目浏览器

![272002131118057.jpg][]

2）SecureCRT结果

![272002393778267.jpg][]

6.3 创建HDFS目录

通过”FileSystem.mkdirs(Path f)“可在HDFS上创建文件夹，其中f为文件夹的完整路径。具体实现如下所示。

![复制代码][copycode.gif]

package com.hebut.dir;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class CreateDir {
    
        public static void main(String[] args) throws Exception{
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path dfs=new Path("/TestDir");
    
            hdfs.mkdirs(dfs);
        }
    
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）项目浏览器

![272003597839435.jpg][]

2）SecureCRT结果

![272004267211274.jpg][]

6.4 重命名HDFS文件

通过”FileSystem.rename(Path src, Path dst)“可为指定的HDFS文件重命名，其中src和dst均为文件的完整路径，具体实现如下所示。

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class Rename{
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path frpaht=new Path("/test");    //旧的文件名
    
            Path topath=new Path("/test1");    //新的文件名
    
            boolean isRename=hdfs.rename(frpaht, topath);
    
            String result=isRename?"成功":"失败";
    
            System.out.println("文件重命名结果为："+result);
        }
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）项目浏览器

![272005577217606.jpg][]

2）SecureCRT结果

![272006223613644.jpg][]

6.5 删除HDFS上的文件

通过”FileSystem.delete(Path f, Boolean recursive)“可删除指定的HDFS文件，其中f为需要删除的完整路径，recuresive用来确定是否进行递归删除。具体实现如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class DeleteFile {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path delef=new Path("/test1");
    
            boolean isDeleted=hdfs.delete(delef,false);
    
            //递归删除
    
            //boolean isDeleted=hdfs.delete(delef,true);
    
            System.out.println("Delete?"+isDeleted);
        }
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）控制台结果

![272011545497426.jpg][]

2）项目浏览器

![272012253771375.jpg][]

6.6 删除HDFS上的目录

同删除文件代码一样，只是缓存删除目录路径即可，如果目录下有文件，要进行递归删除。

6.7 查看某个HDFS文件是否存在

通过”FileSystem.exists(Path f)“可查看指定HDFS文件是否存在，其中f为文件的完整路径。具体事项如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class CheckFile {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path findf=new Path("/test1");
    
            boolean isExists=hdfs.exists(findf);
    
            System.out.println("Exist?"+isExists);
    
        }
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）控制台结果

![272014286433883.jpg][]

2）项目浏览器

![272014467529283.jpg][]

6.8 查看HDFS文件的最后修改时间

通过”FileSystem.getModificationTime()“可查看指定HDFS文件的修改时间。具体实现如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileStatus;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class GetLTime {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path fpath =new Path("/user/hadoop/test/file1.txt");
    
            FileStatus fileStatus=hdfs.getFileStatus(fpath);
    
            long modiTime=fileStatus.getModificationTime();
    
            System.out.println("file1.txt的修改时间是"+modiTime);
        }
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）控制台结果

![272016302366234.jpg][]

6.9 读取HDFS某个目录下的所有文件

通过”FileStatus.getPath()“可以查看指定HDFS中某个目录下所有文件。具体实现如下所示。

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileStatus;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class ListAllFile {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path listf =new Path("/user/hadoop/test");      
    
            FileStatus stats[]=hdfs.listStatus(listf);
    
            for(int i = 0; i < stats.length; ++i)
    　　　　 {
    　　　　　　 System.out.println(stats[i].getPath().toString());
    　　　　 }
            hdfs.close();
        }
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）控制台结果

![272018280337447.jpg][]

2）项目浏览器

![272019175189396.jpg][]

6.10 查找某个文件在HDFS集群的位置

通过”FileSystem.getFileBlockLocation(FileStatus file, long start, long len)“可查找指定文件在HDFS集群上的位置，其中file为文件的完整路径，start和len来标识查找文件的路径。具体实现如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.BlockLocation;
    
    import org.apache.hadoop.fs.FileStatus;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.fs.Path;
    
    public class FileLoc {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem hdfs=FileSystem.get(conf);
    
            Path fpath=new Path("/user/hadoop/cygwin");      
    
            FileStatus filestatus = hdfs.getFileStatus(fpath);
    
            BlockLocation[] blkLocations = hdfs.getFileBlockLocations(filestatus, 0, filestatus.getLen());
    
            int blockLen = blkLocations.length;
    
            for(int i=0;i<blockLen;i++){
    
                String[] hosts = blkLocations[i].getHosts();
    
                System.out.println("block_"+i+"_location:"+hosts[0]);
    
            }
        }
    
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）控制台结果

![272021166894623.jpg][]

6.11 获取HDFS集群上所有节点名称信息

通过”DatanodeInfo.getHostName()“可获取HDFS集群上的所有节点名称。具体实现如下：

![复制代码][copycode.gif]

package com.hebut.file;
    
    import org.apache.hadoop.conf.Configuration;
    
    import org.apache.hadoop.fs.FileSystem;
    
    import org.apache.hadoop.hdfs.DistributedFileSystem;
    
    import org.apache.hadoop.hdfs.protocol.DatanodeInfo;
    
    public class GetList {
    
        public static void main(String[] args) throws Exception {
    
            Configuration conf=new Configuration();
    
            FileSystem fs=FileSystem.get(conf);
    
            DistributedFileSystem hdfs = (DistributedFileSystem)fs;
    
            DatanodeInfo[] dataNodeStats = hdfs.getDataNodeStats();
    
            for(int i=0;i<dataNodeStats.length;i++){
    
                System.out.println("DataNode_"+i+"_Name:"+dataNodeStats[i].getHostName());
            }
        }
    }

![复制代码][copycode.gif]

运行结果，如下图所示。

1）控制台结果

![272023235334570.jpg][]

7、HDFS的读写数据流

7.1 文件的读取剖析

![272024018936685.jpg][]

文件读取的过程如下：

1）解释一

*  客户端（client）用FileSystem的open()函数打开文件；
 *  DistributedFileSystem用RPC调用元数据节点，得到文件的数据块信息；
 *  对于每一个数据块，元数据节点返回保存保存数据块的数据节点的地址；
 *  DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据；
 *  客户端调用stream的read()函数开始读取数据；
 *  DFSInputStream连接保存此文件第一个数据块的最近的数据节点；
 *  Data从数据节点读到客户端（client）；
 *  当此数据块读取完毕后，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点；
 *  当客户端读取完毕数据的时候，调用FSDataInputStream的close函数；
 *  在读取数据的过程中，如果客户端在与数据点通信出现错误，则尝试连接包含此数据块的下一个数据节点；
 *  失败的数据节点将被记录，以后不再连接；

2）解释二

*  使用HDFS提供的客户端开发库，向远程的NameNode发起RPC请求；
 *  NameNode会视情况返回文件的部分或全部的block列表，对于每个block，Namenode都会返回有该block拷贝的datanode地址；
 *  客户端开发库会选取离客户端最接近的datanode来读取block；
 *  读取完当前block数据后，关闭与当前datanode连接，并为读取下一个block寻找最佳的datanode；
 *  当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向NameNode获取下一批的block列表；
 *  读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读；

7.2 文件的写入剖析

![272036051893648.jpg][]

写入文件的过程比读取较为复杂：

1）解释一

*  客户端调用create()来创建文件
 *  DistributedFileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件。
 *  元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。
 *  DistributedFileSystem返回DFSOutputStream，客户端用于写数据。
 *  客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。
 *  Data queue由Data Streamer读取，并通知 元数据节点分配 数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。
 *  Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
 *  DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。
 *  如果数据节点在写入的过程中失败：
    
     *  关闭pipeline，将ack queue中的数据块放入data queue的开始。
     *  当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。
     *  失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。
     *  元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。
 *  当客户端结束写入数据，则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。 最后通知元数据节点写入完毕。

2）解释二

*  使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求；
 *  Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；
 *  当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表，列表的大小根据在Namenode中对replication的设置而定。
 *  开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。
 *  最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。
 *  如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas设定的数量。

[Link 1]: http://www.open-open.com/lib/view/open1328763454608.html
[Link 2]: http://static.googleusercontent.com/media/research.google.com/zh-CN//archive/gfs-sosp2003.pdf
[26104230-8109ac513de14fe1b115b775581751f2]: http://www.weixuehao.com/wp-content/uploads/2014/05/26104230-8109ac513de14fe1b115b775581751f2.jpg
[26104230-8109ac513de14fe1b115b775581751f2 1]: http://www.weixuehao.com/archives/596/26104230-8109ac513de14fe1b115b775581751f2
[26162921-2de9d28df9b54fe6a97a6fd88f1cb03f.jpg]: /images/20220708/3982b708db1545ffbf4225467b212371.png
[26163017-fc613879835c402886b75e0593ca52ed.jpg]: /images/20220708/90f9e806a41b4306bfcff8786a94cb80.png
[271630215644342.jpg]: /images/20220708/811dd09470cc48d2b5b1683c35cfcd55.png
[271644020802602.jpg]: /images/20220708/53dafc903ba64c82840e0f896ff74dae.png
[271646487528649.jpg]: /images/20220708/69cc1159cd7041c890692fef7c157683.png
[271647406276968.jpg]: /images/20220708/26042f7647ef4d7caf879fa87387d741.png
[271659040649774.jpg]: /images/20220708/1b479df26b4240dcb3089b48644ede14.png
[271702502364876.jpg]: /images/20220708/a838bf77e0d6470ca29cbb82c6d64dfc.png
[271750077526567.jpg]: /images/20220708/414a49e9659b4991b9ba35c76aa7ef99.png
[271751552369828.jpg]: /images/20220708/55afb14ca3b5474a9b81b12925c63471.png
[271752538463958.jpg]: /images/20220708/282be5b4622647bf847a0700994aa58c.png
[271753466894348.jpg]: /images/20220708/27deb6c11dbc4ebca5f37dad551abf3a.png
[271754328613440.jpg]: /images/20220708/7f1c774e793e4fe0a6ebb5d559e7b28c.png
[271755541588937.jpg]: /images/20220708/245a7b2e185c47099e8a214a9e87d4c8.png
[271838517834892.jpg]: /images/20220708/1870996cc3794d1085f3d2a089e53d65.png
[271840063461280.jpg]: /images/20220708/4a90acd89d484e2a9f8ac56657d9bb3a.png
[271845089556697.jpg]: /images/20220708/1e0d8e97393e48d09dccc72bc38fcdca.png
[271848008305355.jpg]: /images/20220708/e5cf9f3a6f1143a99bfabd713646cb39.png
[271848441116165.jpg]: /images/20220708/658fafa575b741f4b1b4f31b63d25acf.png
[271849035807051.jpg]: /images/20220708/277eadca18c0482ba037ac42728bd738.png
[271851150969639.jpg]: /images/20220708/9b1a4100f7bc42a598d0074486e64ce0.png
[271853033777258.jpg]: /images/20220708/2acf9749d2594153ba51865099519169.png
[271855000966901.jpg]: /images/20220708/77ac907cc4dd44dca3e6076b253b0a31.png
[271854251745669.jpg]: /images/20220708/3b22f934df7a4eaf887a57ab4e7e1be0.png
[271856080025221.jpg]: /images/20220708/5ecfcb3484814541874af4e4b0403d02.png
[271953138619401.jpg]: /images/20220708/e68c9c73490847889d9dae6a6323fec4.png
[271954230495465.jpg]: /images/20220708/7d9ba7336c0a486992b9d05a97e8d806.png
[copycode.gif]: /images/20220708/68a7ba69546a4d308653ba04e18299ed.png
[271959402058371.jpg]: /images/20220708/d16a6d9f481443bb813abb9898bf1288.png
[272000049246853.jpg]: /images/20220708/46e441ec40274001b545047998a123b5.png
[272000369866857.jpg]: /images/20220708/a64b1f3f51b44056b0203f6c70663f0b.png
[272002131118057.jpg]: /images/20220708/75eb0c45bf1d4c3ba05614bc8db95bd2.png
[272002393778267.jpg]: /images/20220708/e9bbc3c1bec843f79127cb2343e58735.png
[272003597839435.jpg]: /images/20220708/a080406fc3ef495abb2b7efc549b84d6.png
[272004267211274.jpg]: /images/20220708/1c3f8e2f6e2042ae83e76a57a80c4696.png
[272005577217606.jpg]: /images/20220708/1b1631a7f4484ad698d071d9010c66e6.png
[272006223613644.jpg]: /images/20220708/3f8e9fd51c384ff3afcd932dba0af119.png
[272011545497426.jpg]: /images/20220708/0f55aa0c12d9483ca8b031ca765c9569.png
[272012253771375.jpg]: /images/20220708/0949b916860c41e48a5bfc605ce4df6a.png
[272014286433883.jpg]: /images/20220708/ba2d4435869c47bea816dcbb842227f7.png
[272014467529283.jpg]: /images/20220708/619489b661674227a1da86d32347bc70.png
[272016302366234.jpg]: /images/20220708/66e8afe704214d47b85ea52c139e765d.png
[272018280337447.jpg]: /images/20220708/ead501c91f4140d1a1c00f228bc4f869.png
[272019175189396.jpg]: /images/20220708/0b893b9120cc4ef1b7c068aa91447e2b.png
[272021166894623.jpg]: /images/20220708/212ba68b199246f0b4e6b655871b88d0.png
[272023235334570.jpg]: /images/20220708/58b6e4dea9884d74960bbd48fb46d0dd.png
[272024018936685.jpg]: /images/20220708/6a84a1b19b944d3b8032519ef98058af.png
[272036051893648.jpg]: /images/20220708/b3356fcc9fd44c81945ba7c8ae942656.png