zoukankan      html  css  js  c++  java
  • NameNode机制和DataNode机制

    首先我们看一下NAMENODE:

    我们已经知道了NAMENODE作为DATANODE的管理者,其重要性不言而喻,那么NAMENODE是怎么管理数据的呢?

    首先,我们看一下上面这张图,每次客户端读写数据都要先经过NAMENODE,其实就是先查询NAMENODE中的元数据,那么问题来了,NAMENODE中的元数据究竟是存在内存中还是存在硬盘中呢?如果存在内存中,一旦断电就意味着数据的丢失;但是存在硬盘中,读写速度必然下降。下面将对其细节进行详尽的阐述。

    通过看以上这幅图,我们可以看到NAMENODE中的元数据既存在在内存中,也存在在硬盘中。我们先看一下元数据的存储细节:

    从左到右依次是存储路径,有哪些副本,每个副本在哪些主机上面存储。NAMENODE是整个文件系统的管理节点。它维护着整个文件系统的文件目录树,文件/目录的元信息和每个文件对应的数据块列表,接受用户的操作请求。

    文件包括:

    1.fsimage:元数据镜像文件,存储某一时段NAMENODE内存元数据信息。

    2.edits:操作日志文件。

    3.fstime:保存最近一次checkpoint的时间。

    现在我们回到上一幅图,

    1.NAMENODE始终在内存中保存meta.data,用于处理“读请求”。

    2.到有“写请求”到来时,NAMENODE会首先写edits到磁盘,即向edits文件中写日志,成功返回后,才会修改内存,并且向客户端返回。

    3.Hadoop会维护一个fsimage文件,也就是namenode中meta.data的镜像,但是fsimage不会随时与NAMENODE内存中的meta.data保持一致,而是每隔一段时间通过合并edits文件来更新内容。Secondary NAMENODE就是用来合并fsimage和edits文件来更新NAMENODE的meta.data的。

    这里就用到了Secondary NAMENODE,我们再来看一张图:

     

    在这张图中,我们可以看到SN的一些作用,当NN通知SN要进行checkpoint操作的时候,NN就停止向edits日志中写数据了,但是写操作又不能停止,这时候就会向一个edits.new日志文件中写数据,而SN会把fsimage和edits里面的内容下载到SN中,在SN中进行合并,说白了,就是将日志格式转化成要存储的文件格式,产生fsimage.chkpoint文件,并将它上传给NN,替换fsimage,并且重命名成fsimage,同时edits.new替换edits,并且重命名成edits。详细过程就是:

    那么什么时候checkpoint呢?有两种判别方式:

    1.fs.checkpoint.period:指定两次checkpoint的最大时间间隔,默认是3600秒。

    2.fs.checkpoint.size:规定edits文件的最大值,一旦超过这个值则强制checkpoint,不管是否达到最大时间间隔。默认大小是64M。

    两种判定方式先达到哪个判定条件,则先采用哪个。

    我们再来看一下DATANODE:

    DataNode

    提供真实文件数据的存储服务

    文件块:最基本的存储单位,对于文件内容而言,一个文件的长度大小是size,那么从文件的0偏移,按照固定的大小,顺序对文件进行划分并编号。划分好的每一块称为一个Block,默认Block的大小是128M。开始不同于普通文件系统的是HDFS中,如果一个文件小于一个数据块的大小,并不占用整个数据块存储空间。datanode与namenode保存心跳机制,当长时间未向namenode报告,则视为该datanode死机,namenode会重新备份该datanode上的数据块。

    读程图:

    1、客户端发送请求,调用DistributedFileSystem API的open方法发送请求到Namenode,获得block的位置信息,因为真正的block是存在Datanode节点上的,而namenode里存放了block位置信息的元数据。

    2、Namenode返回所有block的位置信息,并将这些信息返回给客户端。

    3、客户端拿到block的位置信息后调用FSDataInputStream API的read方法并行的读取block信息,图中4和5流程是并发的,block默认有3个副本,所以每一个block只需要从一个副本读取就可以。

    4、datanode返回给客户端。

    写流程:

    1、客户端发送请求,调用DistributedFileSystem API的create方法去请求namenode,并告诉namenode上传文件的文件名、文件大小、文件拥有者。

    2、namenode根据以上信息算出文件需要切成多少块block,以及block要存放在哪个datanode上,并将这些信息返回给客户端。

    3、客户端调用FSDataInputStream API的write方法首先将其中一个block写在datanode上,每一个block默认都有3个副本,并不是由客户端分别往3个datanode上写3份,而是由

         已经上传了block的datanode产生新的线程,由这个namenode按照放置副本规则往其它datanode写副本,这样的优势就是快。

    4、写完后返回给客户端一个信息,然后客户端在将信息反馈给namenode。

    5、需要注意的是上传文件的拥有者就是客户端上传文件的用户名,举个例子用windows客户端上传文件,那么这个文件的拥有者就是administrator,和linux上的系统用户名不是一样的。

    补充:

    我们在文件系统写内容,其实也是先在日志中写,然后同步到内存,接着返回写入成功,内存中的内容会在达到阈值后写入到磁盘中。

    推荐这篇文章:

    深刻理解HDFS工作机制

  • 相关阅读:
    POJ 1330 Nearest Common Ancestors(LCA Tarjan算法)
    LCA 最近公共祖先 (模板)
    线段树,最大值查询位置
    带权并查集
    转负二进制
    UVA 11437 Triangle Fun
    UVA 11488 Hyper Prefix Sets (字典树)
    UVALive 3295 Counting Triangles
    POJ 2752 Seek the Name, Seek the Fame (KMP)
    UVA 11584 Partitioning by Palindromes (字符串区间dp)
  • 原文地址:https://www.cnblogs.com/DarrenChan/p/6416043.html
Copyright © 2011-2022 走看看