首页 > HDFS > HDFS详解

HDFS详解

HDFS:(Hadoop Distributed File System),是运用MapReduce框架进行大规模分布式数据处理的高度容错性的文件系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用。HDFS是hadoop项目的一部分,可以说是Hadoop和Hbase的基石.

HDFS是一个主从(Master/Slave)的架构,一个HDFS集群是由一个名字节点(NameNode),若干数据节点(DataNode)组成。

 

HDFS架构一.HDFS节本概念介绍

  • 数据块 (block) 

HDFS默认的基本存储单位是64M的数据块,和普通文件系统相同的是,HDFS中的文件是被分成64M一块的数据块存储的。 不同于普通文件系统的是,HDFS中,如果一个文件小于一个数据块的大小,并不占用整个数据块存储空间。

  • 元数据节点(NameNode)

主要用来管理文件系统的命名空间,其将所有的文件和文件夹的元数据保存在一个文件系统树中。 这些信息也会在硬盘上保存成以下文件:命名空间镜像(namespace image)及修改日志(edit log),其还保存了一个文件包括哪些数据块,分布在哪些数据节点上。然而这些信息并不存储在硬盘上,而是在系统启动的时候从数据节点收集而成的。

  • 数据节点(DataNode)

真正存储数据的地方。客户端(client)或者元数据信息(namenode)可以向数据节点请求写入或者读出数据块。 其周期性的向元数据节点回报其存储的数据块信息。

  • 从元数据节点(Secondary NameNode)

从元数据节点并不是元数据节点出现问题的时候的备用节点,它和元数据节点负责不同的事情。 其主要功能就是周期性将元数据节点命名空间的镜像文件和修改日志文件合并,以防日志文件过大。     合并过后的命名空间镜像文件也在从元数据节点保存了一份,以防元数据节点失败的时候,可以恢复。secondarynamenode一般来说不应该和namenode在一起。

2012081314565068

Secondary NameNode主要是做Namespace image和Edit log合并的。

当客户端执行写操作,则NameNode会在edit log记录下来,并在内存中保存一份文件系统的元数据。

Namespace image(fsimage)文件是文件系统元数据的持久化检查点,不会在写操作后马上更新,因为fsimage写非常慢。

由于Edit log不断增长,在NameNode重启时,会造成长时间NameNode处于安全模式,即不可用状态,是非常不符合Hadoop的设计初衷。所以要周期性合并Edit log,但是这个工作如果由NameNode来完成,会占用大量资源,这样就出现了Secondary NameNode,它可以进行image检查点的处理工作。步骤如下:

  •  Secondary NameNode请求NameNode进行edit log的滚动(即创建一个新的edit log),将新的编辑操作记录到新生成的edit log文件;
  • 通过http get方式,读取NameNode上的fsimage和edits文件,到Secondary NameNode上;
  • 读取fsimage到内存中,即加载fsimage到内存,然后执行edits中所有操作并生成一个新的fsimage文件,即这个检查点被创建;
  • 通过http post方式,将新的fsimage文件传送到NameNode;
  • NameNode使用新的fsimage替换原来的fsimage文件,让 Secondary NameNode创建的edits替代原来的edits文件;并且更新fsimage文件的检查点时间。整个处理过程完成。

Secondary NameNode的处理,是将fsimage和edites文件周期的合并,不会造成nameNode重启时造成长时间不可访问的情况。

二. 文件目录结构

1)元数据节点

目录结构

[frankwong@Master name]$ ll
总用量 12
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 22:27 current
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 21:43 image
-rw-rw-r--. 1 frankwong frankwong    0 6月   1 22:27 in_use.lock
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 22:27 previous.checkpoint

具体信息:
[frankwong@Master name]$ cd current/
[frankwong@Master current]$ ls
edits fsimage fstime VERSION
[frankwong@Master current]$ more VERSION
#Sat Jun 01 22:32:49 CST 2013
namespaceID=2035266975
cTime=0
storageType=NAME_NODE
layoutVersion=-32

说明:

VERSION文件是java properties文件,保存了HDFS的版本号。
layoutVersion是一个负整数,保存了HDFS的持续化在硬盘上的数据结构的格式版本号。
namespaceID是文件系统的唯一标识符,是在文件系统初次格式化时生成的。
cTime此处为0
storageType表示此文件夹中保存的是元数据节点的数据结构。

2)数据节点

目录结构

[frankwong@Slave01 data]$ ll
总用量 20
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 22:27 blocksBeingWritten
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 22:27 current
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 22:27 detach
-rw-rw-r--. 1 frankwong frankwong    0 6月   1 22:27 in_use.lock
-rw-rw-r--. 1 frankwong frankwong  157 6月   1 22:27 storage
drwxrwxr-x. 2 frankwong frankwong 4096 6月   1 22:27 tmp

具体信息

[frankwong@Slave01 data]$ cd current/
[frankwong@Slave01 current]$ ls -l
总用量 16
-rw-rw-r--. 1 frankwong frankwong   4 6月   1 22:27 blk_-7914335926959921103
-rw-rw-r--. 1 frankwong frankwong  11 6月   1 22:27 blk_-7914335926959921103_1001.meta
-rw-rw-r--. 1 frankwong frankwong  97 6月   1 22:36 dncp_block_verification.log.curr
-rw-rw-r--. 1 frankwong frankwong 158 6月   1 22:27 VERSION
[frankwong@Slave01 current]$ more VERSION 
#Sat Jun 01 22:27:49 CST 2013
namespaceID=2035266975
storageID=DS-663208261-192.168.1.201-50010-1370096869111
cTime=0
storageType=DATA_NODE
layoutVersion=-32
[frankwong@Slave01 current]$

说明

blk_<id>保存的是HDFS的数据块,其中保存了具体的二进制数据。
blk_<id>.meta保存的是数据块的属性信息:版本信息,类型信息,和checksum
当一个目录中的数据块到达一定数量的时候,则创建子文件夹来保存数据块及数据块属性信息。

三.文件数据流

3.1读文件过程

文件读取流程

文件读取流程

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

3.2 写文件过程

100926154727

HDFS写文件过程

 

  • 客户端调用create()来创建文件
  • DistributedFileSystem用RPC调用元数据节点,在文件系统的命名空间中创建一个新的文件。
  • 元数据节点首先确定文件原来不存在,并且客户端有创建文件的权限,然后创建新文件。
  • DistributedFileSystem返回DFSOutputStream,客户端用于写数据。
  • 客户端开始写入数据,DFSOutputStream将数据分成块,写入data queue。
  • Data queue由Data Streamer读取,并通知元数据节点分配数据节点,用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。
  • Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
  • DFSOutputStream为发出去的数据块保存了ack queue,等待pipeline中的数据节点告知数据已经写入成功。
  • 如果数据节点在写入的过程中失败:
  • 关闭pipeline,将ack queue中的数据块放入data queue的开始。
  • 当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示,则错误节点重启后能够察觉其数据块是过时的,会被删除。
  • 失败的数据节点从pipeline中移除,另外的数据块则写入pipeline中的另外两个数据节点。
  • 元数据节点则被通知此数据块是复制块数不足,将来会再创建第三份备份。
  • 当客户端结束写入数据,则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点,并等待ack queue返回成功。最后通知元数据节点写入完毕。

链接

1.HDFS java api http://hadoop.apache.org/core/docs/current/api/

2.HDFS source code http://hadoop.apache.org/hdfs/version_control.html

分类: HDFS 标签:
  1. 2014年6月7日07:35 | #1

    写的不错,收藏了

  1. 本文目前尚无任何 trackbacks 和 pingbacks.
*