Hadoop HDFS详细知识学习(fsimage和editlog)

[color=blue][size=x-large][b]一、HDFS的基本概念[/b][/size][/color]
[size=large][b]1.1、数据块(block)[/b][/size]

[color=red][b]HDFS(Hadoop Distributed File System)默认的最基本的存储单位是64M的数据块。[/b][/color]
和普通文件系统相同的是，HDFS中的文件是被分成64M一块的数据块存储的。
不同于普通文件系统的是，HDFS中，[color=red][b]如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。[/b][/color]

[size=large][b]1.2、元数据节点(Namenode)和数据节点(datanode)[/b][/size]
[size=medium][color=blue][b]元数据节点用来管理文件系统的命名空间[/b][/color][/size]
其将所有的文件和文件夹的元数据保存在一个文件系统树中。
这些信息也会在硬盘上保存成以下文件：[b]命名空间镜像(namespace image)及修改日志(edit log)[/b]
其还保存了一个文件包括哪些数据块，分布在哪些数据节点上。[color=red][b]然而这些信息并不存储在硬盘上，而是在系统启动的时候从数据节点收集而成的。[/b][/color]

[size=large][color=red][b]数据节点(datanode)是文件系统中真正存储数据的地方。[/b][/color][/size]

客户端(client)或者元数据信息(namenode)可以向数据节点请求写入或者读出数据块。
其周期性的向元数据节点回报其存储的数据块信息。
[color=red][b]从元数据节点(secondary namenode)[/b][/color]
从元数据节点并不是元数据节点出现问题时候的备用节点，它和元数据节点负责不同的事情。
[b]其主要功能就是周期性将元数据节点的命名空间镜像文件和修改日志合并，以防日志文件过大。[/b]这点在下面会详细叙述。
合并过后的命名空间镜像文件也在从元数据节点保存了一份，以防元数据节点失败的时候，可以恢复。
[size=medium][b]1.2.1、元数据节点文件夹结构[/b][/size]

[size=medium][color=blue][b]fsimage是在磁盘[/b][/color][/size]

[size=medium][color=red][b]metadata是在内存[/b][/color][/size]

[img]http://dl2.iteye.com/upload/attachment/0123/4495/d0eea1df-1f2a-3991-b4a9-3385ee7fb9d5.png[/img]

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

namespaceID=1232737062

cTime=0

storageType=NAME_NODE

layoutVersion=-18

[size=medium][b]1.2.2、文件系统命名空间映像文件及修改日志[/b][/size]

当文件系统客户端(client)进行写操作时，首先把它记录在修改日志中(edit log)
元数据节点在内存中保存了文件系统的元数据信息。在记录了修改日志后，元数据节点则修改内存中的数据结构。

[b]每次的写操作成功之前，修改日志都会同步(sync)到文件系统。[/b]
fsimage文件，也即[b][color=red]命名空间映像文件[/color][/b]，是内存中的元数据在硬盘上的checkpoint，它是一种序列化的格式，并不能够在硬盘上直接修改。

同数据的机制相似，当元数据节点失败时，则最新checkpoint的元数据信息从fsimage加载到内存中，然后逐一重新执行修改日志中的操作。
[size=medium][color=red][b]从元数据节点就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的[/b][/color][/size]

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

[img]http://dl2.iteye.com/upload/attachment/0123/4497/4ce46583-9848-3526-8145-acb65f1b4186.jpg[/img]

元数据信息（fsimage + editslog），内存保存一份，磁盘保存一份，，，，，其他有个什么地方也要保存一份。

就如，学校图书馆里。书库，为了使得借书运转，要买多本书存库。

[color=red][b]fsimage：[/b][/color][b]元数据镜像文件，存储某一时段NameNode内存元数据信息。（文件目录树和文件数据块映射信息）[/b]

在hadoop1.*里，就是fsimage。

在hadoop2.*里，还加了后缀。

听说过镜像。 关闭时，将机器内存的信息写到磁盘，启动时，将磁盘的东西读取到内存。

[color=red][b]edits：操作日志文件[/b][/color]

比如说，上传一个文件或删除一个文件，这些操作。

[color=red][b]fstime:保存最近一次checkpoint的时间　[/b][/color]　　　　

比如说，在6月1号买的新电脑，在6月5日，做的第一次还原点，在6月18号，由于中病毒。在6月21号是做的第二次还原点。Checkpoint是保存最近的那次做还原点的数据。6月18-21日。

namenode始终在内存中保存metadata，用于处理“读请求”。[color=red][b]到有“读请求”时，namenode会首先写editlog到磁盘，即向edits（操作日志文件）中写入日志，成功返回后，才会修改内存，并且向客户端返回。[/b][/color]

形象化例子：我client提货员，向仓库管理员namenode，请求提货，在他同意同时，会将这情况写到editlog，[b]先是将editlog写到磁盘，成功后，再写到内存。[/b]

[size=medium][b]1.2.3、从元数据节点的目录结构[/b][/size]

[img]http://dl2.iteye.com/upload/attachment/0123/4501/1506ccc5-304a-3107-86ff-e6f7125bf844.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0123/4511/1092843c-ccc7-326b-8e99-7b666c23c873.png[/img]

[size=medium][b]1.2.4、数据节点的目录结构[/b][/size]

[img]http://dl2.iteye.com/upload/attachment/0123/4503/8f7afa16-1200-3abf-8d5d-341cb30b950a.png[/img]

[b]数据节点的VERSION文件格式如下：[/b]

namespaceID=1232737062

storageID=DS-1640411682-127.0.1.1-50010-1254997319480

cTime=0

storageType=DATA_NODE

layoutVersion=-18

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

[size=x-large][b]二、数据流(data flow)[/b][/size]
[size=large][b]2.1 读文件的过程[/b][/size]

客户端(client)用FileSystem的open()函数打开文件
DistributedFileSystem用RPC调用元数据节点，得到文件的数据块信息。
[b]对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。[/b]
DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。

客户端调用stream的read()函数开始读取数据。
[b]DFSInputStream连接保存此文件第一个数据块的最近的数据节点。[/b]
Data从数据节点读到客户端(client)
当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。
当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。
在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。
失败的数据节点将被记录，以后不再连接。

[img]http://dl2.iteye.com/upload/attachment/0123/4505/d7bc638d-d31c-3550-ad8d-c0cfc413e279.png[/img]

[size=large][b]2.2 写文件的过程[/b][/size]

客户端调用create()来创建文件
[b]DistributedFileSystem用RPC调用元数据节点[/b]，在文件系统的命名空间中创建一个新的文件。

元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。

DistributedFileSystem返回DFSOutputStream，客户端用于写数据。

客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。

Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。

Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。

如果数据节点在写入的过程中失败：
关闭pipeline，将ack queue中的数据块放入data queue的开始。
当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。
[color=red][b]失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。[/b][/color]
元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。
[color=red][b]当客户端结束写入数据，则调用stream的close函数。[/b][/color]此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。

转自：[url]http://www.cnblogs.com/forfuture1978/archive/2010/03/14/1685351.html[/url]