分享

元数据文件

Joker 发表于 2015-5-5 11:30:17 [显示全部楼层] 回帖奖励 阅读模式 关闭右栏 3 9197
元数据映射信息存放在fsimage中,当NameNode启动的时候,会加载如内存中,并执行edits文件中所有的操作
那么,我想问的是,当客户端发送一条删除指令的时候,此时没有进行合并成最新的元数据信息入内存中
假设配置了fsimage的合并,但是没到达一定的时间和文件的大小。

那么,如何读取内存中的元数据信息表,这是我想知道的。
假设能读到,那么是否有数据,如果有,hadoop是否就只是删除本节点的数据,但是还存在副本数


已有(3)人评论

跳转到指定楼层
tntzbzc 发表于 2015-5-5 12:43:34
楼主是说的hadoop,还是hbase.hadoop上传文件是这么个过程

创建一个新文件的过程:

第一步:客户端通过DistributedFilesystem 对象中的creat()方法来创建文件,此时,RPC会 通过一个RPC链接协议来调用namenode,并在命名空间中创建一个新文件,namenode执行各种权限以及文件isexist 的检查,dfs返回一个输出流,否则抛出 IOEXCEPTION。输出流控制一个DFSoutPutstream,负责处理数据节点和名称节点之间的通信

第二步:客户端开始通过输出流写入数据,DFSoutPutstream将客户端写入的数据分成一个个的数据包包,然后写入到dfs中的一个queue,这些queue中的数据包被dfs中的数据流管理,数据流通过一定的分发机制,将这些数据包形成副本并存放在datanode上,当前例如我们设置的dfs.replication=3,则需要将副本放在三个datanode上,这三个datanode会通过一个管线连接,数据流将包分流给管线中第一个的datanode,这个节点会存储包并且发送给管线中的第二个datanode。同样地,第二个数据节点存储包并且传给管线中第三个datanode

(我就不画流程图了,大家肯定能想明白咯  )

第三步:其实第三步应该归属到第二步里面,上一步中所提到的DFSoutPutstream有一个内部等待确认queue,专门用来存放datanode收到的数据包,只有管线中所有的datanode收到副本并且存储成功返回成功标识后等待确认queue才会移除所有的数据包。


如果上传成功一份,那么删除就真正删除了。如果配置有垃圾回收站,那么还可以恢复。
如果是hbase,会先放到内存中,得到一定程度会flush.这是时候删除会先到内存查看,内存没有会到其它位置查看。
个人观点,仅供参考。

楼主的观点能否给出出处,共同学习和进步




回复

使用道具 举报

Joker 发表于 2015-5-5 13:10:24
tntzbzc 发表于 2015-5-5 12:43
楼主是说的hadoop,还是hbase.hadoop上传文件是这么个过程

这个是我个人的想法。

数据被传送到HDFS上之后,肯定被edits文件记录下来这次的操作,那么,在fsimage文件中也会有这个HDFS的idnode信息,用于管理数据(删除..)
我么知道元数据信息是被加载到内存中的,那么假设你配置了合并fsimage和edits文件,但是文件没有到达一定的大小或者没到一定的时间还没有去
合并文件产生新的fsimage加载到内存。

那么,在这个时候,我就把hdfs的一个文件删除了, 然后我 如何读取 “内存元数据”的信息,我认为的是如果还没有更新内存元数据应该是可以读取到旧值的但是不知道如何读取内存元数据,在内存的元数据是只读的
fsimage作为一个检查点,重启集群会把fsimage加载如内存,然后执行edits文件的内容
最终使得内存中的元数据和实际同步。


回复

使用道具 举报

Alkaloid0515 发表于 2015-5-5 14:44:43
Joker 发表于 2015-5-5 13:10
这个是我个人的想法。

数据被传送到HDFS上之后,肯定被edits文件记录下来这次的操作,那么,在fsimage ...



楼主可以看下面图:



元数据其实都是保存在磁盘的某个路径下的,并非放到内存中。

对于 Secondary NameNode在读取的时候会加载到内存,但是它并不参与namenode.而我们读取和写文件也和Secondary NameNode没有关系。

Secondary NameNode就像一个助手,有点像后勤人员,但并不真正打仗。

楼主可能认为元数据是放到内存中,其实不是的。

参考:hadoop详细了解5个进程的作用


回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条