Hadoop中HDFS的存储机制

共计 4887 个字符，预计需要花费 13 分钟才能阅读完成。

HDFS（Hadoop Distributed File System）是 Hadoop 分布式计算中的数据存储系统，是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍 HDFS 中的一些基础概念，然后介绍 HDFS 中读写操作的过程，最后分析了 HDFS 的优缺点。

本文参考：Hadoop 集群（第 8 期）_HDFS 初探之旅 http://www.linuxidc.com/Linux/2012-12/76704p8.htm

相关文章：再理解 HDFS 的存储机制  http://www.linuxidc.com/Linux/2014-12/110511.htm

1. HDFS 中的基础概念

Block：HDFS 中的存储单元是每个数据块 block，HDFS 默认的最基本的存储单位是 64M 的数据块。和普通的文件系统相同的是，HDFS 中的文件也是被分成 64M 一块的数据块存储的。不同的是，在 HDFS 中，如果一个文件大小小于一个数据块的大小，它是不需要占用整个数据块的存储空间的。

NameNode：元数据节点。该节点用来管理文件系统中的命名空间，是 master。其将所有的为了见和文件夹的元数据保存在一个文件系统树中，这些信息在硬盘上保存为了命名空间镜像（namespace image）以及修改日志（edit log），后面还会讲到。此外，NameNode 还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而，这些信息不存放在硬盘上，而是在系统启动的时候从数据节点收集而成的。

DataNode：数据节点，是 HDFS 真正存储数据的地方。客户端（client）和元数据节点（NameNode）可以向数据节点请求写入或者读出数据块。此外，DataNode 需要周期性的向元数据节点回报其存储的数据块信息。

Secondary NameNode: 从元数据节点。从元数据节点并不是 NameNode 出现问题时候的备用节点，它的主要功能是周期性的将 NameNode 中的 namespace image 和 edit log 合并，以防 log 文件过大。此外，合并过后的 namespace image 文件也会在 Secondary NameNode 上保存一份，以防 NameNode 失败的时候，可以恢复。

edit log：修改日志，当文件系统客户端 client 进行写操作的时候，我们就要把这条记录放在修改日志中。在记录了修改日志后，NameNode 则修改内存中的数据结构。每次写操作成功之前，edit log 都会同步到文件系统中。

fsimage：命名空间镜像，它是内存中的元数据在硬盘上的 checkpoint。当 NameNode 失败的时候，最新的 checkpoint 的元数据信息就会从 fsimage 加载到内存中，然后注意重新执行修改日志中的操作。而 Secondary NameNode 就是用来帮助元数据节点将内存中的元数据信息 checkpoint 到硬盘上的。

具体 checkpoint 的过程如下图：（参考 hadoop 集群的博客）

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

2. HDFS 中文件读写操作流程

在 HDFS 中，文件的读写过程就是 client 和 NameNode 以及 DataNode 一起交互的过程。我们已经知道 NameNode 管理着文件系统的元数据，DataNode 存储的是实际的数据，那么 client 就会联系 NameNode 以获取文件的元数据，而真正的文件读取操作是直接和 DataNode 进行交互的。

写文件的过程：

客户端调用 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 返回成功。最后通知元数据节点写入完毕。

读取文件的过程：

客户端 (client) 用 FileSystem 的 open()函数打开文件

DistributedFileSystem 用 RPC 调用元数据节点，得到文件的数据块信息。

对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。

DistributedFileSystem 返回 FSDataInputStream 给客户端，用来读取数据。

客户端调用 stream 的 read()函数开始读取数据。

DFSInputStream 连接保存此文件第一个数据块的最近的数据节点。

Data 从数据节点读到客户端(client)

当此数据块读取完毕时，DFSInputStream 关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。

当客户端读取完毕数据的时候，调用 FSDataInputStream 的 close 函数。

在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录，以后不再连接。

3. HDFS 的优缺点分析

优点：

1）能够处理超大的文件；

2）流式访问数据。HDFS 能够很好的处理“一次写入，多次读写”的任务。也就是说，一个数据集一旦生成了，就会被复制到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及到数据集中的大部分数据。所以，HDFS 请求读取整个数据集要比读取一条记录更加高效。

3）可以运行在比较廉价的商用机器集群上。

缺点和改进策略：

1）不适合低延迟数据访问：HDFS 是为了处理大型数据集分析任务的，主要是为达到大数据分析，所以延迟时间可能会较高。改进策略：对于那些有低延时要求的应用程序，HBase 是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是 goes real time。使用缓存或多 master 设计可以降低 client 的数据请求压力，以减少延时。还有就是对 HDFS 系统内部的修改，这就得权衡大吞吐量与低延时了。

2）无法高效存储大量小文件：因为 Namenode 把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由 Namenode 的内存大小来决定。一般来说，每一个文件、文件夹和 Block 需要占据 150 字节左右的空间，所以，如果你有 100 万个文件，每一个占据一个 Block，你就至少需要 300MB 内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为 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 的 Failover，而且 Block 大小改为 1M，有意要调优处理小文件啊。

附带个 Alibaba DFS 的设计，也是多 Master 设计，它把 Metadata 的映射存储和管理分开了，由多个 Metadata 存储节点和一个查询 Master 节点组成。

3）不支持多用户写入以及任意修改文件：在 HDFS 的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前 HDFS 还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

————————————– 分割线 ————————————–

将本地文件拷到 HDFS 中 http://www.linuxidc.com/Linux/2013-05/83866.htm

从 HDFS 下载文件到本地 http://www.linuxidc.com/Linux/2012-11/74214.htm

将本地文件上传至 HDFS http://www.linuxidc.com/Linux/2012-11/74213.htm

HDFS 基本文件常用命令 http://www.linuxidc.com/Linux/2013-09/89658.htm

Hadoop 中 HDFS 和 MapReduce 节点基本简介 http://www.linuxidc.com/Linux/2013-09/89653.htm

《Hadoop 实战》中文版 + 英文文字版 + 源码【PDF】http://www.linuxidc.com/Linux/2012-10/71901.htm

Hadoop: The Definitive Guide【PDF 版】http://www.linuxidc.com/Linux/2012-01/51182.htm

————————————– 分割线 ————————————–

更多 Hadoop 相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13