Hadoop中HDFS的存储机制

1、Hadoop中HDFS的存储机制HDFS （Hadoop Distributed File System）是Hadoop分布式计算中的数据存储系统， 是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础概念，然后介绍HDFS中读写操作的过程，最后分析了 HDFS的优缺点。1. HDFS中的基础概念i=Block： HDFS中的存储单元是每个数据块block，HDFS默认的最基本的存储单位是64M的数 据块。和普通的文件系统相同的是，HDFS中的文件也是被分成64M 一块的数据块存储的。 不同的是，在HDFS中，如果一个文件大小小于一个数据块的大小，它是不需要占

2、用整个数 据块的存储空间的。NameNode：元数据节点。该节点用来管理文件系统中的命名空间，是 master。其将所有的为了见和文件夹的元数据保存在一个文件系统树中，这些信息在硬盘上 保存为了命名空间镜像（namespace image）以及修改日志（edit log），后面还会讲到。 此外，NameNode还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而，这些 信息不存放在硬盘上，而是在系统启动的时候从数据节点收集而成的oDataNode：数据节点， 是HDFS真正存储数据的地方。客户端（client）和元数据节点（NameNode）可以向数据节 点请求写入或者读出数据块。此外，

3、DataNode需要周期性的向元数据节点回报其存储的数 据块信息。Secondary NameNode:从元数据节点。从元数据节点并不是NameNode出现问题 时候的备用节点，它的主要功能是周期性的将NameNode中的namespace image和edit log 合并，以防log文件过大。此外，合并过后的namespace image文件也会在Secondary NameNode上保存一份，以防NameNode失败的时候，可以恢复。edit log：修改日志，当文 件系统客户端client进行写操作的时候，我们就要把这条记录放在修改日志中。在记录了 修改日志后，NameNode则修改内

4、存中的数据结构。每次写操作成功之前，edit log都会同 步到文件系统中。fsimage：命名空间镜像，它是内存中的元数据在硬盘上的checkpointo 当NameNode失败的时候，最新的checkpoint的元数据信息就会从fsimage加载到内存中， 然后注意重新执行修改日志中的操作。而Secondary NameNode就是用来帮助元数据节点将 内存中的元数据信息checkpoint到硬盘上的。具体checkpoint的过程如下图：（参考hadoop集群的博客）checkpoint 的过程如下：Secondary NameNode 通知 NameNode 生成新的 日志文件，以后的

5、日志都写到新的日志文件中o Secondary NameNode用http get从NameNode获得fsimage文件及旧的日志文件。Secondary NameNode 将fsimage文件加载到内存中，并执行日志文件中的操作，然后生成新的 fsimage 文件。Secondary NameNode 将新的 fsimage 文件用 http post 传回 NameNodeo NameNode可以将旧的fsimage文件及旧的日志文件，换为新的 fsimage文件和新的日志文件（第一步生成的），然后更新fstime文件，写入此次checkpoint的时间。这样NameNode中的fsim

6、age文件保存了最新的 checkpoint的元数据信息，日志文件也重新开始，不会变的很大了。从元数据节点HDFS中文件读写操作流程在HDFS中，文件的读写过程就是client和NameNode以及DataNode 一起交互的过程。 我们已经知道NameNode管理着文件系统的元数据，DataNode存储的是实际的数据，那么 client就会联系NameNode以获取文件的元数据，而真正的文件读取操作是直接和DataNode 进行交互的。写文件的过程：客户端调用create()来创建文件DistributedFileSystem用RPC调用元数据节点，在文件 系统的命名空间中创建一个新的文件。

7、元数据节点首先确定文件原来不存在，并且客户端有 创建文件的权限，然后创建新文件。DistributedFileSystem返回DFSOutputStream，客户端用于写数据。客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。 Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每 块默认复制3块)。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入 pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个 数据节点将数据发送给第三个数据节点。DF

8、SOutputStream为发出去的数据块保存了 ack queue，等待pipeline中的数据节点告知数据已经写入成功。如果数据节点在写入的过程中 失败：关闭pipeline，将ack queue中的数据块放入data queue的开始。当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够 察觉其数据块是过时的，会被删除。失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。当客户端结束写入数据，则调用stream的close函数。此操作将所有的数据块写入

9、pipeline 中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。client JVMl：reate6：演FSDwnamenodedient nodedatanodedatancdeNdineN 缺DdiaNodeDataNodePipelinedHDF5di entDistributedHleSyflem5： jck packet读取文件的过程:客户端(client)用 FileSystem 的 open()函数打开文件 DistributedFileSystem用 RPC 调用 元数据节点，得到文件的数据块信息。对于每一个数据块，元数据节点返回保存数据块的数 据

10、节点的地址。DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。 客户端调用stream的read ()函数开始读取数据DFSInputStream连接保存此文件第一个数 据块的最近的数据节点。Data从数据节点读到客户端(client)当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节 点。当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。在读取数据 的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据 节点。失败的

11、数据节点将被记录，以后不再连接。HDFS的优缺点分析优点：1）能够处理超大的文件；2）流式访问数据。HDFS能够很好的处理“一次写入，多次读写”的任务。也就是说， 一个数据集一旦生成了，就会被复制到不同的存储节点中，然后响应各种各样的数据分析任 务请求。在多数情况下，分析任务都会涉及到数据集中的大部分数据。所以，HDFS请求读 取整个数据集要比读取一条记录更加高效。3）可以运行在比较廉价的商用机器集群上。缺点和改进策略：1）不适合低延迟数据访问：HDFS是为了处理大型数据集分析任务的，主要是为达到大 数据分析，所以延迟时间可能会较高。改进策略：对于那些有低延时要求的应用程序，HBase 是一个

12、更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的 提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据 请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时 了。2）无法高效存储大量小文件：因为Namenode把文件系统的元数据放置在内存中，所以 文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、 文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据 一个Block，你就至少需要300MB内存。当前来说，数百万的文件还

13、是可行的，当扩展到数 十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数 量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程 管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会 有10000个Maptasks，会有很大的线程开销;若每个split为100M，则只有100个Maptasks， 每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。改进策略：要想让 HDFS能处理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件， 这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想 找回原来的小文件内容，那就必须得知道与归档文件的映射关系。横向扩展，一个Hadoop 集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大 的Hadoop集群。google也是这么干过的。多Master设计，这个作用显而易见了。正在研 发中的GFS II也要改为分布式多Master设计，还支持Master的Failove