此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player

您现在的位置: 智可网 - 新技术 - Hadoop - 正文
Hadoop namenode启动过程详细剖析及瓶颈分析
教程录入:李隆权    责任编辑:quan 作者:佚名 文章来源:656463

Namenode会将HDFS的文件和目录元数据存储在一个叫fsimage的二进制文件中,每次保存fsimage之后到下次保存之间的所有hdfs操作,将会记录在editlog文件中,当editlog达到一定的大小(bytes,由fs.checkpoint.size参数定义)或从上次保存过后一定时间段过后(sec,由fs.checkpoint.period参数定义),namenode会重新将内存中对整个HDFS的目录树和文件元数据刷到fsimage文件中。Namenode就是通过这种方式来保证HDFS中元数据信息的安全性。

Fsimage是一个二进制文件,当中记录了HDFS中所有文件和目录的元数据信息,在我的HadoopHDFS版中,该文件的中保存文件和目录的格式如下:

 

namenode重启加载fsimage时,就是按照如下格式协议从文件流中加载元数据信息。从fsimag存储格式可以看出,fsimage保存有如下信息:

1.         首先是一个image head,其中包含:

a)         imgVersion(int):当前image的版本信息

b)        namespaceID(int):用来确保别的HDFS instance中的datanode不会误连上当前NN

c)         numFiles(long):整个文件系统中包含有多少文件和目录

d)        genStamp(long):生成该image时的时间戳信息。

2.         接下来便是对每个文件或目录的源数据信息,如果是目录,则包含以下信息:

a)         path(String):该目录的路径,如”/user/build/build-index”

b)        replications(short):副本数(目录虽然没有副本,但这里记录的目录副本数也为3

c)         mtime(long):该目录的修改时间的时间戳信息

d)        atime(long):该目录的访问时间的时间戳信息

e)         blocksize(long):目录的blocksize都为0

f)         numBlocks(int):实际有多少个文件块,目录的该值都为-1,表示该item为目录

g)        nsQuota(long)namespace Quota值,若没加Quota限制则为-1

h)        dsQuota(long)disk Quota值,若没加限制则也为-1

i)          username(String):该目录的所属用户名

j)          group(String):该目录的所属组

k)        permission(short):该目录的permission信息,如644等,有一个short来记录。

3.         若从fsimage中读到的item是一个文件,则还会额外包含如下信息:

a)         blockid(long):属于该文件的blockblockid

b)        numBytes(long):该block的大小

c)         genStamp(long):该block的时间戳

当该文件对应的numBlocks数不为1,而是大于1时,表示该文件对应有多个block信息,此时紧接在该fsimage之后的就会有多个blockidnumBytesgenStamp信息。

因此,在namenode启动时,就需要对fsimage按照如下格式进行顺序的加载,以将fsimage中记录的HDFS元数据信息加载到内存中。

BlockMap

从以上fsimage中加载如namenode内存中的信息中可以很明显的看出,在fsimage中,并没有记录每一个block对应到哪几个datanodes的对应表信息,而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储,而是在所有datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenodenamenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanodenamenode汇报块信息的过程叫做blockReport,而namenodeblock -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。

BlocksMap的内部数据结构如下:   

              

 

如上图显示,BlocksMap实际上就是一个Block对象对BlockInfo对象的一个Map表,其中Block对象中只记录了blockidblock大小以及时间戳信息,这些信息在fsimage中都有记录。而BlockInfo是从Block对象继承而来,因此除了Block对象中保存的信息外,还包括代表该block所属的HDFS文件的INodeFile对象引用以及该block所属datanodes列表的信息(即上图中的DN1DN2DN3,该数据结构会在下文详述)。

因此在namenode启动并加载fsimage完成之后,实际上BlocksMap中的key,也就是Block对象都已经加载到BlocksMap中,每个key对应的value(BlockInfo)中,除了表示其所属的datanodes列表的数组为空外,其他信息也都已经成功加载。所以可以说:fsimage加载完毕后,BlocksMap中仅缺少每个块对应到其所属的datanodes list的对应关系信息。所缺这些信息,就是通过上文提到的从各datanode接收blockReport来构建。当所有的datanode汇报给namenodeblockReport处理完毕后,BlocksMap整个结构也就构建完成。

BlockMap中datanode列表数据结构

BlockInfo中,将该block所属的datanodes列表保存在一个Object[]数组中,但该数组不仅仅保存了datanodes列表,还包含了额外的信息。实际上该数组保存了如下信息:

 

上图表示一个block包含有三个副本,分别放置在DN1DN2DN3三个datanode上,每个datanode对应一个三元组,该三元组中的第二个元素,即上图中prev block所指的是该block在该datanode上的前一个BlockInfo引用。第三个元素,也就是上图中next Block所指的是该block在该datanode上的下一个BlockInfo引用。每个block有多少个副本,其对应的BlockInfo对象中就会有多少个这种三元组。

       Namenode采用这种结构来保存block->datanode list的目的在于节约namenode内存。由于namenodeblock->datanodes的对应关系保存在了内存当中,随着HDFS中文件数的增加,block数也会相应的增加,namenode为了保存block->datanodes的信息已经耗费了相当多的内存,如果还像这种方式一样的保存datanode->block list的对应表,势必耗费更多的内存,而且在实际应用中,要查一个datanode上保存的block list的应用实际上非常的少,大部分情况下是要根据block来查datanode列表,所以namenode中通过上图的方式来保存block->datanode list的对应关系,当需要查询datanode->block list的对应关系时,只需要沿着该数据结构中next Block的指向关系,就能得出结果,而又无需保存datanode->block list在内存中。

分享
打赏我
打开支付宝"扫一扫" 打开微信"扫一扫"
客户端
"扫一扫"下载智可网App
意见反馈
Hadoop namenode启动过程详细剖析及瓶颈分析
作者:佚名 来源:656463

Namenode会将HDFS的文件和目录元数据存储在一个叫fsimage的二进制文件中,每次保存fsimage之后到下次保存之间的所有hdfs操作,将会记录在editlog文件中,当editlog达到一定的大小(bytes,由fs.checkpoint.size参数定义)或从上次保存过后一定时间段过后(sec,由fs.checkpoint.period参数定义),namenode会重新将内存中对整个HDFS的目录树和文件元数据刷到fsimage文件中。Namenode就是通过这种方式来保证HDFS中元数据信息的安全性。

Fsimage是一个二进制文件,当中记录了HDFS中所有文件和目录的元数据信息,在我的HadoopHDFS版中,该文件的中保存文件和目录的格式如下:

 

namenode重启加载fsimage时,就是按照如下格式协议从文件流中加载元数据信息。从fsimag存储格式可以看出,fsimage保存有如下信息:

1.         首先是一个image head,其中包含:

a)         imgVersion(int):当前image的版本信息

b)        namespaceID(int):用来确保别的HDFS instance中的datanode不会误连上当前NN

c)         numFiles(long):整个文件系统中包含有多少文件和目录

d)        genStamp(long):生成该image时的时间戳信息。

2.         接下来便是对每个文件或目录的源数据信息,如果是目录,则包含以下信息:

a)         path(String):该目录的路径,如”/user/build/build-index”

b)        replications(short):副本数(目录虽然没有副本,但这里记录的目录副本数也为3

c)         mtime(long):该目录的修改时间的时间戳信息

d)        atime(long):该目录的访问时间的时间戳信息

e)         blocksize(long):目录的blocksize都为0

f)         numBlocks(int):实际有多少个文件块,目录的该值都为-1,表示该item为目录

g)        nsQuota(long)namespace Quota值,若没加Quota限制则为-1

h)        dsQuota(long)disk Quota值,若没加限制则也为-1

i)          username(String):该目录的所属用户名

j)          group(String):该目录的所属组

k)        permission(short):该目录的permission信息,如644等,有一个short来记录。

3.         若从fsimage中读到的item是一个文件,则还会额外包含如下信息:

a)         blockid(long):属于该文件的blockblockid

b)        numBytes(long):该block的大小

c)         genStamp(long):该block的时间戳

当该文件对应的numBlocks数不为1,而是大于1时,表示该文件对应有多个block信息,此时紧接在该fsimage之后的就会有多个blockidnumBytesgenStamp信息。

因此,在namenode启动时,就需要对fsimage按照如下格式进行顺序的加载,以将fsimage中记录的HDFS元数据信息加载到内存中。

BlockMap

从以上fsimage中加载如namenode内存中的信息中可以很明显的看出,在fsimage中,并没有记录每一个block对应到哪几个datanodes的对应表信息,而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储,而是在所有datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenodenamenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanodenamenode汇报块信息的过程叫做blockReport,而namenodeblock -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。

BlocksMap的内部数据结构如下:   

              

 

如上图显示,BlocksMap实际上就是一个Block对象对BlockInfo对象的一个Map表,其中Block对象中只记录了blockidblock大小以及时间戳信息,这些信息在fsimage中都有记录。而BlockInfo是从Block对象继承而来,因此除了Block对象中保存的信息外,还包括代表该block所属的HDFS文件的INodeFile对象引用以及该block所属datanodes列表的信息(即上图中的DN1DN2DN3,该数据结构会在下文详述)。

因此在namenode启动并加载fsimage完成之后,实际上BlocksMap中的key,也就是Block对象都已经加载到BlocksMap中,每个key对应的value(BlockInfo)中,除了表示其所属的datanodes列表的数组为空外,其他信息也都已经成功加载。所以可以说:fsimage加载完毕后,BlocksMap中仅缺少每个块对应到其所属的datanodes list的对应关系信息。所缺这些信息,就是通过上文提到的从各datanode接收blockReport来构建。当所有的datanode汇报给namenodeblockReport处理完毕后,BlocksMap整个结构也就构建完成。

BlockMap中datanode列表数据结构

BlockInfo中,将该block所属的datanodes列表保存在一个Object[]数组中,但该数组不仅仅保存了datanodes列表,还包含了额外的信息。实际上该数组保存了如下信息:

 

上图表示一个block包含有三个副本,分别放置在DN1DN2DN3三个datanode上,每个datanode对应一个三元组,该三元组中的第二个元素,即上图中prev block所指的是该block在该datanode上的前一个BlockInfo引用。第三个元素,也就是上图中next Block所指的是该block在该datanode上的下一个BlockInfo引用。每个block有多少个副本,其对应的BlockInfo对象中就会有多少个这种三元组。

       Namenode采用这种结构来保存block->datanode list的目的在于节约namenode内存。由于namenodeblock->datanodes的对应关系保存在了内存当中,随着HDFS中文件数的增加,block数也会相应的增加,namenode为了保存block->datanodes的信息已经耗费了相当多的内存,如果还像这种方式一样的保存datanode->block list的对应表,势必耗费更多的内存,而且在实际应用中,要查一个datanode上保存的block list的应用实际上非常的少,大部分情况下是要根据block来查datanode列表,所以namenode中通过上图的方式来保存block->datanode list的对应关系,当需要查询datanode->block list的对应关系时,只需要沿着该数据结构中next Block的指向关系,就能得出结果,而又无需保存datanode->block list在内存中。