浅析基于HDFS的分布式Namenode模型

司雅楠++阮宁

摘要：大量的信息以数据的形式进行存储和处理，如果能够以最佳的方式存储、访问和分析所有产生的数据，就可以创造出价值。面对如此海量的数据，Hadoop文件系统（HDFS，Hadoop Distributed File System）展现出了它的优越性。但是基于单一NameNode节点的HDFS文件系统表现出了单点失效、单点瓶颈和扩展性差几个问题。为了解决单一NameNode成为整个集群性能瓶颈的问题，本文提出一种基于HDFS的分布式NameNode模型，并对分布式NameNode结构的总体设计进行介绍。

关键词：HDFS；单一NameNode；分布式NameNode

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）06-0239-03

信息的数据化使得每天都有大量的数据产生，据统计现在人们创造与复制的数据量每两年就会增加一倍。这种增长趋势仍在加速，接下来几年中，数据始终保持每年50%的增长速度。这些数据的数量之大种类之多，已经无法用传统的数据处理工具加以分析，这也促进了新的数据处理技术应运而生。以云计算[1]为基础的信息数据挖掘技术，可低成本、高效率地将这些数量巨大、结构多样的终端数据存储下来，实时地进行分析和计算。

大数据[2]和云计算两个概念相辅相成，大数据中蕴含了丰富的信息和潜在价值，而云计算的出现，帮助我们更好的对大数据中的价值进行分析，获得新的认知、创造新的价值。Hadoop作为基础云计算平台已经得到了广泛的应用。Hadoop[3]的两大核心模块是HDFS[4]和MapReduce[5]，其中HDFS是Hadoop体系结构中的底层支持。

1 HDFS的基础构架[6]

Hadoop的分布式文件系统（HDFS，Hadoop Distributed File System）作为Hadoop云平台的核心组件，其主要负责海量数据的存储工作。HDFS具有高容错性，可以部署在廉价的机器之上，它允许自定义数据块备份的数目，并且将同一数据块的备份存放在不同机架中，以提高文件系统的可靠性。

HDFS文件系统采用了主/从（master/slave）结构，在集群中NameNode作为主节点，多个DataNode作为从节点。客户端（client）发起的读写请求会直接传送给NameNode，由NameNode对数据文件进行重命名、打开、删除等操作。NameNode还要实时的与DataNode进行数据交互。此外NameNode管理并维护上传数据到HDFS中时产生的EditLog日志文件和FsImage文件系统映射表等元数据信息。大数据文件传入文件系统后，首先进行预处理，被分割成固定大小的数据块（默认为64M），然后这些数据块存放在各个DataNode中。HDFS的体系结构如图1所示。

1.1 NameNode

NameNode主要有四大功能。首先，它対元数据（连线1）和数据块进行管理。其次， NameNode还可以将存储在内存中的元数据持久化到硬盘中去，以提高安全性。再次，NameNode负责处理客户端和DataNode的所提出的请求。最后，DataNode要向NameNode发送的心跳信息，NameNode通过心态信息对DataNode进行管理。

1.2 Secondary NameNode

Secondary NameNode并不是NameNode的备份，而是按照一定时间间隔保持文件系统元数据的快照。Secondary NameNode与NameNode保持通信（连线2），定时的到NameNode上获取edit logs，并更新到自己的fsimage上，一旦它有了新的fsimage文件，它就会将其拷贝到NameNode中。待NameNode重启时会就会使用这个新的fsimage文件，从而减少其重启的时间。

1.3 DataNode

DataNode最主要的工作就是存储数据块。其次DataNode会执行数据的流水线复制任务，数据存入文件系统内部后，默认被分成64M大的数据块，数据块以冗余存储的形式备份在多个DataNode中（连线3），默认备份数为3。最后DataNode还会定期的向NameNode报告其存储的数据块列表（连线4）和发送心跳信息。

1.4 Client

Client作为HDSF的使用者，它可以对系统中的文件进行读写操作。Client不能直接与DataNode通信，需要先从NameNode中获取文件对应数据块的位置信息（连线5），通过位置信息找到相应的DataNode并进行数据的读写操作（连线6，7）。

2 基于单一NameNode的分布式文件系统

2.1 单一NameNode节点设计原则

HDFS采用主/从（master/slave）结构，一个HDFS集群中由一个NameNode和若干个DataNode组成。NameNode作为HDFS的主服务器部署在性能相对较高的机器上，主要负责管理文件系统中的元数据，这消耗其大量的内存和I/O资源。所以NameNode上不存储用户的数据，也不执行计算任务。

2.2 单一NameNode模型的不足[7]

单一NameNode节点的构架避免了复杂的一致性问题，简化了系统的结构。但随着数据规模的发展，HDFS单一NameNode节点的构架在现如今的数据应用场景中，也表现出了一些不足之处，主要表现在以下几个方面.

（1） 单点性能瓶颈问题

由于HDFS上所运行的MapReduce任务和其他应用不断地增多，若在同一时间内对NameNode发出访问请求的Client数量较大时，NameNode所承受的压力也越来越大。另外，存小文件的数据不断增多，小文件的数目增多不可避免的会引起元数据的膨胀，NameNode的内存大小成为制约文件系统整体性能的瓶颈。

（2） 单点失效问题

由于NameNode节点在整个hadoop集群中仅有一个，一旦该节点发生故障就会造成客户端对文件进行操作时无法获取到元数据信息，文件到数据块的映射无法找到，整个HDFS集群无法正常工作，单一的NameNode节点就成为了HDFS集群的单一失效点（SPOF，Single Point of Failure）。为了解决单点失效的问题，HDFS的Secondary NameNode作为NameNode元数据信息的快照，待NameNode重启后会就会使用Secondary NameNode中fsimage文件里的快照，将元数据信息恢复到NameNode故障前的状态。但是NameNode重启和元数据的恢复都需要一定的时间，影响了这个系统的实时性。

（3） 扩展性问题

单一NameNode存在扩展性方面的问题。首先NameNode节点内存的大小成为整个文件系统存储规模的限制。元数据都存在放NameNode中，这样做虽然加快了元数据的访问效率，但是随着HDFS系统规模的增大，数据块的数量急剧增加，NameNode节点中元数据数量也相应的变大，当达到NameNode内存上限时NameNode节点内存的大小就制约了HDFS文件系统的规模。若只是通过简单的增大数据块大小来减小元数据的数量会增加文件系统的磁盘碎片。此外，随着文件系统存储文件数目的增加，元数据的数量也增大，单一NameNode节点的内存无法存放数量巨大的元数据信息。我们可以通过合并文件的方法来减少文件的数目从而减少元数据的数据量，但合并后文件的原始结构遭到了破坏。综上所述，单一NameNode节点也对文件系统所存放文件数量的扩展产生了制约。

3 基于分布式NameNode的分布式文件系统

为了减轻NameNode的压力，避免单一NameNode节点变成制约整个HDFS集群性能的瓶颈，本文提出基于分布式NameNode的HDFS文件系统，集群里所有的NameNode节点共同完成元数据的存储。

3.1 总体结构设计

在基于分布式NameNode节点的HDFS文件系统中，多个NameNode节点组成一个小型的分布式集群，各个NameNode对外提供一致的服务。集群内部设有一个Manager NameNode节点监控NameNode节点的工作状态。集群中还分别设有Manager NameNode和NameNode这两种节点的备用节点以保证集群的高可用性。因此，分布式NameNode集群中共有四种不同类型的节点分别承担不同的工作，其结构如图2所示。

（1） Manger NameNode节点

Manger NameNode节点监控和管理各个NameNode节点的工作状态，同时它本身也是一个NameNode节点，其具体工作任务如下：

1） 监督集群中所有NameNode节点的工作情况。Manager NameNode通过NameNode节点定时发送的心跳信息来识别NameNode节点是否失效或者是否恢复工作，如果在指定时间段内没有收到某个NameNode发送的心跳信息，则认为该节点发生故障无法正常工作。

2） 处理集群中的节点故障。当集群中出现故障节点时，Manger NameNode会启动故障节点的后备节点Secondary NameNode替换该节点。

3） 转发DataNode的状态信息。DataNode将自己的状态信息发送给Manger NameNode，再由Manger NameNode转发给所有的NameNode节点。

（2） Secondary Manger NameNode节点

为了保证分布式NameNode集群的高可用性，需要有一个Secondary Manger NameNode节点，其作用类似于Secondary NameNode，当Manger NameNode节点出现故障无法正常工作时，Secondary Manger NameNode作为该节点的快照，帮助其尽快回复正常工作。

（3） NameNode节点

基于分布式NameNode节点的HDFS文件系统将元数据分散的存放在集群中各个NameNode节点上。集群中的NameNode节点分为三种，分别是Secondary Manger NameNode节点、Manger NameNode节点和NameNode节点。它们都需要完成普通NameNode节点的工作，同时又有各自特有的工作任务。在HDFS文件系统中它们需要协同完成元数据服务。

（4） Secondary NameNode节点

当Manger NameNode节点未在规定时间内收到NameNode节点发来的心跳信息时，则认为该NameNode节点发生故障，并选择一个新的NameNode节点加载相关的元数据信息后，代替故障NameNode节点，加入到集群中。

（5） DataNode节点

负责具体的数据块的存放。

3.2 基于分布式NameNode的分布式文件系统的优点[8]

（1） 文件系统的可靠性增强

从两个方面保证文件系统的高可靠性，首先，NameNode和DataNode都会定期的向Manger NameNode节点发送心跳信息，若在规定时间内没有得到Manger NameNode节点的响应则认为其发生了故障，进而将心跳信息发送给Secondary Manger NameNode节点；其次，Secondary Manger NameNode节点也会定时的向Manger NameNode节点发送信息，在规定时间内没有得到回复，则认为Manger NameNode节点发生故障随即替代它工作。通过这两种方式保证了集群里NameNode和DataNode节点中存放的最新信息不会丢失，从而增强了文件系统的可靠性。

（2） 故障节点的切换速度提升

Manger NameNode节点故障后可以在短时间内切换成Secondary Manger NameNode节点来替代，不会导致HDFS瘫痪。

（3） NameNode通信量减小

在单一NameNode节点的HDFS文件系统中，NameNode节点需要存放所有的元数据信息和接收DataNode发送的心跳信息。而本文提出得分布式NameNode节点模型，DataNode节点的状态信息都发送给Manger NameNode节点，再由Manger NameNode节点发送给各个NameNode节点。只有当DataNode上发生数据块变化时，才由DataNode直接与其对应的NameNode发送数据块报告，这样减少了他们之间的通行量也减轻了DataNode的通信压力。如图3所示：

（4） 提高了HDFS文件系统的扩展性

分布式NameNode的HDFS集群中有多个NameNode同时对外提供元数据服务，根据一定的元数据存放策略选择相对应的NameNode节点进行元数据存储。利用这种方式解决单一NameNode节点扩展性差的问题，从而提高了HDFS文件系统的服务性能。

4 结束语

随着各种可佩戴计算设备的出现，信息的数据化是的数据量日益增加。利用Hadoop技术来对大数据进行处理成为主流方式，这也使Hadoop中HDFS文件系统单一NameNode节点设计所存在的问题日益凸显，本文提出了基于HDFS的分布式NameNode借点模型来解决基于HDFS的单一NameNode节点模型的不足之处。

本文介绍了HDFS的基本框架，以及单一NameNode节点的HDFS读取数据的过程，以此来引出单一NameNode节点模型所存在的问题，并提出分布式NameNode节点模型的基本构架。通过分布式NameNode节点模型来解决单一NameNode节点模型所存在的不足，使HDFS文件系统有更好的扩展性。

参考文献：

[1] 曹风兵. 基于Hadoop的云计算模型研究与应用[D]. 重庆：重庆大学计算机学院， 2011：5-14.

[2] 王元卓， 靳小龙， 程学旗. 网络大数据： 现状与展望[J]. 计算机学报， 2013， 36（6）： 1125-1138.

[3] Hadoop.[EB/OL][2015-02-13]. http：//hadoop.apache.org/.

[4]王永洲. 基于HDFS的存储技术的研究[D]. 南京邮电大学， 2013：13-17.

[5]李玉林， 董晶.基于Hadoop的MapReduce模型的研究与改进[J]. 计算机工程与设计， 2012， 33（8）： 3110-3116.

[6] 李鑫. Hadoop框架的扩展和性能调优[D]. 西安：西安建筑科技大学， 2012.

[7] 邓鹏， 李玫毅， 何诚. NameNode单点故障解决方案研究[J]. 计算机工程， 2012， 38（21）： 40-44.

[8] 杨帆. Hadoop平台高可用性方案的设计与实现[D]. 北京：北京邮电大学， 2012.