设为首页 收藏本站
查看: 1606|回复: 0

[经验分享] hadoop源码分析系列(六)——org.apache.hadoop.hdfs包之nameNode篇

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2014-6-6 11:00:15 | 显示全部楼层 |阅读模式
摘要: 概述:nameNode主要负责管理hdfs中的namespace和inode信息,namenode维护了一个两个关键的列表1、文件与块的映射(namespace)2、块于节点的映射(inodes)namespace的信息存储在磁盘文件中,inode的信息每次 ...

概述:
nameNode主要负责管理hdfs中的namespace和inode信息,namenode维护了一个两个关键的列表
1、文件与块的映射(namespace)
2、块于节点的映射(inodes)
namespace的信息存储在磁盘文件中,inode的信息每次启动namenode的时候就会重建
NameNode中的FSNamesystem负责对文件系统的管理,当然还需要启动http server暴漏ipc通信接口,用来和外部通信。
NameNode允许客户机通过ClientProtocol类获得namenode中dfs的信息,允许datanode通过DatanodeProtocol来与之交互,还允许secondary namenodes通过NamenodeProtocol协议与之交互
还包含了一些度量NN的参数指标,保存在myMetrics中
NN提供了两个server,一个是rpc server另一个是http server

下面具体介绍下关键的方法:

initialize(Configuration conf):初始化方法,初始化权限信息,创建rpc服务器,初始化度量信息和文件系统,启动http服务器,启动回收站线程。
startHttpServer(Configuration conf) :通过以下参数初始化http服务器:dfs.info.bindAddress、dfs.info.port、dfs.http.address、dfs.https.enable、dfs.https.need.client.auth、dfs.https.address、dfs.https.server.keystore.resource、dfs.datanode.https.address、datanode.https.port、name.node.address、name.system.image、
getBlocks(DatanodeInfo datanode, long size):获得NN中存储的块信息
abandonBlock:丢弃块
addBlock:增加块
blockReceived:接收块
commitBlockSynchronization:块同步
metaSave:保存元数据
register:注册dataNode
sendHeartbeat:发送心跳




关键类:
回收站类Trash:这个类的原理和win的回收站一样,很容易理解,主要包含3个目录.trash、user和Current,2个时间,一个是过期时间,一个是线程检查点的时间,当然还包括了fs和permission的信息,基本工作原理就是把要删除的文件先放到trash的current目录下,等到时间过了就永久删除了。

FSNamesystem类:主要维护5个表:1、文件与块的映射表 2、有效的块的集合表 3、块到节点的对应关系表  4、节点到块的对应关系表 5、基于LRU算法的节点心跳表
还有其他的小表,如满足冗余策略的块到节点的映射表、最近失效的块的集合、额外的块的信息、需要冗余的块的集合、正在冗余的块的集合。
FSNamesystem还记录了块的冗余过程中的3个状态,提供了检测心跳的线程,冗余过程中的监视器线程、安全模式的监视器线程。

下面介绍几个inode相关的类,这几个类的分析有助于了解hdfs的目录结构,其实在经典的操作系统理论中就有inode的概念,只是那里面记录的是文件在磁盘的位置信息,在hdfs中这个inode其实就是记录了数据块在hdfs中的位置信息:
153445y6znjbmvcsnnzd9y.png
先分析下核心抽象类inode:实现了Comparable接口,这个很容易理解,为了比较两个inode的信息是否相同,和INodeDirectory类是包含,且多对一的关系,这样可以形成树状结构,准确的说INodeDirectory和INodeFile形成了树状结构,只不过inode抽象类提取了这两个类之前的共同部分,抽象成一个独立的抽象类。
这个抽象类维护了inode的权限信息,访问时间,修改时间,使用的ns的个数和使用的ds的个数,还有个INodeDirectory,用来记录上一级的inode。

INodeFile类记录了文件中包含的所有块的信息,冗余数和期望的块大小当然还包括权限信息

INodeFileUnderConstruction类继承了INodeFile,保存了正在构造的文件的一些信息,包括主要的创建节点、发起请求的client的信息,配合构造的辅助节点的信息。

INodeDirectoryWithQuota类继承了INodeDirectory类,主要增加了对目录几点ns数、ns配额、ds配额和ds数
这里所说的ns是指namespace、ds是指diskspace



FSDirectory类维护了文件系统的目录树的信息,主要包括FSNamesystem信息和INodeDirectoryWithQuota信息,这里的目录指的是根目录,还有FSImage的信息,这个类后面会进行介绍,然后是是否可读和度量的信息,提供了对块的目录的操作,可以认为这个类和FSNamesystem共同构成了namenode的核心。

DatanodeDescriptor类除了可以保存dataNode上的信息,但是和之前的dataNodeInfo不同,这个类只负责在nameNode内传递dataNode的信息,并不会把这些信息持久化,这个类的增强功能在于内部的三个内部类,BlockIterator类储存了datanode中包括的块信息,BlockTargetPair类保存块和dataNode的信息,BlockQueue队列存储了多个BlockTargetPair信息。

lease类体系:

153445vr7fuq5c8fu2c2co.png
LeaseManager类用来管理文件的租约,所谓文件的租约可以理解为文件并发读写的锁机制,这是hdfs一致性模型中最重要的一环,下面介绍下主要的理论:

Lease内部类标示一把锁,每一个和他通信的client都会在进来前请求一个时间戳的更新用作唯一标示,超时或是客户端挂了,这个锁就会被释放。Monitor类就是监督锁保证及时释放的。

1、Namenode来维护租约信息
2、对于文件的租约来说,主要考虑文件的最后一个块b的租约信息,先得到存储这个块b的dn的信息,然后从多个dn中分配一个主dn p,p从nn中得到一个新的stamp,p从dn中得到块的信息后计算最小块的长度,然后用这个stamp更新所有的dn,通知nn更新结果,nn更新自己的BlockInfo信息,nn从租约队列中删除f,以此为循环所有的文件在租约队列中都被删除,nn提交editlog。
addLease:给指定文件加锁
changeLease:换锁
checkLeases:检查锁
countLease:锁计数
getSortedLeases:得到一个有顺序的锁队列
removeLease:移除锁,当然了类中有很多移除的方法

FSEditLog类和FSImage类:这两个类维护了namenode的日志信息。
FSEditLog:顾名思义记录namenode fs的修改,首先定义了一些操作的常量,输出流输入流句柄、事务计数器、最近的log时间、FSImage信息、事务统计信息和度量信息。
FSImage类记录了namespace的修改日志和检查点信息,
recoverTransitionRead:通过读日志恢复之前的fs事务信息,
doRollback:回滚fs状态
doImportCheckpoint:导入指定目录下的checkpoint信息
loadFSImage() :载入最近的image信息
loadFSImage:载入指定文件的image
saveFSImage:保存image
saveINode2Image:保存inode的image
NameNodeDirType给出了可以存储的文件内容既可以只存储editlog,也可以image和editlog一起存

最后要介绍的是SecondaryNameNode类,这个类或者说这个服务其实就是一个线程:这个线程最主要的任务在于维护检查点的信息。
initialize:连接nn,初始化客户端信息,
run:没5分钟检查一次nn的editlog的增量大小
downloadCheckpointFiles:传输文件
doCheckpoint:做一次新的检查点
putFSImage:给nn传递新的image
doMerge:合并image
类内部提供了用于测试error的方法,在每次调用的时候执行,保证了执行过程的正确性。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-20266-1-1.html 上篇帖子: hadoop源码分析系列(五)——org.apache.hadoop.hdfs包之balancer篇 下篇帖子: hadoop源码分析系列(七)——org.apache.hadoop.hdfs包完结篇—...
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表