大数据之Hadoop框架之HDFS（二）

HDFS

引言

一、DFS

二、HDFS 1.0

2.1 HDFS 定义

2.2 HDFS 系统架构

2.3 HDFS 相关概念

2.4 机架感知策略

2.5 数据完整性和容错

2.6 HDFS的优缺点

2.7 HDFS 写流程

2.8 HDFS读流程

三、 HDFS 2 ——HDFS 1 的优化

3.1 HDFS HA

3.2 NameNode Federation

3.3 HDFS 快照

3.4 HDFS 缓存

3.5 HDFS ACL(Access Control Lists)

四、HDFS的Shell操作

引言

\quad \quad

随着互联网的发展，日常生活和工作中的数据量越来越大，文件和数据被越来越多地存储到系统管理的磁盘中，单台机器已经不能满足大量的文件存储需求，迫切需要一种允许多机器上的多用户通过网络分享文件和存储空间的文件管理系统，这就是分布式文件（存储）文件系统。

\quad \quad

分布式文件管理系统有很多，如DFS和HDFS，而HDFS适用于一次写入、多次查询的情况。

一、DFS

\quad \quad

分布式文件系统DFS是基于Master/Slave(主/从）模式，在物理结构上是由计算机集群中的多个节点构成的。其结构如下：

主节点（Master Node）

\quad \quad

主节点又被称为名称节点（NameNode），负责文件和目录的创建，删除，重命名等，管理数据和文件块的映射关系。因此客户端要访问存储的文件的时候，必须先访问名称节点，得到其文件所分成的文件块的存储位置信息，直接与其文件块进行信息的读取。

从节点（Slave Node)

\quad \quad

从节点又被成为数据节点（DataNode），负责数据的存储，读取，在存储时由名称节点分配存储位置，之后客户端直接把数据存储相应的位置，其之间的映射关系也就存放在名称节点当中。数据节点也是根据NameNode的命令进行创建和删除。

二、HDFS 1.0

\quad \quad

前面提到的DFS是统称的分布式文件系统，在Hadoop中实现的分布式文件系统被称之为HDFS。

2.1 HDFS 定义

\quad \quad

HDFS 是Hadoop自带的分布式文件系统，即Hadoop Distributed File System。HDFS是一个使用Java语言实现的分布式、可横向扩展的文件系统，是一个集群（多个节点/服务器），用于存储海量数据。

2.2 HDFS 系统架构

\quad \quad

从客户端传入读写请求时，NameNode(HDFS的集群管理节点）首先接受客户端的读写服务请求，并根据它保存的Metadata元数据【包括元数据的镜像文件（fsimage)和操作日志（edit logs)信息】和DataNode（数据存储）通信并进行资源协调，Secondary NameNode进行EditLog和FsImage的合并，同时DataNode之间进行数据复制。

2.3 HDFS 相关概念

1、NameNode（NN）：

\quad \quad

就是Master，它是一个主管、管理者，具有唯一性，也就是说一个集群通常只有一台活动的NameNode。

管理HDFS的文件系统命名空间（命名空间包括目录，文件，块）

存储元数据

保存文件，Block，DataNode之间的映射信息

元信息持久化

在NameNode中存放元信息的文件是 fsimage。在系统运行期间 所有对元信息的操作都保存在内存中并被持久化到另一个文件 edits中。并且edits文件和fsimage文件会被 SecondaryNameNode周期性的合并

处理客户端读写请求

运行NameNode会占用大量内存I/O资源

Hadoop更倾向存储大文件原因

一般来说，一条元信息记录会占用200byte内存空间。假设块大 小为64MB，备份数量是3 ，那么一个1GB大小的文件将占用 163=48个文件块。如果现在有1000个1MB大小的文件，则会占 用10003=3000个文件块（多个文件不能放到一个块中）。我们 可以发现，如果文件越小，存储同等大小文件所需要的元信息就 越多，所以Hadoop更喜欢大文件。

NameNode（NN）——核心结构

\quad \quad

NameNode有两个核心的数据结构FsImage 和 EditLog。

1、 FsImage

元数据镜像文件，用于维护文件系统树以及文件树中的所有文件夹和文件夹下的元数据

2、 Edit Logs

元数据操作日志文件，记录了所有针对文件的创建，删除，重命名等一系列的操作

\quad \quad

每次NameNode启动的时候都会将Fsimage文件读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并

NameNode——单节点故障

\quad \quad

全Hadoop系统只有一个NameNode，导致单节点故障，解决方案如下:

1、将Hadoop元数据写入到本地文件系统的同时再实时同步到一个远程挂载的网络文件系统（NFS)

2、运行一个Secondary NameNode，它的作用是与NameNode进行交互定期通过编辑日志文件合并命名空间镜像。当NameNode发生故障时它会通过自己合并的命名空间镜像副本来恢复。需要注意的是Secondary NameNode保存的状态总是滞后于NameNode，所以这种方式难免会导致丢失部分数据。

2、DataNode（DN）：

\quad \quad

就是Slave。NameNode下达命令，DataNode执行实际的操作

负责存储数据块，负责为系统客户端提供数据块的读写服务

根据NN的指示进行创建、删除和复制等操作

心跳机制，定期向NN报告文件块列表信息

DN中文件的储存方式是按大小分成若干个Block,存储到不同的节点上。Block大小和副本数通过Client端上传文件时设置，文件上传成功后副本数可以变更，BlockSize不可变更。默认情况下每个Block都有3个副本。

3、Secondary NameNode (SNN，第二名称节点)：

\quad \quad

SNN并非NameNode的备份，当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务，而是帮助NameNode合并edit logs,减少NameNode启动时间。

问世原因：

\quad \quad

在HDFS运行时，更新的操作不断地写入Edit Logs当中，其不断的变大，在HDFS重启时，速度会变的很慢，因此产生了第二名称节点。

主要功能/工作：

完成EditLog和FsImage的合并操作，减小Edit Logs的大小，缩短NameNode重启的时间，提升效

作为NameNode的“检查节点”，保存元数据信息，但它并不能取代掉NameNode也不是NameNode的 备份。

NN和SNN工作机制：

（1）每隔一段时间，第二名称节点会和名称节点进行通信，请求停止使用EditLog，创建新的EditLog.new文件，将新的对文件的操作写入new文件中。

（2）将名称节点中的FsImage和EditLog文件拉回到本地中，并加载到内存中。

（3）二者进行合并，生成新的FsImage文件。

（4）将最新的FsImage文件返回给NameNode。

（5）新的FsImage替换旧的，用EditLog.new替换EditLog文件，整个操作执行完成。

再换一个相似的图进行说明：

第一阶段：NameNode启动

：第一次启动NameNode格式化后，创建Fsimage和Edits。如不是第一次启动，加载编辑日志和镜像文件到内存

：客户端对元数据进行增删改的请求

：NameNode记录操作日志，更新滚动日志

：NameNode再内存中对数据进行增删改

第二阶段：Secondary NameNode工作

：每隔一段时间，Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果

：Secondary NameNode请求执行CheckPoint

：NameNode滚动正在写的Edits日志

：将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

：Secondary NameNode加载编辑日志和镜像文件到内存，并合并

：生成新的镜像文件fsimage.chkpoint

：拷贝fsimage.chkpoint到NameNode

：NameNode将fsimage.chkpoint重新命名成fsimage

4、Client：客户端

：文件切分。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行上传

：与NameNode交互，读取或者写入位置信息

：与DataNode交互，读取或写入数据

：Client提供一些命令来管理HDFS，比如NameNode格式化

：Client可以通过一些命令来访问HDFS，比如对HDFS增删改查操作

5、Block: 数据块

数据块——磁盘读/写的基本单位

HDFS也有块的概念，在HDF 1.x 中默认数据块大小为64MB ，在HDF 1.x 中默认数据块大小为128MB

与单一磁盘的文件系统相似，HDFS上的文件也被划分成块大小的多个分块（chunk)，作为独立的存储单元

但与面向单一的文件磁盘系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间（例如一个1MB的文件存储在一个128MB的块中时，文件只会使用1MB的磁盘空间，而不是128MB）。

2.4 机架感知策略

1、—Block副本放置策略

每个文件默认的副本数是三个，即有三个block

第一个副本，在客户端相同的节点（如果客户端是集群外的一台机器，就随机算节 点，但是系统会避免挑选太满或者太忙的节点）

第二个副本，放在不同机架（随机选择）的节点

第三个副本，放在与第二个副本同机架但是不同节点上。

2.5 数据完整性和容错

1、数据完整性

不希望在存储和处理数据时丢失或损坏任何数据 •

HDFS 会对写入的数据计算校验和，并在读取数据时验证校验和

两种检验方法：

1、校验和 CRC32（冗余验证码）

2、数据块检测程序DataBlockScanner

在DataNode节点上开启一个后台线程，来定期验证存储在它上所有块，这个是防止物理介质出现损减情况而 造成的数据损坏。

检测损坏数据的常用方法是在第一次进行系统时计算数据的校验和，在通道传输过程中，如果新生成的校验和 不完全匹配原始的校验和，那么数据就会被认为是被损坏的。

python 计算验证码代码

2、容错——可靠性措施

一个名字节点和多个数据节点

数据复制（冗余机制）

– 存放的位置（机架感知策略）

故障检测

– 数据节点

• 心跳包（检测是否宕机）

• 快报告（安全模式下检测）

• 数据完整性检测（校验和比较）

– 名字节点（日志文件，镜像文件）

空间回收机制 – Trash目录

2.6 HDFS的优缺点

1、HDFS的优点

高容错性

：数据自动保存多个副本。它通过增加副本的形式，提高容错性

：某一个副本丢失以后，它可以自动恢复

适合批处理即就近原则

：移动计算而非非数据，数据位置暴露给计算机框架

：本地化，数据不移动，代码（任务）移动。

适合处理大数据

：数据规模：能够处理数据规模达到GB、TB、甚至PB级别的数据

：文件规模：能够处理百万规模以上的文件数量，数量相当之大

可构建在廉价机器上，通过多副本机制，提高可靠性

2、HDFS的缺点

不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。寻址时间长，适合读取大文件，低延迟与高吞吐率。

不适合小文件存储

占用NameNode大量内存，寻找时间超过读取时间

不支持并发写入，文件随机修改

：一个文件只能有一个写，不允许多个线程同时写

：仅支持数据append（追加），不支持文件的修改

2.7 HDFS 写流程

（1）客户端调用DFS.create( )方法新建文件。

（2）DFS会对NN创建一个RPC（Remote Procedure Call，远程过程调用），在文件系统的命名空间中创建一个新文件，需要注意的是，此时该文件中还没有相应的数据块。

（3）NN通过执行不同的检查来确保这个文件不存在而且客户端有新建文件的权限。如果这些检查都通过了，NN就会为创建新文件写下一条记录；反之，如果文件创建失败，则向客户端抛出一个IOException。

（4）随后DFS向客户端返回一个FSDataOuputStream 对象，这样客户端就可以写入数据了。FSDataOutputStream封装一个DFSOuputStream对象，该对象会处理DN和NN之间的通信。在客户端写入数据的时候， DFSOuputStream将它分成一个个的数据包，并且写入内部队列，被称之为“数据队列’

（5）DataStream处理数据队列，它的任务是选出适合用来存储数据副本的一组DataNode,并据此要求NN分配新的数据块。这一组DN会构成一条管线，DataStream会将数据包流式传输到管线中的第一个DN，然后依次存储并发送给下一个DN。

（6）DFSOuputStream也维护着一个内部数据包队列来等待DN的收到确认回执，称为”确认队列"(ask queue)。收到管道中所有DN确认信息后，该数据包才会从确认队列删除。

（7）客户端完成数据的写入后，会对数据流调用close()方法。

2.8 HDFS读流程

（1）客户端通过FileSystem.open()打开文件，对于HDFS来说，这个对象是DFS的一个实例。

（2）DFS通过使用远程过程调用（RPC）来调用NN，以确定文件起始块的位置。

（3）获得输入流FSDataInputStream后，客户端调用read()函数开始读取数据。输入流根据前面的排序结果，选择距离客户最近的数据节点建立连接并开始读取数据。

（4）数据从该数据节点到客户端；当该数据块读取完毕后，FSDataInputStream关闭和该数据块的连接。

（5）输入流通过getBlockLocations()方法查找下一个数据块（如果客户端中已经包含了该数据块的位置信息，就不要调用该方法）。

（6）找到该数据块的最佳数据节点，读取数据。

（7）当客户端读取完毕数据的时候，调用FSDataInputStream的close()函数，关闭输入流。

三、 HDFS 2 ——HDFS 1 的优化

HDFS 1.0当中存在的问题

在1.0的版本当中，是只有一个单一的名称节点的，其内存中包含了整个HDFS系统中的元数据信息，不可以进行水平扩展。

单个的名称节点的内存空间是有限的，这就限制了系统中的数据块，文件和目录的数目。

整个HDFS的系统吞吐量会受限制于单个名称节点的吞吐量。

隔离性方面，单个名称节点无法提供不同程序之间的隔离性，一个程序的运行很可能会影响其它程序的运行。

HDFS 2.0优化之处主要有以下几点：

NameNode HA

NameNode Federation

HDFS 快照

HDFS 缓存

HDFS ACL

最重要的是前两个

3.1 HDFS HA

\quad \quad

HDFS HA（High Availability）是为了解决单点故障问题而设计。

\quad \quad

对于分布式文件系统HDFS而言，名称节点（NameNode）是系统的核心节点，因为它存储了各类元数据的信息，并负责管理文件系统的命名空间和客户端对文件的访问。但是在HDFS1.0当中，只存在一个单一的名称节点，一旦这个名称节点宕掉那么整个HDFS就会崩掉，(即单点故障问题）虽然存在第二名称节点（SecondNode），但其的主要作用是合并FsImage和EditLog文件，减少名称节点的压力和加快HDFS启动的时间，并不可以作为名称节点的备份节点，因为在其从名称节点拉回FsImage和EditLog进行合并的时候，HDFS新的对文件的操作其并不能进行记录， 故不能作为名称节点的实时备份切换节点。因此，针对这一问题提出了HA（High Availability）架构。

HA 架构如下图所示

\quad \quad

HA集群设置了两个名称节点NN，其中一个处于工作 （Active） 状态，另一个处于随时待命 （Standby） 状态，以至于不会落入单点故障。处于活跃状态的名称节点负责对外处理所有客户端的请求，而处于待命状态的名称节点则作为备用节点，保存了足够多的系统元数据，当名称节点出现故障时提供快速恢复能力。也就是说，在HDFS HA中，处于待命状态的名称节点提供了“热备份”，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点，不会影响到系统的正常对外服务。

1、由于待命的名称节点在活跃的名称节点出现故障的时候是可以实时立即切换对外提供服务的，所以二者的状态信息必须实时的同步，包括写操作的信息，数据存储等等的元数据信息。两个名称节点存在的情况下，数据一致性如何保证？

共享网络文件（文件名->block数据块之间的映射关系）

DN同时向两个NN发送心跳（block->datanode节点之间的映射关系）

需要依赖JounrnalNode守护进程，完成元数据的一致性

2、 JN：JounrnalNode日志节点，共享网络文件系统，一个集群，前提是节点个数为奇数，在学习期间一般使用3个节点来部署JN。作用：数据统一存储。

2、ZK：ZooKeeper，使用Zookeeper来进行心跳监测监控，在Active NameNode失效时自动切换Standby NameNode为Active状态。

3、由于待命名称节点是活跃的“热备份”，因此活跃名称节点的状态信息必须实时同步到待命名称节点。两种名称节点的状态同步，可以借助于一个共享存储系统来实现，比如NFS（Network File System）、QJM（Quorum Journal Manager）或者Zookeeper。活跃名称节点将更新数据写入到共享存储系统，待命名称节点会一直监听该系统，一旦发现有新的写入，就立即从公共存储系统中读取这些数据并加载到自己的内存中，从而保证与活跃名称节点状态完全同步。此外，名称节点中保存了数据库（block）到实际存储位置的映射信息，即每个数据块是由哪个数据节点存储的。当一个数据节点加入HDFS集群时，它会把自己所包含的数据块列表报告给名称节点，此后会通过“心跳”的方式定期执行这种告知操作，以确保名称节点的块映射是最新的。

3.2 NameNode Federation

\quad \quad

HDFS1.0采用单名称节点的设计，还存在可扩展性、性能和隔离性等问题。而HDFS联邦可以很好地解决上述三个方面的问题。

HDFS联邦采用多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联邦（Federation）关系，不需要批次协调。并且向后兼容

HDFS联邦中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报

属于同一个命名空间的块构成一个“块池”

对于联邦中多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问

客户可以访问不同的挂载点来访问不同的子命名空间

把各个命名空间挂载到全局“挂载表”（mount-table）中，实现数据全局共享

同样的命名空间挂载到个人的挂载表中，就称为应用程序课件的命名空间

HDFS Federation设计可以解决单名称节点存在的以下几个问题：

HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目

性能更高效。多个名称节点管理不同的数据。且同时对外提供服务，将为用户提供更好的读写吞吐率。

良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。

\quad \quad

需要注意的是，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点挂掉对业务产生的影响。

3.3 HDFS 快照

HDFS快照是一个只读的基于时间点文件系统拷贝

快照可以是整个文件系统的也可以是一部分

常用来作为数据备份，防止用户错误操作和容灾恢复

Snapshot并不会影响HDFS的正常操作：修改会按照时间的反序记录，这样可以直接读取到最新的数据

快照数据是当前数据减去修改的部分计算出来的

快照会存储在snapshottable的目录下

HDFS快照是对目录进行设定，是某个目录的某一个时刻的镜像

本质：快照只是记录了block的列表和大小，并不涉及到数据的复制

3.4 HDFS 缓存

hdfs缓存是为了减少对数据的重复访问请求，hdfs的缓存通过缓存块实现。

允许用户指定要缓存的hdfs路径

明确的锁定可以阻止频繁使用的数据被从内存中清除

集中化缓存管理对于重复访问的文件很有用

可以换成目录或文件，但目录是非递归的

3.5 HDFS ACL(Access Control Lists)

Hadoop从2.4.0版本开始支持hdfs的ACL

目前HDFS的权限控制与Linux一致，包括用户、用户组、其他用户组三类权限

drwxr-xr-x 2 10011 10011 126 12月 9 20:21 bin

其中

表示bin是一个目录，若是文件则用-表示；

代表owner即用户的权限：读、写、执行

代表用户同组的权限：读、执行，其中-表示没有写的权限

代表不是和用户同组的用户的权限：读、执行

四、HDFS的Shell操作

注：所有操作均在Hadoop根目录下操作

1、启动HDFS集群

执行来到sbin目录下

执行start-dfs.sh

1

可以看到 namenode和 datanode启动的日志信息

通过jps命令查看当前运行的进程

可以看到 NameNode DataNode 以及 SecondaryNameNode 说明启动成功

2、hadoop fs -help: 查看命令参数，得知用法

1

3、hadoop fs -ls: 显示目录信息及其文件

3.1 查看一级目录

1

3.2 逐级查看目录

1

4、-mkdir: hdfs文件系统创建目录

4.1 创建单个目录

1

4.2 一次性创建多个目录

比如创建java1，java2两个目录

4.3 创建多级目录

比如创建a/b/c

5、hadoop fs -touchz: hdfs系统创建文件

5.1 创建单个文件

5.2 一次性创建多个文件

6、hadoop fs -rm: 删除hdfs文件；hadoop fs -rm -r :删除目录

6.1 删除单个文件

6.2 一次性删除多个文件

6.3 删除单个目录

7、hadoop fs -put: 向hdfs上传文件

1、首先在本地编辑一个文件

2、然后将这个文件上传到hdfs中的一个目录上

8、hadoop fs -cat/-tail/-text: 查看文件

9、hadoop fs -du -h：查看hdfs文件的大小

10、查看hdfs文件行数

11、-get: 从HDFS下载文件到本地

12、查看之前的历史命令

参考资料：

1、https://blog.csdn.net/master_hunter/article/details/109986717

------------END-----------