hdfs——nn的启动优化

hdfs——nn的启动优化,第1张

hdfs——nn的启动优化

【概述】


上一篇文章讲解了,在一定DN节点规模,一定block数据量下的并发写文件的优化问题。

在这种节点、数据量规模的集群中,当HDFS全部重启(nn+dn全部重启),或者两个NN都重启后,需要经过较长时间,才能真正对外提供服务。

那么nn启动过程中都干了些啥,主要耗时点在哪,以及应当如何优化,本文就来聊聊这些问题——启动优化。

【启动流程与耗时分析】


NN的启动可以粗略的分为以下几个步骤:

启动http服务

加载文件系统

启动rpc服务

按需启动插件服务

处理dn的注册以及dn的全量块汇报

其中启动HTTP服务、RPC服务,都是在对应配置的IP端口上进行监听,然后创建对应的reader线程、handler线程,然后等待客户端的连接并处理客户端的请求。

加载文件系统则是启动过程中的关键步骤,又可以细分为:

加载fsimage文件

加载fsimage的MD5文件并进行比对校验

加载editlog文件

checkpoint的保存(可选)

进入安全模式

加载fsimage就是读取fsimage文件中的内容,并以此在内存中构建相关的元数据信息;加载editlog则是读取本地editlog文件或到JournalNode上读取editlog文件;checkpoint本质上还是对元数据信息持久化保存,对于HA模式而言,不需要进行checkpoint的保存处理;最后按需进入安全模式,等待dn的注册与块上报,当上报的块信息达到指定比例后(默认为99.9%),延迟一段时间后解除安全模式。

需要注意的是:这几个步骤是串行进行的,一个步骤完成后才进行下一个处理动作。

整个启动过程中,耗时的点在于加载文件系统和dn注册后的块汇报。加载文件系统的耗时在整个启动过程中占50%左右,剩下的50%为dn注册的块汇报处理。http服务和rpc服务的启动几乎不耗时。

【fsimage的格式】


既然加载文件系统占整个启动过程中一半的耗时,有必要先来了解了fsimage文件格式是怎样的,具体的加载过程又是怎样的。

整个fsimage文件由几个部分组成,最前面的是Header头信息,然后是多个section段,section之后是一个Summary概要信息,以及Summary的长度。

header的内容在2.4版本之后均固定为"HDFSIMG1",长度为8字节,同时指明后面的section的编码方式(采用protobuf的方式编码存储)。

summary则记录各个section的名字、在文件中的起始偏移位置以及长度。section则保存Hdfs元数据的相关信息,其中最重要的当属INODE和INODE_DIR两个section了,通常来说,这两个section占据fsimage的绝大部分空间。

INODE记录了hdfs中包含的所有文件/目录的信息,包括名称及可能的各个属性,每个INODE对应一条记录信息;而INDOE_DIR则记录了INODE的父子关系,也就是文件、目录的层级关系,同样也是一条记录对应一条关系信息。有了两个section,就可以构造出完整的文件系统目录树。

读取fsimage文件时,先读文件末尾4字节,得到Summary的起始位置,然后读取Summary的内容,这样就知道每个section的起始位置,长度,因此就可以按需加载各个section的内容了。

另外,section的加载顺序是串行的,即加载INODE_DIR时,必须先完成INODE的加载,否则可能出现找不到对应的inode条目。

【如何优化】


从上面fsimage的文件格式可以看出,每个文件的inode在INodeSection中都是一个独立的条目,读fsimage文件时单线程遍历每个条目,并在内存中构造对应的数据结构进行存储。因此,当有海量文件信息存储在fsiamge中时,单线程遍历必然是非常耗时的。这也就是启动耗时长的主要原因。

既然单线程加载很慢,那是否可以调整成多线程加载,每个线程读取其中的一部分,从而加速完成整个INodeSection的加载呢?

实际上,社区版本中的优化就是这么做的,将INodeSeciont拆分成多个带sub后缀的新分区名,同时保留原始的分区信息,同时在summary中增加各个子section的信息。

真正读取文件时,使用多线程进行加载,每个线程完成一部分子section的读取,实现读取的加速,同样INODE_DIR也通过多线程并行进行读取。

其中,拆分后的子分区个数由配置项("dfs.image.parallel.target.sections")决定,并行加载的线程数由配置项("dfs.image.parallel.threads")决定。

这样一来,就可以通过多线程并行进行加载INODE和INODE_DIR两个section,每个线程读取一个子section,有效提升加载速度。

除此之外,社区还有两个优化:

一个优化是:fsimage文件md5校验计算和fsimage的加载并行处理,在此之前是串行处理的,详见官方JIRA(HDFS-13694)。

另一个优化是:在加载INodeDirectorySection后,需要更新blocksMap、更新nameCache,然后将inode添加到inode directory的child列表中,优化的逻辑是将这三个 *** 作步骤并行进行处理。

【优化效果】


从官方给出的优化效果来看,数据量在几个亿的级别时,三个优化整体能达到40%-60%的提升(有兴趣的可以去看看社区给出的测试数据)。

而实际测试发现,整体效果差不多是在这个范围内,但具体还会NN所在节点的CPU核数有一定的关系,并行加载时,CPU几乎处于满负荷状态,如果核数不够,那么效果会一般,核数稍微大一些,优化的效果会明显了。

【总结】


好了,小结一下,本文主要讲述了nn的启动流程,分析了主要的耗时点,然后结合fsimage的文件结构,讲述社区的实际优化处理,以及优化后的效果。

如果觉得本文对你有帮助,三连走起(点赞,在看,分享转发),也欢迎加我微信交流~

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5717697.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存