码迷,mamicode.com
首页 > 其他好文 > 详细

HDFS架构

时间:2019-12-27 21:40:48      阅读:93      评论:0      收藏:0      [点我收藏+]

标签:safe   sim   方法   相同   无法   字节   合成   操作日志   时机   

hdfs的设计前提和目标:

  1.认为硬件错误是常态而不是异常

  2.流式数据访问,注重批处理和高吞吐量,而不是低延迟

  3.大规模数据集

  4.一次写入多次读取的文件访问模式

  5.移动计算比移动数据更加划算

  6.异构软硬件平台间的可移植性

 

技术图片

namenode:

  作用

    1.存储文件和目录的元数据(元数据放在内存中):包含文件的block的副本个数,修改和访问的时间,访问权限,block大小以及block列表信息。

    2.以两种方法在namenode本地进行持久化

      命名空间镜像文件(fsimage)和编辑日志(edits log)

    3.fsimage文件不记录每个block所在的datanode信息,这些信息会在每次系统启动的时候从datanode重建,之后datanode会周期性的通过心跳机制向namenode报告block信息。   

datanode向namenode注册的时候发送的block列表信息:

      • 1、文件名称和路径
      • 2、文件的大小
      • 3、文件的所属关系
      • 4、文件的block块大小 128MB
      • 5、文件的副本个数 3 MR 10个副本
      • 6、文件的修改时间
      • 7、文件的访问时间
      • 8、文件的权限
      • 9、文件的block列表

blk1:0,134217728?,node1,node13,node26:blockID
blk2:134217728,134217728?,node7,node89,node1002
blk2:134217728*2,134217728?,node7,node89,node1002

 

 

    技术图片

     该目录结构在第一次格式化的时候创建

      in_use.lock文件用于NameNode锁定存储目录,这样就防止其他同时运行的NameNode实例使用相同的存储目录

      edits表示edits log日志文件,在namenode启动后,对文件系统的改动序列

      fsimage:表示文件系统元数据镜像文件,启动时对整个文件系统的快照

      NameNode在checkpoint之前首先要切换新的edits log文件,在切换时更新seen_txid的值。上次合并fsimage和editslog之后的第一个操作编号

  用户操作过程

      当文件系统客户端进行了写操作(创建或者移动了文件),这个事务首先在edits log中记录下来,namenode在内存中有文件系统的元数据,当edits log记录结束后,才更新内存中的元数据

SecondaryNamenode

  存在的意义

    edits log会随着对文件系统的操作而无限制的增长,这种情况对正在运行的namenode而言没有任何影响,如果namenode重启,则需要很长的时间执行deits log的记录来更新fsimage(元数据的镜像文件),在此期间,整个系统不可用。

  工作流程

    1.secondarynamenode请求namenode生成新的edits log文件并向其中写日志。NameNode会在所有的存储目录中更新seen_txid文件

    2SecondaryNameNode通过HTTP GET的方式从NameNode下载fsimage和edits文件到本地。

    3.secondaryNameNode将fsimage加载到自己的内存上,并根据edits log更新内存中的fsimage信息,然后将更新完毕之后的fsimage写到磁盘上

    4.SecondaryNamenode通过HTTP Put将新的fsimage文件发送到NameNode,NameNode将该文件保存为.ckpt的临时文件备用。

    5.NameNode重命名该临时文件并准备使用,此时NameNode拥有一个新的fsimage文件和一个很小的edits log文件(可能不是空的,因为在SecondaryNamenode合并期间,客户端可能有读写操作),管理员也可以将NameNode置于safeMode,通过hdfs dfsadmin -saveNamespace命令来进行edits log和fsimage的合并

  SecondaryNameNode要和NameNode拥有相同的内存,对大的集群,SecondaryNameNode运行与一台专用的物理主机。

    技术图片技术图片

   更新时机:

    1.默认情况下:SecondaryNameNode每个小时进行一次checkpoint合并,由dfs.namenode.checkpoint.period设置,单位秒

    2.在不足一小时的情况下,如果edits log存储的事务达到了100 0000 个也进行一次checkpoint合并

      由dfs.namenode.checkpoint.txns设置事务数量

    3.事务数量检查默认每分钟进行一次

      由dfs.namenode.checkpoint.check.period设置,单位秒。

  存储结构

      1.目录布局和namenode完全一样

      2.如果NameNode完全坏掉,也可以快速的从secondarynamenode回复,但是有可能会丢失数据,因为在secondarynamenode复制合并数据的时候,namenode的edits文件也在运行添加新的数据。

 NameNode和SecondaryNamenode的工作机制

  NameNode中的元数据是存储在哪里的?

    首先,我们做个假设,如果存储在NameNode节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中,但是,如果只存在内存中,一旦断电,元数据丢失,这样,整个集群就无法工作了,因此产生了在磁盘中备份元数据的fsimage

    这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新fsimage,就会导致效率过低,但如果不更新,就会产生一致性的问题,一旦NameNode节点断电,就会产生数据丢失,因此,引入edits文件(只进行追加操作,效率很高),每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到edits中,这样,一旦NameNode节点断电,就可以通过fsimage和edits的合并,合成完整的元数据

    但是,如果长时间添加数据到edits中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长,因此,需要定期进行fsimage和edits文件的合并,如果这个操作由NameNode节点完成,又会效率过低,因此,引入新的节点Secondarynamenode,专门用于fsimage和edits的合并

技术图片

第一阶段:NameNode启动:

  1.第一次启动namenode格式化后,创建fsimage和edits文件,如果不是第一次启动,直接加载编辑日志文件和镜像文件到内存。

  2.NameNode记录操作日志,更新滚动日志。

  3.NameNode在内存中对元数据进行增删改。

第二阶段:Secondarynamenode工作

  1.secondarynamenode询问Namenode是否需要checkPoint,直接带回那么弄得是否检查结果

  2.secondarynamenode请求执行checkPoint

  3.NameNode滚动正在写的edits日志

  4.将滚动前的编辑日志和镜像文件拷贝到secondaryNamenode

  5.secondaryNamenode加载编辑日志和镜像文件到内存,并合并。

  6.生成新的镜像文件fsimage.chkpoint

  7.拷贝fsimage.chkpoint到NameNode

  8.NameNode将fsimage.chkpoint重新命名成fsimage

 

DataNode

  存储结构:

  技术图片

1、HDFS块数据存储于blk_前缀的文件中,包含了被存储文件原始字节数据的一部分。

2、每个block文件都有一个.meta后缀的元数据文件关联。该文件包含了一个版本和类型信息的头部,后接该block中每个部分的校验和。

3、每个block属于一个block池,每个block池有自己的存储目录,该目录名称就是该池子的ID(跟NameNode的VERSION文件中记录的block池ID一样)。

 

  副本的放置策略:

第一个副本:放置在上传文件的DN;如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点。

第二个副本:放置在于第一个副本不同的 机架的节点上。

第三个副本:与第二个副本相同机架的节点。

更多副本:随机节点

Hadoop的安全模式

工作流程

  1. 启动NameNode,NameNode加载fsimage到内存,对内存数据执行edits log日志中的事务操作。
  2. 文件系统元数据内存镜像加载完毕,进行fsimage和edits log日志的合并,并创建新的fsimage文件和一个空的edits log日志文件。
  3. NameNode等待DataNode上传block列表信息,直到副本数满足最小副本条件。
  4. 当满足了最小副本条件,再过30秒,NameNode就会退出安全模式。最小副本条件指整个文件系统中有99.9%的block达到了最小副本数(默认值是1,可设置)


在NameNode安全模式(safemode)

  1. 对文件系统元数据进行只读操作
  2. 当文件的所有block信息具备的情况下,对文件进行只读操作
  3. 不允许进行文件修改(写,删除或重命名文件)

HDFS架构

标签:safe   sim   方法   相同   无法   字节   合成   操作日志   时机   

原文地址:https://www.cnblogs.com/hhz-97/p/12109632.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!