HDFS学习笔记

最新推荐文章于 2023-07-06 16:12:15 发布

asd_1314

最新推荐文章于 2023-07-06 16:12:15 发布

阅读量179

点赞数

分类专栏： HDFS 文章标签： HDFS

本文链接：https://blog.csdn.net/u012810123/article/details/102848516

版权

HDFS 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

HDFS 概念

HDFS是什么？

HDFS是一个分布式的文件系统，用于存储文件，通过目录树来定位文件；由很多服务器联合来实现功能，并且服务有个字的角色。

适用场景

适用场景
适合一次写入，多次读出的场景且不支持对文件的直接修改，仅支持在文件末尾追加

HDFS构成

HDFS 构成： NameNode 、DataNode、 SecondaryNameNode;
NameNode 作用：负责管理整个文件系统的元数据以及每一个路径(文件)所对应的数据块信息
DataNode 作用：负责管理用户的文件数据块，每个本数据块都可以在多个datanoe上存储多个副本
SecondaryNameNode作用：用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。

HDFS 块大小

HDFS 的文件在物理上是分块存储(block)，块的大小可以通过配置参数(dfs.blocksize)来定，在hadoop2.x 版本中默认为128M
HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。

为什么块大小不能设置太小，也不能设置太大？

为什么块大小不能设置太小，也不能设置太大？
1. HDFS的块设置太小，会增加寻址时间，使得程序可能一直在寻找块的开始位置
2. 如果设置的太大，从磁盘传输数据的时间会明显大于定位这个块所需的寻址时间，导致程序处理这块数据时会非常慢

HDFS文件块大小计算

HDFS文件块大小
1、集群中的block
2、寻址时间：查找目标block的时间
3、寻址时间为传输时间的1%时，则为最佳状态。
4、磁盘的传输速率
文件块大小= 寻址时间/0.01 * 传输速率

HDFS 的数据流

写HDFS过程中三个基本单位

block

block：是最大的一个单位，它是最终存储于DataNode上的数据粒度，由dfs.block.size参数决定，默认是64M；注：这个参数由客户端配置决定；

packet

packet是中等的一个单位，它是数据由DFSClient流向DataNode的粒度，以dfs.write.packet.size参数为参考值，默认是64K；注：这个参数为参考值，是指真正在进行数据传输时，会以它为基准进行调整，调整的原因是一个packet有特定的结构，调整的目标是这个packet的大小刚好包含结构中的所有成员，同时也保证写到DataNode后当前block的大小不超过设定值；

chunk

chunk是最小的一个单位，它是DFSClient到DataNode数据传输中进行数据校验的粒度，由io.bytes.per.checksum参数决定，默认是512B；注：事实上一个chunk还包含4B的校验值，因而chunk写入packet时是516B；数据与检验值的比值为128:1，所以对于一个128M的block会有一个1M的校验文件与之对应；

HDFS写数据流程

1）客户端向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。

2）namenode返回是否可以上传。

3）客户端请求第一个 block上传到哪几个datanode服务器上。

4）namenode返回3个datanode节点，分别为dn1、dn2、dn3。

5）客户端请求dn1（最近原则）上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成

6）dn1、dn2、dn3逐级应答客户端

7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答

8）当一个block传输完成之后，客户端再次请求namenode上传第二个block的服务器。（重复执行3-7步）

写过程中的三层buffer

写过程中会以chunk、packet及packet queue三个粒度做三层缓存；

首先，当数据流入DFSOutputStream时，DFSOutputStream内会有一个chunk大小的buf，当数据写满这个buf（或遇到强制flush），会计算checksum值，然后填塞进packet；

当一个chunk填塞进入packet后，仍然不会立即发送，而是累积到一个packet填满后，将这个packet放入dataqueue队列；

进入dataqueue队列的packet会被另一线程按序取出发送到datanode；（注：生产者消费者模型，阻塞生产者的条件是dataqueue与ackqueue之和超过一个block的packet上限）

HDFS写数据流程

1）客户端向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。

2）namenode返回是否可以上传。

3）客户端请求第一个 block上传到哪几个datanode服务器上。

4）namenode返回3个datanode节点，分别为dn1、dn2、dn3。

5）客户端请求dn1（最近原则）上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成

6）dn1、dn2、dn3逐级应答客户端

8）当一个block传输完成之后，客户端再次请求namenode上传第二个block的服务器。（重复执行3-7步）

NameNode && Secondary NameNode 工作机制

镜像文件和编辑日志文件

概念

namenode 被格式化后，在namenode 的存储目录中会产生以下文件：

edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

镜像文件（fsimage）

fsimage（镜像文件）文件其实是Hadoop文件系统元数据的一个永久性的检查点，其中包含Hadoop文件系统中的所有目录和文件idnode的序列化信息

查看fsimage文件命令 - oiv

基本语法
hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

编辑日志文件（edits）

edits（编辑日志）文件存放的是Hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中

查看edits 文件命令- oev

基本语法
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

seen_txid 文件

seen_txid 文件保存的是一个数字，就是最后一个edits_ 的数字

以上文件的作用

NameNode启动过程：每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

工作机制

工作机制流程图

详细过程

第一阶段：namenode启动
（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求
（3）namenode记录操作日志，更新滚动日志。
（4）namenode在内存中对数据进行增删改查
第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
（2）Secondary NameNode请求执行checkpoint。
（3）namenode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint
（7）拷贝fsimage.chkpoint到namenode
（8）namenode将fsimage.chkpoint重新命名成fsimage