数据量越来越多,在一个操作系统管辖的范围存不下了,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,因此迫切需要一种系统来管理多台机器上的文件,这就是分布式文件管理系统;是一种允许文件通过网络在多台主机上分享的文件系统,可让多机器上的多用户分享文件和存储空间。
分布式文件管理系统很多,hdfs只是其中一种。适用于一次写入多次查询的情况,不支持并发写情况,小文件不合适。
下面给大家讲解一下HDFS的数据管理机制;
HDFS架构有:
NameNode
DataNode
Secondary NameNode
HDFS数据管理机制
当有客户端请求HDFS进行写文件时:
1.客户端API通过RPC机制向NameNode通信,请求上传文件;
2.NameNode根据文件切分的块信息分配好相应的DataNode,同时维护元数据信息,包括文件虚拟路径,块数据与DataNode的对应信息等,然后向客户端返回分配的DataNode;
3.客户端根据返回的信息向DataNode中写入文件块数据,客户端对每个文件块数据只写入一次之后就返回写文件成功,没有进行副本数据写入;
4.文件块数据在第一台DataNode中写入成功之后,由DataNode进行副本数据的写入,该台DataNode向另外一台DataNode写入副本数据,写入成功之后,再由第二台DataNode向下一台继续写入副本数据,以此类推,直到副本数量达到配置文件中定义的数量,如果向某个DataNode写入失败,就往上一个DataNode返回错误信息;
NameNode
Namenode是整个文件系统的管理节点。它的职责是维护着整个文件系统的文件目录树,文件/目录的元信息和每个文件对应的数据块列表。接收用户的操作请求。
NameNode元数据管理机制
Namenode始终在内存中保存metedata,用于处理“读请求”;
当有“写请求”时:
1.客户端上传文件时,NameNode首先会向edits log文件中记录元数据操作日志;
2.客户端开始上传文件,上传成功之后就返回成功信息给NameNode,NameNode就在内存中写入这次上传操作的元数据信息;
3.每当edits log写满或者达到指定时间时,需要将这一段时间的新的元数据刷到fsimage文件中;
Secondary NameNode
edits文件是有大小限制的,那么如何保证fsimage与内存中的数据一致性,HDFS将最新的元数据(edits)追加到fsimage末尾以保证数据一致性,防止数据丢失;文件合并的工作是Secondary NameNode来执行;
执行checkpoint操作,合并fsimage,edits log;
HA的一个解决方案。但不支持热备。配置即可;
checkpoint过程:
1.NameNode通知Secondary NameNode执行checkpoint操作
2.Secondary NameNode收到执行请求后,通知NameNode停止往edits log中写入元数据;
3.NameNode收到请求之后,新建edits.new文件,如果这时候有写文件请求,元数据是写入新建的edits文件中;
4.Secondary NameNode从NameNode下载fsimage和edits文件(通过http);
5.Secondary NameNode对下载的fsimage,edits进行合并;
6.Secondary NameNode上传合并之后的文件fsimage.chkpoint文件给NameNode;
7.NameNode用新的fsimage替换旧的fsimage;
什么时候checkpoint:
可以在hdfs配置文件中配置属性来决定什么时候checkpoint;
1.fs.checkpoint.period:指定两次checkpoint的最大时间间隔,默认3600秒;
2.lfs.checkpoint.size:规定edits文件的最大值,一旦超过这个值则强制checkpoint,不管是否到达最大时间间隔。默认大小是64M。
DataNode
提供真实文件数据的存储服务,HDFS中,默认Block大小是128MB,如果一个文件小于一个数据块的大小,并不占用整个数据块存储空间;