1、优点
2、缺点
1、 namenode
1. 剖析文件写入
(1)客户端通过Distributed FileSystem模块向NameNode请求上传文件,NameNode检查目标文件是否已存在,父目录是否存在。
(2)NameNode返回是否可以上传。
(3)客户端请求第一个 Block上传到哪几个DataNode服务器上。
(4)NameNode返回3个DataNode节点和输出流对象,分别为dn1、dn2、dn3。
(5)客户端通过FSDataOutputStream模块请求dn1上传数据,dn1收到请求会继续调用dn2,然后dn2调用dn3,将这个通信管道建立完成。
(6)dn1、dn2、dn3逐级应答客户端,。
(7)客户端开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存),以Packet为单位,dn1收到一个Packet就会传给dn2,dn2传给dn3;dn1每传一个packet会放入一个应答队列等待应答,通过ack数据校验包返回数据是否传输完成。
(8)当一个Block传输完成之后,客户端再次请求NameNode上传第二个Block的服务器。(重复执行3-7步)。
成功后 关闭输出流,并向namenode返回文件已上传完毕,等待namenode
确认。因为NameNode已经知道文件由哪些块组成,因此仅需等待最小复制块即可成功返回即可。至此整个流程就完成了。
在HDFS写数据的过程中,NameNode会选择距离待上传数据最近距离的DataNode接收数据。那么这个最近距离怎么计算呢?
节点距离:两个节点到达最近的共同祖先的距离总和。
众所周知,数据块会在hdfs上有多个副本默认三分。那么副本是按照什么策略存储呢?
副本1会存储在client所处节点上,如果client不在对应datanode节点则会随机存储在datanode集群。
副本2会存储在另一个机架随机的一个节点,副本3会存储在和副本3相同机架另个节点。
1.客户端通过distribute file system 向 NamenNode 发送 请求下载文件A 德的请求。
2.namenode接收到后 判断是否在存在该文件,且该用户是否有权限如果有则返回对应文件的元数据信息
3 . 客户端接收到元数据信息后,创建input输入流 去找最近的节点D1去下载block1块数据,如果D1负载过高,那么下载block2块会打到另个d2节点。
4.传输block1数据,以packet为单位,每隔packet占64字节。先写入缓存,然后再写入目标文件
NameNode中的元数据信息是存储在哪里的呢?
首先想到的是数据会存储在内存中,但是如果断电那么数据就会丢失,整个集群就会挂掉。
如果存放在磁盘中读取效率又很低,因为有io操作。
为了解决这个问题 hdfs 在磁盘中产生了备份文件fsimage。和历史操作记录文件Edits
fsimage是存储大部分的元数据序列化信息镜像。
edits文件保存元数据最近的操作记录。元数据修改操作信息会首先同步到edits文件中,再同步到,内存中。这么做的原因是如果修改元数据期间断电,数据不会丢失。
所以即便断电 通过fsimage和edits两个文件合并最终也可以得到元数据信息。
如果修改记录过多放到edits文件中会导致文件数据过大,效率降低,开机恢复时间过长出于这个问题,所以需要定期更新合并fsimage和edit文件。如果这个操作由namenode完成,那么namennode工作效率就会降低。
这也是为什么namenode 和 SecondaryNamenode不在一台服务器节点的原因。
总结如下:
一、
二、
在此期间
checkpoint 服务时间再 hdfs-default.xml 中可以配置 默认是1分钟检查一次