精华内容
下载资源
问答
  • HDFS文件目录结构详解

    千次阅读 2018-09-26 10:15:02
    HDFS metadata以树状结构存储...本文基于Hadoop2.6版本介绍HDFS Namenode本地目录的存储结构和Datanode数据块存储目录结构,也就是hdfs-site.xml中配置的dfs.namenode.name.dir和dfs.datanode.data.dir。   一、...

    HDFS metadata以树状结构存储整个HDFS上的文件和目录,以及相应的权限、配额和副本因子(replication factor)等。本文基于Hadoop2.6版本介绍HDFS Namenode本地目录的存储结构和Datanode数据块存储目录结构,也就是hdfs-site.xml中配置的dfs.namenode.name.dir和dfs.datanode.data.dir。

     

    一、NameNode

    HDFS metadata主要存储两种类型的文件

    1、fsimage

    记录某一永久性检查点(Checkpoint)时整个HDFS的元信息

    2、edits

    所有对HDFS的写操作都会记录在此文件中

     

    Checkpoint介绍

    HDFS会定期(dfs.namenode.checkpoint.period,默认3600秒)的对最近的fsimage和一批新edits文件进行Checkpoint(也可以手工命令方式),Checkpoint发生后会将前一次Checkpoint后的所有edits文件合并到新的fsimage中,HDFS会保存最近两次checkpoint的fsimage。Namenode启动时会把最新的fsimage加载到内存中。

     

    下面是一个标准的dfs.namenode.name.dir目录结构,注意edits和fsimage也可以通过配置放到不同目录中

    ├── current
    │ ├── VERSION
    │ ├── edits_0000000000000000001-0000000000000000007
    │ ├── edits_0000000000000000008-0000000000000000015
    │ ├── edits_0000000000000000016-0000000000000000022
    │ ├── edits_0000000000000000023-0000000000000000029
    │ ├── edits_0000000000000000030-0000000000000000030
    │ ├── edits_0000000000000000031-0000000000000000031
    │ ├── edits_inprogress_0000000000000000032
    │ ├── fsimage_0000000000000000030
    │ ├── fsimage_0000000000000000030.md5
    │ ├── fsimage_0000000000000000031
    │ ├── fsimage_0000000000000000031.md5
    │ └── seen_txid
    └── in_use.lock
    
    1、VERSION
    #Thu May 19 10:13:22 CST 2016
    namespaceID=1242163293
    clusterID=CID-124668a8-9b25-4ca7-97bf-5dd5c25041a9
    cTime=1455091012961
    storageType=NAME_NODE
    blockpoolID=BP-180412957-192.168.1.8-1419305031110
    layoutVersion=-60
    
     
    • layoutVersion - HDFS metadata版本号,通常只有HDFS增加新特性时才会更新这个版本号
    • namespaceID/clusterID/blockpoolID - 这三个ID在整个HDFS集群全局唯一,作用是引导Datanode加入同一个集群。在HDFS Federation机制下,会有多个Namenode,所以不同Namenode直接namespaceID是不同的,分别管理一组blockpoolID,但是整个集群中,clusterID是唯一的,每次format namenode会生成一个新的,也可以使用-clusterid手工指定ID
    • storageType - 有两种取值NAME_NODE /JOURNAL_NODE,对于JournalNode的参数dfs.journalnode.edits.dir,其下的VERSION文件显示的是JOURNAL_NODE
    • cTime - HDFS创建时间,在升级后会更新该值

     

    2、edits_start transaction ID-end transaction ID

    finalized edit log segments,在HA环境中,Standby Namenode只能读取finalized log segments,

    3、edits_inprogress__start transaction ID

    当前正在被追加的edit log,HDFS默认会为该文件提前申请1MB空间以提升性能

    4、fsimage_end transaction ID

    每次checkpoing(合并所有edits到一个fsimage的过程)产生的最终的fsimage,同时会生成一个.md5的文件用来对文件做完整性校验

    5、seen_txid

    保存最近一次fsimage或者edits_inprogress的transaction ID。需要注意的是,这并不是Namenode当前最新的transaction ID,该文件只有在checkpoing(merge of edits into a fsimage)或者edit log roll(finalization of current edits_inprogress and creation of a new one)时才会被更新。

    这个文件的目的在于判断在Namenode启动过程中是否有丢失的edits,由于edits和fsimage可以配置在不同目录,如果edits目录被意外删除了,最近一次checkpoint后的所有edits也就丢失了,导致Namenode状态并不是最新的,为了防止这种情况发生,Namenode启动时会检查seen_txid,如果无法加载到最新的transactions,Namenode进程将不会完成启动以保护数据一致性。

    6、in_use.lock

    防止一台机器同时启动多个Namenode进程导致目录数据不一致
     

    二、Datanode

    Datanode主要存储数据,下面是一个标准的dfs.datanode.data.dir目录结构

    ├── current
    │ ├── BP-1079595417-192.168.2.45-1412613236271
    │ │ ├── current
    │ │ │ ├── VERSION
    │ │ │ ├── finalized
    │ │ │ │ └── subdir0
    │ │ │ │ └── subdir1
    │ │ │ │ ├── blk_1073741825
    │ │ │ │ └── blk_1073741825_1001.meta
    │ │ │ │── lazyPersist
    │ │ │ └── rbw
    │ │ ├── dncp_block_verification.log.curr
    │ │ ├── dncp_block_verification.log.prev
    │ │ └── tmp
    │ └── VERSION
    └── in_use.lock
    


    1、BP-random integer-NameNode-IP address-creation time

    BP代表BlockPool的意思,就是上面Namenode的VERSION中的集群唯一blockpoolID,如果是Federation HDFS,则该目录下有两个BP开头的目录,IP部分和时间戳代表创建该BP的NameNode的IP地址和创建时间戳

    2、VERSION 

    与Namenode类似,其中storageType是DATA_NODE

    #Wed Feb 10 16:00:18 CST 2016
    storageID=DS-2e165f84-68b1-40c9-b501-b6b08fcb09ee
    clusterID=CID-124668a8-9b25-4ca7-97bf-5dd5c25041a9
    cTime=0
    datanodeUuid=cb9fead7-cd64-4507-affd-c06f083708b5
    storageType=DATA_NODE
    layoutVersion=-56
    

     

    3、finalized/rbw目录

    这两个目录都是用于实际存储HDFS BLOCK的数据,里面包含许多block_xx文件以及相应的.meta文件,.meta文件包含了checksum信息。

    rbw是“replica being written”的意思,该目录用于存储用户当前正在写入的数据。

    4、dncp_block_verification.log

    该文件用于追踪每个block最后修改后的checksum值,该文件会定期滚动,滚动后会移到.prev文件

    5、in_use.lock

    防止一台机器同时启动多个Datanode进程导致目录数据不一致

     

    --------------------- 本文来自 opensure 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/opensure/article/details/51452058?utm_source=copy

    展开全文
  • HDFS的存储结构以及写入、读取hdfs数据操作流程简单总结.pdf
  • HDFS结构

    2017-05-03 22:02:07
    1、HDFS结构 hdfs的采用的是master/slave模型,一个hdfs cluster包含一个NameNode若干的DataNode,NameNode是master。 NameNode主要负责管理hdfs文件系统,掌握着整个HDFS的文件目录树及其目录与文件,...

    1、HDFS结构

    hdfs的采用的是master/slave模型,一个hdfs cluster包含一个NameNode和若干的DataNode,NameNode是master。

    NameNode主要负责管理hdfs文件系统,掌握着整个HDFS的文件目录树及其目录与文件,这些信息会以文件的形式永久地存储在本地磁盘。具体地包括namespace管理(其实就是目录结构)block管理(其中包括 filename->block,block->ddatanode list的对应关系)NameNode提供的是始终被动接收服务的server,主要有三类协议接口:ClientProtocol接口、DatanodeProtocol接口、NamenodeProtocol接口。

    DataNode主要是用来存储数据文件,hdfs将一个文件分割成一个个的block,这些block可能存储在一个DataNode上或者是多个DataNode上。dn负责实际的底层的文件的读写,如果客户端client程序发起了读hdfs上的文件的命令,那么首先将这些文件分成block,然后DataNode将告知client这些block数据是存储在哪些DataNode上的,之后,client将直接和DataNode交互。

    2、FSNamesystem

    NameNode的核心是FSNamesysem

    FSNamesystem持有几大主要数据结构:FSDirectory维护系统目录结构、BlocksMap维护数据块信息、LeaseManagr维护租约信息;此外,还通过DatandeDescriptor、corruptReplicas等维护数据结点(DN)状态、坏副本等信息;

    FSNamesystem内部维护多个数据结构之间的关系:

    1. fsname->block列表的映射
    2. 所有有效blocks集合
    3. block与其所属的datanodes之间的映射(该映射是通过block reports动态构建的,维护在namenode的内存中。每个datanode在启动时向namenode报告其自身node上的block)
    4. 每个datanode与其上的blocklist的映射
    5. 采用心跳检测根据LRU算法更新的机器(datanode)列表

      FSNamesystem体系结构

    2.1、FSDirectory

    FSDirectory用于维护当前系统中的文件树,存储整个文件系统的目录状态FSDirectory通过FSImage及FSEditLog保存目录结构的某一时刻镜像及对镜像的修改(从namenode本地磁盘读取元数据信息和向本地磁盘写入元数据信息,并登记对目录结构所作的修改到日志文件);另外,FSDirectory保存了文件名和数据块的映射关系。

    我们可以在$HADOOP_HOME/tmp/dfs/name/current下找到这些文件:fsimage以及edits。

    fsimage:保存了最新的元数据检查点;
    edits:保存了HDFS中自最新的元数据检查点后的命名空间变化记录;

    为了防止edits中保存的最新变更记录过大,HDFS会定期合并fsimage和edits文件形成新的fsimage文件,然后重新记录edits文件。由于NameNode存在单点问题(Hadoop2.0以前版本),因此为了减少NameNode的压力,HDFS把fsimage和edits的合并的工作放到SecondaryNameNode上,然后将合并后的文件返回给NameNode。但是,这也会造成一个新的问题,当NameNode宕机,那么NameNode中edits的记录就会丢失。也就是说,NameNode中的命名空间信息有可能发生丢失。

    2.2、FsImage

    在fsimage中,并没有记录每一个block对应到哪几个datanodes的对应表信息,而只是存储了所有的关于namespace的相关信息。

    FSImage用于持久化文件树的变更以及系统启动时加载持久化数据。 HDFS启动时通过FSImage来加载磁盘中原有的文件树,系统Standby之后,通过FSEditlog来保存在文件树上的修改,FSEditLog定期将保存的修改信息刷到FSImage中进行持久化存储。

    Fsimage是一个二进制文件,它记录了HDFS中所有文件和目录的元数据信息。关于fsimage的内部结构我们可以参看下图:
    fsimage
    第一行是文件系统元数据,第二行是目录的元数据信息,第三行是文件的元数据信息。namespaceID:当前命名空间的ID,在NameNode的生命周期内保持不变,DataNode注册时,返回该ID作为其registrationID,每次和NameNode通信时都要检查,不认识的namespaceID拒绝连接;path的length为0,即表示这个目录为根目录。

    NameNode将这些信息读入内存之后,构造一个文件目录结构树,将表示文件或目录的节点填入到结构中。

    NameNode加载fsimage完成之后,BlocksMap中只有每个block到其所属的datanodes list的对应关系信息还没建立。然后通过dn的blockReport来收集构建。当所有的DataNode汇报给NameNode的blockReport处理完毕后,BlocksMap整个结构也就构建完成了。

    GFS 在 Master 上存储的文件结构是采用命名空间的方式,没有目录内存储的文件列表结构,没有链接或别名机制,每一个命名空间的映射条目都是采用文件的绝对路径存储,并且采用前缀压缩技术(Prefix compression)进行压缩存储。这样可以更高效地进行文件的定位和访问。


    2.3、BlocksMap

    namenode中是通过block->datanode list的方式来维护一个block的副本是保存在哪几个datanodes上的对应关系的。

    2.3.1、版本一

    从以上fsimage中加载如namenode内存中的信息中可以很明显的看出,在fsimage中,并没有记录每一个block对应到哪几个datanodes的对应表信息,而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储,而是在所有datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenode,namenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport,而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。
    BlocksMap的内部数据结构如下:
     
    如上图显示,BlocksMap实际上就是一个Block对象对BlockInfo对象的一个Map表,其中Block对象中只记录了blockid,block大小以及时间戳信息,这些信息在fsimage中都有记录。而BlockInfo是从Block对象继承而来,因此除了Block对象中保存的信息外, 还包括代表该block所属的HDFS文件的INodeFile对象引用以及该block所属datanodes列表的信息(即上图中的DN1,DN2,DN3,该数据结构会在下文详述)。

     BlockInfo中datanode列表数据结构
    在BlockInfo中,将该block所属的datanodes列表保存在一个Object[]数组中,但该数组不仅仅保存了datanodes列表,还包含了额外的信息。实际上该数组保存了如下信息:
     
    上图表示一个block包含有三个副本,分别放置在DN1,DN2和DN3三个datanode上,每个datanode对应一个三元组,该三元组中的第二个元素,即上图中prev block所指的是该block在该datanode上的前一个BlockInfo引用。第三个元素,也就是上图中next Block所指的是该block在该datanode上的下一个BlockInfo引用。每个block有多少个副本,其对应的BlockInfo对象中就会有多少个这种三元组。

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


    2.3.2、版本二

    block->datanode的信息没有持久化存储,而是namenode通过datanode的blockreport获取block->datanode list

    BlocksMap负责维护了三种信息(维护Block -> { INode, datanodes, self ref } 的映射 )

      block->datanode list

      block->INodeFile

      datanode->blocks

    这要归功于Object[] triplets结构:

    他是一个三元组,每个block有几个副本,就有几个三元组。

    三元组的第一个元素表示该block所属的Datanode,类型是DatanodeDescriptor,通过它获得block->datanode list

    第二/三个元素表示该block所在Datanode上的前/后一个block(前驱和后继),类型是BlockInfo,通过它获得datanode->blocks

    借助这个三元组可以找到一个block所属的所有datanode,也可以通过三元组的后两个元素信息找到一个datanode上所有的block。


    2.3.3、版本三

    BlocksMap是NameNode保存block对象的容器。所有的Block对象被封装成BlockInfo对象,BlockInfo对象组织成HashMap进行存储;

    BlockInfo对象使用多个(与复本个数相同)三元组(triplets)保存每个block复本的位置信息;

    三元组中第一个位元指向相应复本所在的DataNode;如图中虚线所示;第二个位元指向相同DataNode中前一个Block;第三个位元指向相同DataNode中后一个Block;如图中实现所示,从一个DatanodeDescriptor开始,通过一个双向链表,可以找到该DataNode上所有的Block;

    BlocksMap结构比较简单,实际上就是一个Block到BlockInfo的映射。

    Block

    Block是HDFS中的基本读写单元,主要包括:

    1. blockId: 一个long类型的块id
    2. numBytes: 块大小
    3. generationStamp: 块更新的时间戳

    BlockInfo

    BlockInfo扩展自Block,除基本信息外还包括一个inode引用,表示该block所属的文件;以及一个神奇的三元组数组Object[] triplets,用来表示保存该block的datanode信息,假设系统中的备份数量为3。那么这个数组结构如下:

    triplets

    1. DN1,DN2,DN3分别表示存有改block的三个datanode的引用(DataNodeDescriptor)
    2. DN1-prev-blk表示在DN1上block列表中当前block的前置block引用
    3. DN1-next-blk表示在DN1上block列表中当前block的后置block引用

    DN2,DN3的prev-blk和next-blk类似。 HDFS采用这种结构存放block->datanode list的信息主要是为了节省内存空间,block->datanodelist之间的映射关系需要占用大量内存,如果同样还要将datanode->blockslist的信息保存在内存中,同样要占用大量内存。采用三元组这种方式能够从其中一个block获得到该block所属的datanode上的所有block列表。

    Conclusion

    通过fsimage与blocksmap两种数据结构,NameNode就能建立起完整的命名空间信息以及文件块映射信息。在NameNode加载fsimage之后,BlocksMap中只有每个block到其所属的DataNode列表的对应关系信息还没建立,这个需要通过DataNode的blockReport来收集构建,当所有的DataNode上报给NameNode的blockReport处理完毕后,BlocksMap整个结构也就构建完成。


    HDFS文件系统命名空间

    http://www.aboutyun.com/thread-7388-1-1.html

    https://github.com/leotse90/SparkNotes/blob/master/HDFS%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4.md#hdfs文件系统命名空间

    http://blog.csdn.NET/liuaigui/article/details/5993604

    GFS uses a B-tree to map namespace to metadata; no directory nodes; 100 bytes per file

    哈希表

    http://origin.redisbook.com/datatype/hash.html


    展开全文
  • HDFS采用主从(Master/Slave)结构模型,一个HDFS集群是由一个NameNode若干个DataNode组成的(在最新的Hadoop2.2版本已经实现多个NameNode的配置-这也是一些大公司通过修改hadoop源代码实现的功能,在最新的版本中...

    HDFS的体系架构

    整个Hadoop的体系结构主要是通过HDFS来实现对分布式存储的底层支持,并通过MR来实现对分布式并行任务处理的程序支持。

    HDFS采用主从(Master/Slave)结构模型,一个HDFS集群是由一个NameNode和若干个DataNode组成的(在最新的Hadoop2.2版本已经实现多个NameNode的配置-这也是一些大公司通过修改hadoop源代码实现的功能,在最新的版本中就已经实现了)。NameNode作为主服务器,管理文件系统命名空间和客户端对文件的访问操作。DataNode管理存储的数据。HDFS支持文件形式的数据。

    从内部来看,文件被分成若干个数据块,这若干个数据块存放在一组DataNode上。NameNode执行文件系统的命名空间,如打开、关闭、重命名文件或目录等,也负责数据块到具体DataNode的映射。DataNode负责处理文件系统客户端的文件读写,并在NameNode的统一调度下进行数据库的创建、删除和复制工作。NameNode是所有HDFS元数据的管理者,用户数据永远不会经过NameNode。

    这里写图片描述
    如图:HDFS体系结构图

    图中涉及三个角色:NameNode、DataNode、Client。NameNode是管理者,DataNode是文件存储者、Client是需要获取分布式文件系统的应用程序。

    文件写入:

    1) Client向NameNode发起文件写入的请求。

    2) NameNode根据文件大小和文件块配置情况,返回给Client它管理的DataNode的信息。

    3) Client将文件划分为多个block,根据DataNode的地址,按顺序将block写入DataNode块中。

    文件读取:

    1) Client向NameNode发起读取文件的请求。

    2) NameNode返回文件存储的DataNode信息。

    3) Client读取文件信息。

    HDFS作为分布式文件系统在数据管理方面可借鉴点:

    文件块的放置:一个Block会有三份备份,一份在NameNode指定的DateNode上,一份放在与指定的DataNode不在同一台机器的DataNode上,一根在于指定的DataNode在同一Rack上的DataNode上。备份的目的是为了数据安全,采用这种方式是为了考虑到同一Rack失败的情况,以及不同数据拷贝带来的性能的问题。

    展开全文
  • HDFS 体系结构详解

    千次阅读 2014-09-11 14:00:47
    hdfs体系结构详解

    Hdfs体系结构:三个进程(namenode,datanode, secondary namenode)

     

    Hdfs(hadoopdistributed filesystem)是hadoop的核心子项目,是分布式存储,它是基于流数据模式的访问和处理超大文件。(分布式最大的好处就是其通透性,虽然分布存在不同的datanode上面,但是感觉在一台电脑的本地进行操作)。

    Tips

    Hdfs的高可用性主要取决于namenode,间接取决于元数据的可靠性和namenode的服务回复时间。

     

    磁盘元数据文件,所有的元数据文件是将存放在内存之中的,一旦断电,内存中的数据将会全部消失,所以需要将数据存放在磁盘上面 永久保存。

     

    磁盘员数据文件包含:

     

    fsimage 元数据镜像文件,存储的是某一时刻的namenode内存元数据信息。

    edits:日志文件 包含了该时刻以后的元数据操作记录。

    fstime:保存了最近的checkpoint的时间

    VERSION:标志性文件,代表前面三个文件成功创建。

     

    Namenode(进程):元数据节点,用来管理文件系统的命名空间,维护目录树,接管用户的请求。

    (1)    将文件的元数据保存在一个文件目录树中

    (2)    在磁盘上保存为:fsimage 和 edits

    (3)    保存datanode的数据信息的文件,在系统启动的时候读入内存。

    下面看下hdfs配置文件源码分析,里面的内容立即显现:

    hdfs-default.xml:


    首先这个文件不可以修改的,若是想修改某些属性,拷贝实体到hdfs-site.xml文件中进行配置,这也是开始安装hadoop的配置文件中的一些<configuration>

     

    下面namenode存储的元数据信息的配置

     

    这个property中包含一个:


    ${hadoop.tmp.dir}是基于core-default.xml文件配置的:

     

    ${user.name}安装hadoop的用户名字。

     

    基于在本地文件系统之上的分布式文件系统的name node 是存储 名字表的,保存为fsimage文件,为了冗余(备份,安全性)可以用逗号(,)分隔目录列表。

    例如:

    逗号之间什么都不允许添加,否则将会不识别。

     

    cd ${hadoop.tmp.dir}(自己定义的目录)/dfs/name

    ls 出现


    其中有个in_use.lock 文件,表明已有进程执行(lock住了,即namenode进程)。

    cd current/

    ls 出现:


    正好满足 fsimage(镜像文件namenode的核心数据文件),edits文件的存在。

    如果namenode 失效 将无法恢复 datanode。

     

    Edits


    edits:transaction file (事物文件),为了保存数据的一致性,写入数据的过程需要先写入edits中,edits保存操作的过程,当过程结束时,edits是知道的,但fsimage不清楚,只有操作成功了,才会通知fsimage。此时,要将edits数据操作成功的报告告诉给fsimage,需要通过的进程就是 secondarynamenode,所以secondarynamenode的主要作用就是合并fsiamgeedits的,形成新的fsimage在本地保存,在发送给namenode,同时重置namenode的edits。Namenode之所以不进行合并,而应用secondarynamenode来操作,主要就是namenode需要快速接管用户的请求,需要快速响应。所以fsimage文件保存了一份在secondarynamenode中,所以当namenode的数据丢失的情况,可以进行secondarynamenode恢复,但是可能会丢失一部分数据,就是没有来得及合并的fsimage和edits,即备份数据不是实时的,是冷备份。

    Tips:

    fsimage:是内存的元数据在硬盘上的checkpoint,更新fsimage文件需要有个checkpoin过程:

    • 从元数据节点通知元数据节点生成新的日志文件,以后的日志都写到新的日志文件中。
    • 从元数据节点用http get从元数据节点获得fsimage文件及旧的日志文件。
    • 从元数据节点将fsimage文件加载到内存中,并执行日志文件中的操作,然后生成新的fsimage文件。
    • 从元数据节点奖新的fsimage文件用http post传回元数据节点
    • 元数据节点可以将旧的fsimage文件及旧的日志文件,换为新的fsimage文件和新的日志文件(第一步生成的),然后更新fstime文件,写入此次checkpoint的时间。
    • 这样元数据节点中的fsimage文件保存了最新的checkpoint的元数据信息,日志文件也重新开始,不会变的很大了。


    此外:


    这个作用和上面的一致,多备份几个文件,需要用逗号分隔(,)。

     

    DataNode的进程:主要就是存储真实数据。

    需要存储(上传)数据时,需要先报告给namenode,namenode找到空闲的datanode,才可以进行操作。

    Datanode存储数据的时候,是以block为单位进行,默认大小64MB.


    在hdfs-default.xml文件中,如果用户根据自己的实际情况,需要修改默认的block的大小,如果修改为128MB,256MB的时候,需要注意的是(修改将在hdfs-site.xml文件中进行),同上。

     

    流式数据,将待存储的数据划分为多个block,namenode将block放到不同的datanode中,但是不同于操作系统的切分单位(簇),若是文件大小小于默认大小,并不会按照默认大小来存储,而是按照实际的大小来存储,此外需要注意

    若是上亿(虚拟量)的数量是小文件来存储,此时可以进行,但是效率不高,造成namenode的压力过大,解决:可以将小文件合并处理,将会很有效果,所以也印证了hdfs对于海量小文件的存储,效果并不是很好。

     

    源码datanode的配置:


    由名字可见,datanode进程是:dfs.data.dir 而namenode进程是:dfs.name.dir

     

    解释是:datanode存储block的地方。

    当 cd${hadoop.tmp.dir}(自己定义的目录)/dfs/data 

    ls 出现


    在进入 cd current | ls 出现:


    由图可知:block是成对出现的

    由于上传数据的时候,会被分块,破坏,此时.meta文件主要类似是校验数据的作用,类似于(MD5)。

     

    当上传文件的时候,在datanode的路径中去查看切分好的数据block。

    例如:hadoop fs –put /

    查询blocks:cd ${hadoop.data.dir}(自己定义)/dfs/data/current

    ll:

     

    但是发现,上传之后是在linux文件系统上面,是否可以通过手动拷贝传递?No手动上传hdfs是不承认的(通过 hadoopfs –ls 是查看不到的),原因是namenode并不清楚是否上传。

    展开全文
  • HDFS体系结构.pdf

    2021-09-14 11:35:14
    HDFS体系结构.pdf
  • HDFS体系结构

    千次阅读 2016-08-12 11:37:32
    Namenode 是整个文件系统的管理节点。它维护着整个文件系统的文件目录树,文件/目录的元信息... hdfs-default.xml的dfs.namenode.name.dir 属性(hadoop-hdfs-2.7.2.jar / hdfs-default.xml) dfs.namenode.name.d
  • HDFS结构体系核心流程分析

    千次阅读 2020-01-18 20:42:51
    关于hadoop生态体系中HDFS结构和核心流程的介绍。
  • 了解了HDFS体系结构中的名字节点、数据节点客户端以后,我们来分析HDFS实现的源代码结构HDFS源代码都在org.apache.hadoop.hdfs包下,其结构如图6-3所示。 HDFS的源代码分布在I6个目录下,它们可以分为如下...
  • HDFS体系结构解析.pptx

    2021-05-17 23:11:39
    HDFS体系结构解析
  • HDFS文件系统结构解析

    千次阅读 2013-01-24 09:14:22
     NameNode节点是就是HDFS的大脑。想了解HDFS文件系统,必须了解大脑结构。 咱们就从NameNode节点开始。NameNode类中,关于HDFS文件系统的存储管理都交给了FSNamesystem负责。下面介绍一下FSNamesystem的逻辑组成
  • Hadoop HDFS 体系结构

    2020-04-14 17:53:20
    Hadoop HDFS 体系结构简介体系结构相关概念读写流程客户端命令 简介 HDFS(Hadoop Distributed File System) Hadoop分布式文件系统,Hadoop体系底层的数据存储组件;最开始是作为Apache Nutch web搜索引擎项目的基础...
  • HDFS源代码结构  HDFS的源代码都在org.apche.hadoop.hdfs包下。HDFS的源代码分布16个目录下,它们可以分为如下四类。  1、基础包  包括工具安全包。其中,hdfs.util包含了一些HDFS实现需要的辅助数据结构;...
  • HDFS体系结构简介

    千次阅读 2015-02-16 20:19:43
    HDFS体系结构简介     1、HDFS设计基础与目标:  1.1、硬件错误是常态。因此需要冗余 1.2、流式数据访问。即数据批量读取而非随机读写,Hadoop擅长做的是数据分析而不是事 务处理  1.3、大规模数据集  1.4、...
  • Hadoop之hdfs体系结构

    千次阅读 2020-04-27 09:44:45
    HDFS 采用的是hostname01/slaves这种主从的结构模型来管理数据,这种结构模型主要由四个部分组成,分别是Client(客户端)、Namenode(名称节点)、Datanode(数据节点)SecondaryNameNode。 真正的一个HDFS集群包括一个...
  • HDFS结构解释

    千次阅读 2013-06-12 10:51:01
    HDFS是一个典型的Client/Server架构,主要是由一个NameNode,一个secondaryNameNode,一个或多个DataNode组成。NameNode是整个文件系统的控制中枢,它管理并维护着整个文件系统树以及整个系统树中所有的文件目录,...
  • Hadoop学习日志之HDFS的主从结构

    千次阅读 2017-07-20 08:34:07
     HDFS采用了主从(Master/Slave)结构模型,一个HDFS集群是由一个NameNode若干个DataNode组成的。其中NameNode作为主服务器,管理文件系统的命名空间客 户端对文件的访问操作;集群中的DataNode管理存储的数据。...
  • 一、NameNode数据结构 1、物理结构 ${dfs.name.dir}/current/...VERSION文件是Java属性文件,包含运行HDFS的版本信息。 edits,是编辑日志文件。当客户断执行写操作的时,NameNode首先会在编辑日志中写下记录,并
  • HDFS体系结构及常见功能

    千次阅读 2018-05-05 16:05:24
    本文主要是介绍HDFS的体系结构和常用操作,涉及到的知识点如下: HDFS的体系结构 数据上传 数据下载 HDFS的体系结构 Hadoop的生态圈,包括HDFS、Yarn、HBase都是主从结构。对于HDFS来说,它的主节点是...
  • Apache Hadoop HDFS体系结构介绍:在这个博客中,我...所以,这是我们应该采取深入了解的Apache Hadoop的HDFS架构解开它的美丽的时候了。Apache Hadoop HDFS体系结构的这个博客将涉及的主题如下:HDFS主/从拓扑NameNo
  • Hadoop架构介绍——HDFS的体系结构

    万次阅读 2016-11-10 13:24:40
    设计目标: 1.自动快速检测应对硬件错误 ...HDFS体系结构 NameNode中心服务器 DataNode分布在不同的机架上 基本概念 机架:HDFS集群,由分布在多个机架上的大量DataNode组成,不同机架之间节点通过交换机通信,H
  • HDFS体系结构(NameNode、DataNode详解)
  • HDFS体系结构简介及优缺点

    千次阅读 2014-08-25 13:46:13
    1 HDFS体系结构简介及优缺点 1.1 体系结构简介  HDFS是一个z
  • Hive内部表在HDFS中的目录结构

    万次阅读 2017-04-10 14:01:20
    简要介绍了Hive内部表在HDFS的目录结构
  • HDFS 采用Master/Slave的架构来存储数据,这种架构主要由四个部分组成,分别为HDFS Client、NameNode、DataNodeSecondary NameNode。下面我们分别介绍这四个组成部分。   Client :就是客户端。  1、文件...
  • Hadoop HDFS本地存储目录结构解析

    万次阅读 多人点赞 2016-05-19 11:38:21
    HDFS metadata以树状结构存储整个HDFS上的...本文基于Hadoop2.6版本介绍HDFS Namenode本地目录的存储结构和Datanode数据块存储目录结构,也就是hdfs-site.xml中配置的dfs.namenode.name.dir和dfs.namenode.data.dir。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 84,803
精华内容 33,921
关键字:

hdfs特征和结构