HDFS原理_服务器内存256g hdfs-CSDN博客

本文链接：https://blog.csdn.net/myloveprogrmming/article/details/84351561

【1】分页查看日志

tail -f 可以实时跟踪日志

【2】hdfs集群：namenode datanode secondarynamenode

【3】namenode 管理元数据响应客户请求监视datanode情况（心跳，块报告）

【4】datanode存储文件块

【5】HDFS读写流程，重点在写【客户端往HDFS上写】

客户端对文件切块,设置副本数

客户端要配置hdfs-site.xml

客户端可以在任意一台非集群的电脑上，但是我们安装的只是基础环境，

没有命令和xml

HDFS写流程：

a客户端向namenode发送请求，namenode检查看它的目录树中是否存在客户端指定的路径，

检查在用户指定的目录下该文件是否存在，如果文件存在给出提示，如果目录存在文件不存在，namenode给客户端一个可以上传文件的响应

b发送rpc请求，请求上传第一块文件，namenode根据datanode的块报告得到datanode的硬盘使用情况列表，经过a负载均衡(空间)b距离(距离越近越快)找三台datanode返回给客户端。

距离：通过机架感知得到

上传数据时，datanode的选择策略：

第一个副本优先考虑跟客户端最近的机器（同机架【同一个架子上】)

第二个副本考虑跨机架选择一台机器，增加副本的安全性

第三个副本考虑跟第二个副本同机架的不同机器

c客户端和第一个块请求建立块传输通道(pipeline管道)，第一个datanode和第二个datanode请求建立pipeline，二和三请求建立pipeline，三返回应答成功给二，二返回应答成功给一，一返回应答成功给客户端。客户端将块读入到内存，然后存到包中，包的大小为64k，包在网络上传输数据。包先到datanode1，然后datanode1复制转发到datanode2,datanode2复制转发到datanode3，包每次成功传输一个包都会给前面的节点一个成功的响应。

一个块传输成功后，会再向namenode发送请求上传第二块...直到整个文件完全上传为止

d当整个文件上传成功，客户端会返回一个状态，namenode会写入元数据

问题：

1传输第一个数据块的过程中第三个datanode挂了怎么处理？

不处理，因为已经成功上传一份块，datanode每一小时向namenode报告一次块信息，这时候namenode会发现缺少副本，这时候会自动再备份一份。

如果datanode3又启动了怎么处理？

datanode3中只有该块的一部分数据，在下一次报告的时候，namenode会检查到错误块，会删掉它的这个块。

2如果建立传输通道的时候，node3挂了，怎么处理？

这次请求直接取消。知道3连不上了，返回返回...返回到客户端，客户端返回namenode知道3连不上

了，当挂4次namenode认准这个node3挂了，要重新2重新分配datanode。

3传输过程中，某一个包出错了，怎么处理？

客户端先把整个文件读到内存中，然后打包，将包发送到namenode的调度队列，等待接收方响应接收成功，再发送下一个包，如果回应的是失败会重新再发一遍包，重传的次数有限，如果一直失败则可以判断本次传输失败

4如果第一块，第二块都传输成功了，但是第三块传输失败，怎么办？

a传输第三块的时候，如果node1挂了怎么处理

客户端拿不到返回值，会返回到namenode返回失败，namenode会标记该文件为无效状态。

在下次datanode向namenode发送数据块报告时通过块报告检测出多了这些快，namenode会删除第一块第二块，第三块。

元数据什么时候写入？存储文件对应的块大小，多少块，每个块存储的位置。

当整个文件传输成功之后才在namenode中写入元数据信息。

如果客户端挂了怎么处理？？在报告时检查到多余的块，会删除文件块。

机架感知：

要配置配置文件，再运行脚本

IP 主机名 /哪个交换机/哪个机架

读流程（客户端从HDFS读）：

1向namenoade发送请求下载资源，namenode判断文件是否存在，返回文件的元数据信息，文件有哪些块，块的顺序，每个块存储的位置。

2客户端按顺序和datanode建立连接，下载块

下载块的过程：datanode：先把块读到内存fileinputstream,在写到socketoutputstream中再从这里写到客户端内存中socketinputstream然后在写入硬盘fileoutputstream

注：每个块读入完都会有一个结束标识

注：只有当元数据发生变化时才会发消息给namenode？？

问题HDFS启动流程？

1加载镜像文件

2加载操作日志

3等待datanode启动向namenode报告

HDFS不适合存储小文件（存储效率低）

每一个block存储的元数据信息大概占用150字节的元数据空间

假如一个block大小是128M，有10个块

128*10=1G 消耗元数据空间 10*150KB=1.5k

1T 1.5M

1P 1.5G

上面这段话的意思是每上传成功一个文件，namenode会记录这个文件块的元数据信息，这个信息占用150字节，元数据不属于文件也不属于块，它是在namenode中存的，为了记录文件块的信息。

这和电脑中inode硬盘占用情况差不多，inode占硬盘的十分之一，即有100G空间，10G存id，所以有电脑还有空间但是无法存入的情况发生：因为剩余空间被inode占用,(电脑不检测inode占用的空间)。

元数据

【a】内存元数据（有块的位置信息，报告时得到的加载到了内存中）

【b】fsimage元数据镜像文件，它不用存块位置信息，因为datanode会报告它的块存储位置给namenode。

【c】edits操作日志

当namenode突然挂了，重启后加载硬盘元数据镜像文件，用操作日志恢复元数据。

为了防止namenode挂掉，会备份namenode中的元数据（不只是备份操作日志，因为secondaryNamenode也可能会发生问题，这会导致镜像文件无法加载）。

“回滚” 是一种概念，例如保留最近一个星期的日志记录，就把前7天的抹杀掉，永远只保留你设置的记录规则。也就是定期备份日志，把很长的日志分别存在不同的文件中。

操作日志会定期回滚：为防止日志过大

当前日志的回滚，从而把日志分成多个文件

当恢复元数据时可能要加载大量操作日志，如果这个操作在namenode上进行则消耗大量资源，namenode的服务将会暂停。所以把这个任务交给secondarynamenode，

secondarynamenode做的工作:合并操作日志，备份fsimage（硬盘元数据镜像文件）

过程：namenode会在指定时间（时间间隔在设置里）向secondarynamenode发起请求，触发checkpoint,

secondarynamenode很闲所以返回namenode一个响应，注：secondarynamenode里本来就有fsimage。namenode通过http将操作日志上传到secondarynamenode。开始合并元数据：首先secondraynamenode加载硬盘中的simage和edits（操作日志）到内存中并进行合并，将合并好的元数据存到(dump)硬盘中，生成的文件叫fsimage.checkpoint，将这个文件上传给namenode，namenode要对这个文件进行校验（安全问题，系统级别的都要完事小心，通过namenode原来的fsimages和edits进行校验）。校验成功后改名，fsimage序号递增。fsiamge永远保留两个版本，edits保留之前一百万次的操作。

注fsimage就是一个备份数据，只有当namenode挂掉之后才会用到它。

namenode配置多个目录是为了备份元文件(操作日志)

datanode配置多个目录：一个块在存储时可以有多个位置来选择

之前将NameNode的元数据做备份，从secondarynamenode得到镜像文件，在备份的磁盘上读取操作日志，把它们合并，得到当前镜像文件。

可以。256G，一般namenode比datanode内存翻一倍。

Namenode 是 HDFS 的元数据服务器，管理并协调数据节点 Datanode 的工作，其内存中保存整个分布式文件系统的 2 类元数据：

(1)文件系统的名字空间，即系统目录树（恢复这个需要FsImages和Edit logs）。

(2)数据块副本与 Datanode 的映射，即副本的位置。

第(1)类元数据在 Namenode 上定期持久化，保存为镜像文件。数据块副本的位置信息没有实现持久化，而是在Namenode 启动时，通过接收 Datanode 的 Blockreport（块报告）获得。

//----------------------------------------------------------------------------------------------------------------------------

客户端对HDFS的文件系统目录树进行的任何修改，都会被记录到编辑日志（edits）文件中，以保证系统出现故障后，能够根据这些日志进行恢复，但是随着日志不断地增加，这意味着系统重启后，需要进行恢复的时间也就越长。为了避免这一情况的发生，HDFS引入了检查点（checkpoint）机制。

命名空间镜像(FSImage)文件是系统的持久性检查点，和编辑日志不同，它不能在客户端做的每次修改后都及时更新。故命名空间镜像再加上编辑日志，NameNode节点的元数据提供了安全保障。

在NameNode启动时，首先会将磁盘上（存在NameNode的磁盘上）的fsiamge命名空间镜像文件读入内存，恢复到某个时间的检查点，然后再读取编辑日志，进行重建（也可以成为合并）。

Hadoop中引入了第二命名节点Secondary NameNode节点，就是为了解决编辑日志随时间不断的增长，NameNode节点重启后要花很长时间来执行编辑日志中的每一个操作（来进行合并），这种情况。

Secondary NameNode节点的工作流程：

1）、定期的通过远程方法获取NameNode节点上编辑日志（edits）的大小；

2）、如果NameNode节点上编辑日志很小，就不需要合并NameNode上的fsimage文件和编辑日志；

3）、通过远程接口启动一次检查点过程，这时名字节点NameNode需要创建一个新的编辑日志文件edits.new，后续对文件系统的任何修改都记录到这个新编辑日志里；

4）、SecondNameNode点将Namenode上的fsimage文件和原编辑日志下载到本地，并在内存中合并，合并的结果输出为fsimage.ckpt；

5）、再次发起请求通知NameNode节点数据(fsimage.ckpt)已准备好，然后NameNode节点会下载fsimage.ckpt(并替换掉原来的fsimage)；

6）、NameNode下载结束后，Secondary NameNode会通过远程调用（NameNodeProtocol.rollFsImage()）完成这次检查点，NameNode在响应该远程调用时，会用fsimage.ckpt覆盖原来的fsimage文件，形成新的命名空间镜像，同时将新的编辑日志edits.new改名为edits。

整个流程如下图示：

inprogress为当前正在操作的日志，会回滚成它前面文件的格式

查看最后一次操作的编号

整个集群的信息

元数据管理

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

内存元数据(NameSystem)

磁盘元数据镜像文件

数据操作日志文件（可通过日志运算出元数据）

元数据存储机制

A、内存中有一份完整的元数据(内存meta data)

B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)