• NameNode中的FSImage文件


    第一:结构

    1:下图是FSImage数据结构图

    以看出,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中读到的是一个文件,则还会额外包含如下信息:

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

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

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

    3中是Block类的成员变量;通过BlockMap继承了Block类且新增了自己的成员变量;如下图:

    最后是通过BlockInfo对象来实现block和datanode对应的。

    为什么以上诉形式保存这个block对应datanode的list?

    Namenode采用这种结构来保存block->datanode list的目的在于节约namenode内存。由于namenode将block->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在内存中。

    总结: Namenode在内存中保存着整个文件系统的名字空间和文件数据块映射(Blockmap)的映像;其中文件系统的名字空间通过FSImage文件保存在本地操作系统的文件中;文件数据映射就是在读取FSImage文件时会添加额外内容BlockMap;这个内容没有永久性固化,而是在内存中存有。这个文件是NameNode功能的核心;它是可以永久性固化,就需要经常使用Load和Save操作,来实现这个过程。

    2:EditsLog文件:

    在HDFS中创建一个文件,Namenode就会在Editlog中插入一条记录来表示;同样地,修改文件的副本系数也将往Editlog插入一条记录。Namenode在本地操作系统的文件系统中存储这个Editlog。设计出它的目的就是不想一改就全部修改FSImage内容,而是修改那些变动的内容;且在宕机时,也需要用它和前期的FSImage来创建内存中的FSImage。

    如下图得出原因:

    存放的文件位置如下:

    第二:流程

    1:第一检查点,就是NN启动时将FSImage内容加载到内存中,通过输入输出流;

    2:初始化NN的BlockMap;等待DN的反馈信息。

    3:之后就是循环检查点,每次的检查是发生在DN启动时,当一个Datanode启动时,它会扫描本地文件系统,产生一个这些本地文件对应的所有HDFS数据块的列表,然后作为报告发送到Namenode,这个报告就是块状态报告,NN根据这个信息构造BlockInfo对象更新这个对象。

     未完待续。。。。

     http://hi.baidu.com/yumovrldlubhvxq/item/d2105ce99d19073f8d3ea88e

  • 相关阅读:
    电子辅助的个体化严密控制策略比常规方法更有效地帮助早期RA实现全面控制病情[EULAR2015_THU0122]
    超声和免疫学指标的特征能否反映RA临床缓解的表型?[EULAR2015_THU0121]
    依那西普减量维持过程中RA病人自报病情复发可能预示未来放射学进展[EULAR2015_SAT0147]
    RETRO研究: 持续缓解的RA患者的减量维持方案[EULAR2015_SAT0056]
    OPTIRRA研究: TNF拮抗剂维持期优化减量方案[EULAR2015_SAT0150]
    与时俱进的治疗策略不断提高RA无药缓解机会[EULAR2015_SAT0058]
    雷公藤多甙治疗类风湿关节炎遭质疑
    我的博客今天2岁203天了,我领取了先锋博主徽章
    MyEclipse中最常用的快捷键大全
    MyEclipse无法打开jsp文件(打开是空白的),但是可以打开java文件
  • 原文地址:https://www.cnblogs.com/miner007/p/3745332.html
Copyright © 2020-2023  润新知