hadoop-hdfs整体结构剖析

这篇文章,大约在2011年在原来的博客中写的。今天突然看到再写到这篇文章中,就当日记啦。

 

一:Hadoop整体模块交互

      分布式文件系统,思想是,把数据放到一个服务器集群上面,分为:主控服务器Master/NameNode),数据服务器(ChunkServer/DataNode),和客户服务器Client.HDFS和GFS都是按照这个架构模式搭建的。

      最核心内容是:文件的目录结构独立存储在一个NameNode上,而具体文件数据,拆分成若干块,冗余的存放在不同的数据服务器上(DateNode)。存储目录结构的主控服务器,在GFS中称为Master,在HDFS中称为NameNode。

基本模块的交互图:

 

 

二:Hadoop的HDFS

        HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是一个中心服务器,负责管理文件系统的namespace和客户端对文件的访问。一个文件其实分成一个或多个block,这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作,例如打开、关闭、重命名文件和目录,同时决定block到具体Datanode节点的映射。

一张书中典型的视图

1.文件namespace       

       Datanode在Namenode的指挥下进行block的创建、删除和复制,Datanode在集群中一般是一个节点一个。文件的块可以分别存储在不同的datanode中。

HDFS不支持user quotas和访问权限,也不支持链接(link),不过当前的架构并不排除实现这些特性。           Namenode维护文件系统的namespace,任何对文件系统namespace和文件属性的修改都将被Namenode记录下来。应用可以设置HDFS保存的文件的副本数目,文件副本的数目称为文件的 replication因子,这个信息也是由Namenode保存。

2.数据复制

       HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block序列,除了最后一个block,所有的block都是同样的大小。文件的所有block为了容错都会被复制(也就是文件分块存储后,每块都会有备份)。每个文件的block大小和replication因子都是可配置的。Replication因子可以在文件创建的时候配置,以后也可以改变。

       HDFS中的文件是write-one,并且严格要求在任何时候只有一个writer。Namenode全权管理block的复制,它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。心跳包的接收表示该Datanode节点正常工作,而Blockreport包括了该Datanode上所有的block组成的列表。

3.文件系统命名空间映像文件及修改日志

  •  当文件系统客户端(client)进行写操作时,首先把它记录在修改日志中(edit log) 
  • 元数据节点在内存中保存了文件系统的元数据信息。在记录了修改日志后,元数据节点则修改内存中的数据结构。 
  • 每次的写操作成功之前,修改日志都会同步(sync)到文件系统。 
  • fsimage文件,也即命名空间映像文件,是内存中的元数据在硬盘上的checkpoint,它是一种序列化的格式,并不能够在硬盘上直接修改。 
  • 同数据的机制相似,当元数据节点失败时,则最新checkpoint的元数据信息从fsimage加载到内存中,然后逐一重新执行修改日志中的操作。 
  • 从元数据节点就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的 
  • checkpoint的过程如下: 

             1.从元数据节点通知元数据节点生成新的日志文件,以后的日志都写到新的日志文件中。 

             2.从元数据节点用http get从元数据节点获得fsimage文件及旧的日志文件。 

             3.从元数据节点将fsimage文件加载到内存中,并执行日志文件中的操作,然后生成新的fsimage文件。 

             4.从元数据节点奖新的fsimage文件用http post传回元数据节点 。

             5.元数据节点可以将旧的fsimage文件及旧的日志文件,换为新的fsimage文件和新的日志文件(第一步生成的),然后更新fstime文件,写入此次checkpoint的时间。 

             6.这样元数据节点中的fsimage文件保存了最新的checkpoint的元数据信息,日志文件也重新开始,不会变的很大了。


 

4.数据流(data flow)

 4.1、读文件的过程

  • 客户端(client)用FileSystem的open()函数打开文件 
  • DistributedFileSystem用RPC调用元数据节点,得到文件的数据块信息。 
  • 对于每一个数据块,元数据节点返回保存数据块的数据节点的地址。 
  • DistributedFileSystem返回FSDataInputStream给客户端,用来读取数据。 
  • 客户端调用stream的read()函数开始读取数据。 
  • DFSInputStream连接保存此文件第一个数据块的最近的数据节点。 
  • Data从数据节点读到客户端(client) 
  • 当此数据块读取完毕时,DFSInputStream关闭和此数据节点的连接,然后连接此文件下一个数据块的最近的数据节点。 
  • 当客户端读取完毕数据的时候,调用FSDataInputStream的close函数。 
  • 在读取数据的过程中,如果客户端在与数据节点通信出现错误,则尝试连接包含此数据块的下一个数据节点。 
  • 失败的数据节点将被记录,以后不再连接。 


  4.2写文件的过程

  • 客户端调用create()来创建文件 
  • DistributedFileSystem用RPC调用元数据节点,在文件系统的命名空间中创建一个新的文件。 
  • 元数据节点首先确定文件原来不存在,并且客户端有创建文件的权限,然后创建新文件。 
  • DistributedFileSystem返回DFSOutputStream,客户端用于写数据。 
  • 客户端开始写入数据,DFSOutputStream将数据分成块,写入data queue。 
  • Data queue由Data Streamer读取,并通知元数据节点分配数据节点,用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。 
  • Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。 
  • DFSOutputStream为发出去的数据块保存了ack queue,等待pipeline中的数据节点告知数据已经写入成功。 
  • 如果数据节点在写入的过程中失败: 

             1.关闭pipeline,将ack queue中的数据块放入data queue的开始。 

                 2.当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示,则错误节点重启后能够察觉其数据块是过时的,会被删除。 

                 3.失败的数据节点从pipeline中移除,另外的数据块则写入pipeline中的另外两个数据节点。 

                 4.元数据节点则被通知此数据块是复制块数不足,将来会再创建第三份备份。 

当客户端结束写入数据,则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点,并等待ack queue返回成功。最后通知元数据节点写入完毕。

猜你喜欢

转载自dengqsintyt.iteye.com/blog/2080342