您的位置: 首页  >  文章  >  **Hadoop纵览之(二)分布式文件系统HDFS**

**Hadoop纵览之(二)分布式文件系统HDFS**

分类: 文章 • 2022-10-03 14:37:22

1.官网介绍

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.

Hadoop分布式文件系统(HDFS)是一个分布式文件系统，设计用于在商品硬件上运行。它与现有的分布式文件系统有许多相似之处。然而，与其他分布式文件系统的区别是显著的。HDFS是高度容错的，并且被设计为部署在低成本硬件上。HDFS提供对应用程序数据的高吞吐量访问，适用于具有大数据集的应用程序。HDFS放松了一些POSIX需求，允许对文件系统数据进行流访问。HDFS最初是作为Apache Nutch web搜索引擎项目的基础架构构建的。HDFS是Apache Hadoop核心项目的一部分。

2.HDFS设计目标

1.硬件错误：数量众多的廉价机器使得硬件错误成为常态。
2.数据流访问：应用以流的方式访问数据；设计用于数据的批量处理，而不是低延时的实时交互处理。放弃全面支持POSIX。
3.大数据集：典型的HDFS上的一个文件大小是G或T数量级的，支持一个云中文件数量达到千万数量级。
4.简单的相关模型：假定文件一次写入多次读取。未来可能支持Appending-write的模型。
5.移动计算比移动数据便宜：一个应用请求的计算，离它操作的数据越近就越高效。
6.多种软硬件平台中的可移植性

3.HDFS的特点

优点：
（一）高可靠性：Hadoop按位存储和处理数据的能力值得人们信赖;
（二）高扩展性：Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中。
（三）高效性：Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。
（四）高容错性：Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。
缺点：
（一）不适合低延迟数据访问。
（二）无法高效存储大量小文件。
（三）不支持多用户写入及任意修改文件

4.HDFS的中概念

4.1 HDFS是什么？

首先，它是一个文件系统，用于存储文件，通过统一的命名空间——目录树来定位文件
其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色(namenode 、datanode 、secondarynamenode);
重要特性如下：
(1) HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M

(2) HDFS文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

(3) 目录结构及文件分块位置信息(元数据)的管理由namenode节点承担----namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的block块信息（block的id，及所在的datanode服务器）

(4) 文件的各个block的存储管理由datanode节点承担 ----datanode是HDFS集群从节点，每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication）

(5) HDFS是设计成适应一次写入，多次读出的场景，且不支持文件的修改

(注：适合用来做数据分析，并不适合用来做网盘应用，因为，不便修改，延迟大，网络开销大，成本太高)

4.2 HDFS中的block、packet、chunk

Block：文件上传之前需要分块，这个块就是block，一般为128MB，块太小：寻址时间占比太高。块太大：Map任务数太少，任务执行速度变慢，是第一大单位。
Packet：packet是第二大的单位，它是client端向DataNode，或DataNode的Pipline之间传数据的基本单位，默认64KB。
Chunk：chunk是最小的单位，它是client向DataNode，或DataNode的Pipline之间进行数据校验的基本单位，默认512Byte，因为用做校验，故每个chunk需要带有4Byte的校验位。所以实际每个chunk写入packet的大小为516Byte。由此可以看出真实数据与校验值数据的比值为128：1

5.HDFS的shell命令(常用)

hdfs dfs -ls -R /
hdfs dfs -mkdir -p /test
hdfs dfs -touchz /test/123.txt
hdfs dfs -appendToFile /home/puzzle /test/123.txt ???
hdfs dfs -put /home/hello.java /test
hdfs dfs -copyFromLocal /home/hello.class /test
hdfs dfs -moveFromLocal /home/hello.java /test/hello
hdfs dfs -cat /test/hello
hdfs dfs -tail /test/hello
hdfs dfs -text /test/hello
hdfs dfs -cp /test/hello /test/01
hdfs dfs -mv /test/hello.java /test/01
hdfs dfs -getmerge
hdfs dfs -get /test /home/test1
hdfs dfs -rmdir /test
hdfs dfs -rmr /test/01/tmp

6.HDFS的工作机制

6.1 概述

  1. HDFS集群分为两大角色：NameNode、DataNode
  2. NameNode负责管理整个文件系统的元数据
  3. DataNode 负责管理用户的文件数据块
  4. 文件会按照固定的大小（blocksize）切成若干块后分布式存储在若干台datanode上
  5. 每一个文件块可以有多个副本，并存放在不同的datanode上
  6. Datanode会定期向Namenode汇报自身所保存的文件block信息，而namenode则会负责保持文件的副本数量
  7. HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向namenode申请来进行

6.2 HDFS写数据流程

6.2.1 概述

客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后，客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本

6.2.2 详细步骤图

**Hadoop纵览之(二)分布式文件系统HDFS**

1、客户端和namenode通信请求上传文件，namenode检查目标文件是否已存在，父目录是否存在
2、namenode返回是否可以上传
3、client会先对文件进行切分，比如一个blok块128m，文件有300m就会被切分成3个块，一个128M、一个128M、一个44M，并请求第一个 block该传输到哪些datanode服务器上
4、namenode返回datanode的服务器
5、client请求一台datanode上传数据（本质上是一个RPC调用，建立pipeline），第一个datanode收到请求会继续调用第二个datanode，然后第二个调用第三个datanode，将整个pipeline建立完成，逐级返回客户端
6、client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（一个packet为64kb），当然在写入的时候datanode会进行数据校验，它并不是通过一个packet进行一次校验而是以chunk为单位进行校验（512byte），第一台datanode收到一个packet就会传给第二台，第二台传给第三台；第一台每传一个packet会放入一个应答队列等待应答
7、当一个block传输完成之后，client再次请求namenode上传第二个block的服务器

6.3 HDFS读数据流程

6.3.1 概述

客户端将要读取的文件路径发送给namenode，namenode获取文件的元信息（主要是block的存放位置信息）返回给客户端，客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件

6.3.2 详细步骤图

**Hadoop纵览之(二)分布式文件系统HDFS**
1、和namenode通信查询元数据，找到文件块所在的datanode服务器
2、挑选一台datanode（就近原则，然后随机）服务器，请求建立socket流
3、datanode开始发送数据（从磁盘里面读取数据放入流，以packet为单位来做校验）
4、客户端以packet为单位接收，先在本地缓存，然后写入目标文件,后面的block块就相当于是append到前面的block块最后合成最终需要的文件。

6.4 NameNode工作机制

6.4.1 NameNode职责

1.负责客户端请求的响应
2.元数据的管理（查询，修改）
3.管理datanode的状态

6.4.2 元数据管理

Namenode对数据的管理采用了三种存储形式：

1.内存元数据(NameSystem)
2.磁盘元数据镜像文件
3.数据操作日志文件（可通过日志运算出元数据）

元数据存储机制

A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中

元数据的checkpoint

每隔一段时间，会由secondarynamnode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）详细流程如下:

**Hadoop纵览之(二)分布式文件系统HDFS**

1.SecondaryNameNode通知NameNode准备提交edits文件，此时主节点将新的写操作数据记录到一个新的文件edits.new中。
2.SecondaryNameNode通过HTTP GET方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）。
3.SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt。
4.SecondaryNameNode用HTTP POST方式发送fsimage.ckpt至NameNode。
5.NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束

checkpoint操作的触发条件配置参数
dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率，60秒
dfs.namenode.checkpoint.dir=file://KaTeX parse error: Expected 'EOF', got '#' at position 36: …/namesecondary #̲以上两个参数做checkpoi…{dfs.namenode.checkpoint.dir}

dfs.namenode.checkpoint.max-retries=3 #最大重试次数
dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的时间间隔3600秒
dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录

6.4.3 NameNode的启动过程

1、在hdfs-site.xml中设置文件存储路径并指向data路径，在hadoop安装路径中新建data目录。
2、进行namenode格式化，在data目录中生成各类目录，并生成fsimage文件。
3、第一次启动namenode硬盘中将fsimage加载到内存中，hdfs文件如果修改，将写edits文件作为log，并将最新修改内容加载到内容中。同时secondarynamenode，将不断的从namenode中下载并合并相应的fsimage+edits，并上传到namenode，namenode修改原fsimage，替换为新的fsimage。
4、datanode向namenode进行注册。每隔3秒，datanode向namenode注册心跳的间隔时间。
5、每小时datanode默认向namenode发送block report。汇报datanode的数据节点情况。
6、第二次启动，namenode硬盘中将新的fsimage加载到内存中，并进行改写edits，其他的与第一次启动相似

6.5 DataNode的工作机制

6.5.1 概述

Datanode工作职责

存储管理用户的文件块数据
定期向namenode汇报自身所持有的block信息（通过心跳信息上报）
（这点很重要，因为，当集群中发生某些block副本失效时，集群如何恢复block初始副本数量的问题）

Datanode掉线判断时限参数

   <property>
    	<name>dfs.blockreport.intervalMsec</name>
    	<value>3600000</value>
    	<description>Determines block reporting interval in milliseconds.</description>
    </property>

datanode进程死亡或者网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判定为死亡，要经过一段时间，这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout，则超时时长的计算公式为：
timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。
而默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。
需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。所以，举个例子，如果heartbeat.recheck.interval设置为5000（毫秒），dfs.heartbeat.interval设置为3（秒，默认），则总的超时时间为40秒。
6.6 Secondary Namenode工作机制
SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。两个过程同时进行，称为checkpoint（检查点）
镜像备份的作用：备份fsimage(fsimage是元数据发送检查点时写入文件)；
日志与镜像的定期合并的作用：将Namenode中edits日志和fsimage合并,防止如果Namenode节点故障，namenode下次启动的时候，会把fsimage加载到内存中，应用edits log,edits log往往很大，导致操作往往很耗时。（这也是namenode容错的一套机制）

SNN可以当做NameNode的冷备份，可以恢复NameNode，但是不是完全恢复，最坏的情况下是少FS一个小时的记录。
SNN在自己的目录下，存放着最新进行检查点的fsimage镜像文件

6.7HDFS安全模式

6.7.1什么是安全模式

安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求。在NameNode主节点启动时，HDFS首先进入安全模式，DataNode在启动的时候会向namenode汇报可用的block等状态，当整个系统达到安全标准时，HDFS自动离开安全模式。如果HDFS处于安全模式下，则文件block不能进行任何的副本复制操作，因此达到最小的副本数量要求是基于datanode启动时的状态来判定的，启动时不会再做任何复制（从而达到最小副本数量要求）

6.7.2安全模式相关的配置

系统什么时候才离开安全模式，需要满足哪些条件？当收到来自datanode的状态报告后，namenode根据配置，确定 1）可用的block占总数的比例、2）可用的数据节点数量符合要求之后，离开安全模式。如果有必要，也可以通过命令强制离开安全模式。与安全模式相关的主要配置在hdfs-site.xml文件中，主要有下面几个属性

dfs.namenode.replication.min: 最小的文件block副本数量，默认为1.

dfs.namenode.safemode.threshold-pct: 副本数达到最小要求的block占系统总block数的百分比，当实际比例超过该配置后，才能离开安全模式（但是还需要其他条件也满足）。默认为0.999f，也就是说符合最小副本数要求的block占比超过99.9%时，并且其他条件也满足才能离开安全模式。如果为小于等于0，则不会等待任何副本达到要求即可离开。如果大于1，则永远处于安全模式。

dfs.namenode.safemode.min.datanodes: 离开安全模式的最小可用（alive）datanode数量要求，默认为0.也就是即使所有datanode都不可用，仍然可以离开安全模式。

dfs.namenode.safemode.extension: 当集群可用block比例，可用datanode都达到要求之后，如果在extension配置的时间段之后依然能满足要求，此时集群才离开安全模式。单位为毫秒，默认为1.也就是当满足条件并且能够维持1毫秒之后，离开安全模式。 这个配置主要是对集群的稳定程度做进一步的确认。避免达到要求后马上又不符合安全标准。

总结一下，要离开安全模式，需要满足以下条件：
1）达到副本数量要求的block比例满足要求；
2）可用的datanode节点数满足配置的数量要求；
3） 1、2 两个条件满足后维持的时间达到配置的要求

相关推荐