基于HDFS的创新知识云平台存储架构的研究与设计

马建红　霍振奇

(河北工业大学计算机科学与软件学院　天津 300401)



基于HDFS的创新知识云平台存储架构的研究与设计

马建红霍振奇

(河北工业大学计算机科学与软件学院天津 300401)

针对现有存储结构无法满足海量创新知识带来的存储及服务需求的问题，提出一种改进的HDFS(Hadoop Distributed File System)分布式存储系统并应用到创新知识云平台。首先引入包文件及分布式索引服务，改进HDFS小文件存储的效率问题，然后通过优化HDFS的命名空间备份及故障恢复服务，实现可用性更强、资源利用率更高的HDFS高可用架构。通过系统的设计和实现证明优化工作大大降低了命名节点的内存压力，提高了集群的可用性，并且改进的HDFS存储系统可以满足创新知识云平台的存储需求。

创新知识HDFS小文件存储单点故障

0　引　言

一直以来创新都是国内外各行各业在场竞争中关注的重点之一，我国更是将科技创新作为国家的基本战略。其中，建立创新平台对创新知识进行全社会共享是促进创新发展过程中一个必不可少的环节。创新知识[1]的复杂性以及其量级带来的是计算的复杂性和服务的动态性要求，这正与云计算的特性相契合。因此将云计算的概念引入到创新知识平台的建设也是一种必然的发展要求。

创新知识云平台旨在帮助创新设计人员解决创新过程中的问题。其结构主要包含对创新知识的收集积累、加工整合和知识再利用等过程。该平台由一个创新知识云平台总站和多个创新基地组成。创新基地是知识产生的地方，也是运用创新知识的地方。创新平台总站负责所有基地数据的加工，整理和元数据提取，然后将具有逻辑关系的高实用性知识分发到各个基地，从而提高知识的可达性实现创新知识的社会共享。如图1所示。

图1　创新知识云平台架构

应当注意创新知识数据的一些独特特性。首先是创新知识的多元性。创造发明的内在规律和原理必须通过大量的数据支撑才能体现其价值，而这些数据必然是多样性的，且数据之间的联系也是复杂多变的。其次，创新知识条目众多但是每条知识的数据量较小。发明创新的过程需要大量的思考和时间，但是其结论表达往往归纳为少量的文字或图像。然而创新领域中各种奇妙的解决思路纷繁复杂，数量可观。最后，这些创新知识的运用过程中必然要求有清晰可用的工具能够让用户了解自身真实需求，进而以准确知识推理为用户呈现有启发思维作用的创新知识。所以，创新平台必然要解决的问题就是对创新知识的有效关联管理及大数据量高效存取。因此本文在优化和改进HDFS小文件存储和单点故障问题的基础上，将其引入到创新知识云平台的存储系统。

1　相关工作

Hadoop[2]是在大数据需求下产生的一种对海量数据存储和计算的分布式云计算系统基础架构。HDFS[3]作为Hadoop系统下的文件存储服务，因其稳定性和高效性而得到广泛应用。文献[4]将其应用到医学影像存储领域，文献[5]将其应用到MapGIS K9瓦片地图集数据存储，文献[6]则在其基础上建立了云数据备份系统。同时，许多学者也对HDFS本身进行了研究，如HDFS的安全问题[7]、下载效率[8]以及集群的节能问题[9]等。因此本文基于较新的Hadoop 2.2.0 版本，为创新知识云平台搭建了高容错、高吞吐的基础存储架构。但由于创新知识表达具有的特性及创新知识存取方式的特性，必须对HDFS的适用性作出改进。

对于HDFS对存储大量小文件时表现出的性能上的不足[10]，文献[11]在Sequence File的基础上实现小文件的合并存储，文献[12]则结合格雷码实现了海量音乐特征数据管理。这些解决方案或多或少都是针对特定的数据解决方案,难以推广应用。Hadoop本身提供了Har、SequenceFile和MapFile三种整合存储的结构，但是SequenceFile和MapFile是Append Only，也就是只能对添加新的数据而不能对已有的数据进行更新或删除，而Har甚至是完全只读的，也就是创建文件之后便不能再做任何改变。Hadoop自身在其2.0版本中引入YARN(Yet Another Resource Negotiator)和HDFS Federation，以改进现有的不足并适应新的需求。其中用于解决Nanenode内存问题的HDFS Federation只是对命名空间进行了拆分，并不能完全解决性能问题。本文提出了一种较为通用的具有可改写能力的方案。该方案在保留原始存储方式的基础上添加了灵活的包文件存储形式，用户自行在两者之间选择。其中包文件存储形式可以大量减少存储小文件时Namenode的内存压力，提升存储性能。

同时由于Namenode单点设计会降低整个集群的可用性问题上，也有很多文献进行了改进优化。其中文献[13]中介绍了多种优化方案，并指出它们在数据丢失、故障恢复时间和自动恢复等方面的不足。同时给出了一种改进方案，但是这种改进方案没有考虑到对新版本中多命名空间的适应，可能会造成大量的计算资源浪费。文献[14]中也比较了多种优化方案，指出这些方案以及Hadoop本身提出的HA方案的不足。在其给出的解决方案中采用了扁平化的命名空间设计，以方便将metadata均匀的分布到命名节点中。但是这种方式无法完成层次结构化的文件定位。本文在解决Namenode单点问题时，借鉴了Hadoop 2.0的高可用方案，引入Zookeeper[15]管理的备份集群，但是没有引入外部存储可能带来的新的缺陷，同时充分考虑了HDFS Federation特性，实现了资源利用率更高的自动故障恢复功能。

本文基于实际项目需求，在HDFS的小文件存储问题和主节点高可用问题上给出了新的解决思路，从而搭建了更加高效高可靠的云存储平台。需要指出的是文中的优化策略虽然是为满足创新知识云平台的需求而设计的，但是解决方案具有很强的通用性，可以方便地运用到其他云存储设计当中。

2　系统优化方法及实现

2.1小文件存储优化

在HDFS的主从结构设计中命名结点内存中存储了所有的命名空间元数据。由于HDFS主要被设计用于存储超大文件，因此在系统内部将文件分割为多个Block文件(默认为64 MB，新版本中为128 MB)，Namenode直接管理这些Block信息。所以，当系统中存在大量小文件的时候Namenode的内存压力变成了整个系统的瓶颈。HDFS Federation的引入在一定程度上使该问题得到了缓解，但是创新知识以大量小文件形式存在，小文件存储问题仍然需要解决。

本文主要采用了将小文件合并存储的策略，将小文件合并成一个或多个包文件，以减小命名结点内存压力；同时为了解决合并带来的读取性能问题，引入了索引策略及索引服务从而提高文件的存取效率。整体结构如图2所示。

图2　小文件存储服务架构

首先在客户端(Client)API中添加了小文件存储服务(SmallFileStoringService)及读取服务(SmallFileRetrieveService)分别处理小文件的写入和读取任务，辅助原有HDFS的API完成更高效的存储服务。在Namenode中的小文件部署服务(SmallFileLocatingService)主要负责添加小文件时包文件所在数据块的创建、增加和定位，以及包文件块中的数据重新排布工作的协调。在Datanode中新增了两个新的服务：小文件索引服务(SmallFileIndexingService)为小文件读取提供索引；小文件附加服务(SmallFileAppendingService)在小文件附加删除修改等操作的时候修改索引文件及配合小文件部署服务更新数据块。索引文件及索引服务都是在数据结点上的，因此可以将大量的命名服务分散到数量较多的数据结点上，从而大幅减少命名结点的压力。

在HDFS文件处理过程中主要包含了读、写和修改三个操作。其中写操作相当于将小文件合并(采用的HDFS的Append操作)到指定的包文件中，因此其基本步骤与Append操作流程相同，如图3所示。

图3　小文件写入流程

需要注意以下三点：

1) 客户端需要指定文件是否需要存储到包文件中，在不指定的情况下，小文件也可以存储为单独的文件。

2) 包文件的建立时间设定在Namenode在查找目的块的时候。此时Namenode先检查命名空间中是否存在该包文件。如果不存在则先新建该包文件，Datanode在建立相应的块文件和块元数据文件时调用小文件附加服务一并建立索引文件。

3) 数据结点附加操作完成后，需要调用小文件附加服务更新相应的索引文件。

索引文件主要记录对应块文件中小文件的路径及文件结束位置，其结构示意如下：

example1.jpg

example2.jpg

……

实例数据表示exampl1.jpg的数据位置为0～7150，而exampl2.jpg的数据位置为7151～12 540。写文件时，读取上一个文件的位置再加上当前文件大小可得当前文件结束位置。

下面介绍小文件读取过程，如图4所示。改进后的文件读取操作与原有的文件读取操作相比，在服务器数据交互数量上是相同的，区别是改进的过程同时读取多个数据结点以真正取得所需文件。客户端并行的向所有目的块所在的Datanode发送读请求。只有包含该文件的Datanode返回文件数据，其他的返回查找失败，客户端选择最先返回的文件数据接收，并终止其他线程。

图4　小文件读取流程

对于小文件的修改和删除操作来说，直接进行数据块的修改会造成性能的急剧下降。因此引入标识位的方式避免频繁的数据修改。在文件修改或删除的时候，首先和读取操作相似确定数据块的位置，并通过小文件附加服务修改索引文件的标识位以标识该文件当前的状态。当文件读取的时候，小文件索引服务会将已经标识为删除的文件忽略，返回索引失败。

标志位方式的引入会造成大量的无用文件保存在集群中。所以在命名结点中设计的小文件部署服务以定期任务的方式(管理员也可以手动调用)，将包文件块中的数据重新排布并更新索引文件。当新文件写入时，Namenode中的小文件部署服务会根据适配算法将文件适配到合适的包文件数据块中，以充分利用数据块。

2.2Namenode单点问题改进

Hadoop之前的主要结构中Master主机中运行着所有MapReduce的JobTracker同时维护着所有Datanode的Meta数据。因此当Master结点出现问题，整个集群将处于一种不可用的状态。这种问题被称为Master结点的单点问题，也称高可用问题即High Availability。Hadoop 2.0 对该现象有所改善。首先引入YARN后Master的计算压力会降低很多，同时HDFS Federation可以分担Namenode上保存所有Datanode的Meta数据所造成的主节点压力。但是每个Federation中的Namenode还是存在单点问题。

本文引入一种备份集群的概念，将所有的备份服务器集中管理以获得更高的资源利用率。命名空间NS中存在两种角色：活动结点AN和备份结点SNN。整个Namenode Federation 使用同一个备份集群进行热备份，运用Zookeeper[16]作为一致性协调处理和自动故障恢复工具。结构如图5所示。本文将备份结点设计为虚拟服务以增加灵活性，即备份服务可以运行在单独服务器上，也可以和其他Namenode甚至Datanode共用一台服务器。

图5　备份集群架构

Namenode中需要备份的数据包括文件系统元数据和数据块分布信息。其中文件系统元数据是Namenode内存中维护其命名空间的数据结构，但是为了保证数据的可持久性，Namenode将这些数据以FSImage文件的形式序列化到硬盘或其他可持久化的存储介质上。为防止文件系统元数据的每次修改都直接改写FSImage文件，HDFS引入了EditLog日志文件，将每次修改都记录到日志文件中，等到一定时机再将EditLog和FSImage文件进行合并。块分布信息是由每次Datanode的心跳数据实时维护的数据结构，主要是为了对Datanode中数据块信息的实时监控和查询。因此需要对这三种数据进行热备份，过程如下：

1) 初始化。集群启动时先进行一次FSImage文件同步操作。如果Namenode尚未格式化，则在先进行格式化再同步。设定Namenode写EditLog的目录为备份集群路径。

2) EditLog写入所有备份结点。利用Zookeeper服务处理EditLog一致性写入问题，即只有集群中所有备份服务全部写入成功，该操作才生效，否则返回错误并回滚。

3) FSImage与EditLog合并。该任务由备份集群处理。合并操作被触发后，备份集群先选择一个备份结点开始合并任务，该服务器通知相应Namenode建立检查点，然后该结点开始进行合并任务。合并完成后，将新的FSImage文件同步到相应的Namenode和其他备份结点中，并通知它们进行FSImage文件替换和已合并EditLog文件删除的操作。

4) 心跳数据管理。为了保持所有数据块分布信息实时同步，以便故障恢复时及时使用，所有的Datanode的心跳数据报不仅要向所有Namenode汇报还要向备份集群汇报。汇报数据由Zookeeper服务统一的一致性的记录到备份集群中。

解决单点故障的第二个阶段是故障恢复。当Namenode出现故障的时候，Zookeeper便会监测到它的心跳数据的异常，在超时策略下判定其是否出现故障，如果出现故障则开始故障恢复过程：

1) 首先，Zookeeper直接将故障信息发布到该命名空间的其他Namenode。同时，在Datanode进行心跳包的返回数据中通知所有的数据节点当前的故障信息，以便其将相应的块池设定为故障恢复状态。

2) 然后，通过Zookeeper的选举算法，在当前备份集群中可用的服务器中选举出一台代替故障服务器的主机。通知该主机将FSImage及数据块分布信息加载到内存中，设置为等待状态。

3) 最后，通过Zookeeper通知集群中所有Namenode代替主机的产生，以调整新的集群拓扑结构。同时在Datanode的心跳回复信息中通知它们将对应故障恢复状态的块池绑定到新的Namenode。相关Datanode尝试联系新的Namenode，如果连接成功则将状态转换为正常状态。否则，通知Zookeeper集群新主机失败，Zookeeper会将这台主机标注为失败，再次启动故障恢复流程。

需要注意的是，当一个Namenode被备份集群判定为出现故障之后，它可能处于没有完全停止或只是无法与其他Namenode联系等状态而继续提供服务，此时会出现两个Namenode管理同一个命名空间，这种可能引起混乱现象被称为“脑裂”现象。为解决该问题，当备份集群在判定Namenode失败之后会在内部标识其状态为宕机状态，拒绝处于宕机状态的结点对日志的操作，从而防止命名空间错误改动。同时在判定Namenode失败后尝试向其发送停机命令，以防止错误读取。

为实现命名结点动态拓展，在备份集群中引入动态添加Namenode的功能。新加入的Namenode向当前集群发送初始化请求，备份集群收到请求后通知所有Namenode新节点的加入，然后初始化该结点并使之共同担负备份集群的任务。这样新的命名结点或者先前出现故障的Namenode都可以很轻松地加入到集群当中，实现命名结点的动态拓展。

3　系统实现及验证

为测试以上两个方面改进后对HDFS的海量创新知识存取效率和服务可用性的提升，将其作为基础存储服务应用到创新知识云平台的设计中，结构如图6所示。

图6　系统整体架构

3.1系统配置

系统中包含一台Web服务器用于向用户提供基于创新知识服务；一台关系数据库服务器用于提供简单的关系数据存储服务；三台Namenode节点组建的备份集群，其中两台提供命名服务，一台仅提供备份服务；四台Datanode节点。服务器间以1000 Mbps交换机连接。其中各主机采用双核2.1 GHz的CPU，以及3 GB的内存。

3.2小文件存储优化

为了排除不相关因素的影响，先将测试结构简化，只使用一台Namenode和四台Datanode。用随机产生的50 KB左右的大量小文件进行实验。写入文件前先记录Namenode和各Datanode内存占用量，然后将一定数量的小文件顺序写入集群，分别记录写入总时间、Namenode和各Datanode内存占用量。接着连续读取这些文件记录总时间。多次试验最后，计算出Namenode内存平均增加量，Datanode内存平均增加量，平均写入时间和平均读取时间。具体的统计数据如图7、图8所示。

图7　小文件存储优化内存占用对比图8　小文件存储优化时间消耗对比

当采用包文件策略后，数据块数量大大减少，估算值为(默认数据块体积/文件平均大小=64 MB/50 KB≈1310)，测试数据显示为1200倍左右，与预期基本相符。Datanode的内存下降应该与Namenode相似，但是引入的小文件索引服务会占用部分内存，所以整体内存占用容量减少比例较低，约为20%。而存取时间因为受到内存占用、索引等多方面影响，所以效率有所提升，文件量小的时候提升不明显，由于需要计算一次包内定位，所以效率可能会有所降低，但是文件量大的情况下有较好的表现。

3.3高可用性

配置好三个Namenode组成的备份集群，其中两台提供命名服务和备份服务，另一台只提供备份服务。选择其中一台命名服务器将其主进程结束，并记录时间。此时访问该命名空间的资源出现不可用的状态，而另一个命名空间的服务依然可以访问。连续尝试访问失败的命名空间，直至资源可以重新访问，记录时间。试验集群中文件数量不同的情况，数据统计如表1所示。

表1　备份集群实验数据

数据表明，该方案实现了集群的故障热备份及自动恢复，同时故障恢复的时间与文件数量相关，主要原因在于文件恢复时需要将FSImage文件读取到相应命名结点的内存结构。但是由于小文件存储中大大减少了命名空间数据量，因此恢复时间受到的影响较小在系统可接受的范围。而且恢复期间其他命名空间访问不受影响，可以提供部分命名服务。

4　结　语

随着创新知识数量上不断膨胀，应用需求不断增加的情况下，构建海量数据的创新知识云平台的重要性日益凸显。本文提出了包文件结构的概念使得命名节点的内存占用大大减少进而提升HDFS的存储效率。在此基础上引入的备份集群为集群带来热备份及自动恢复特性的同时提高了系统可用性。通过整体系统的设计与实现可以看出，优化工作基本满足预期效果，可以为创新知识云平台提供良好的分布式存储服务。

[1] Ding Zhikun,Jiayuan Wang,et al.Innovation and Patent Knowledge Management in the Construction Industry[C]//Proceedings of the 17th International Symposium.on Advancement of Construction Manage-ment and Real Estate,Berlin,2014:833-842.

[2] Shvachko K,Kuang H,Radia S,et al.The hadoop distributed file system[C]//Proceeding of IEEE 26th Symposium.on Mass Storage Systems and Technologies (MSST),Lake Tahoe,2010:1-10.

[3] The Apache Software Foundation.HDFS architecture guide[EB/OL].[2011-05-04].http://hadoop.apache.org/ common/ docs/ current/ hdfs_design.pdf.

[4] 李彭军,陈光杰,郭文明.基于HDFS的区域医学影像分布式存储架构设计[J].南方医科大学学报,2011,31(3):495-498.

[5] 万波,党琦,杨林.基于HDFS管理MapGISK9瓦片地图集的研究与实现[J].计算机应用与软件,2013,30(12):232-235.

[6] 郭东,杜勇,胡亮.基于HDFS的云数据备份系统[J].吉林大学学报:理学版,2012,50(1):101-105.

[7] 余琦,凌捷.基于HDFS的云存储安全技术研究[J].计算机工程与设计,2013,34(8):2700-2705.

[8] 曹宁,吴中海,刘宏志,等.HDFS下载效率的优化[J].计算机应用,2010,30(8):2060-2065.

[9] 廖彬,于炯,张陶,等.基于分布式文件系统 HDFS的节能算法[J].计算机学报,2013,36(5):1047-1064.

[10] Chandrasekar S,Dakshinamurthy R,Seshakumar P G,et al.A novel indexing scheme for efficient handling of small files in Hadoop Distributed File System[C]//Computer Communication and Informatics (ICCCI),2013 International Conference on,2013:1-8.

[11] 余思,桂小林,黄汝维,等.一种提高云存储中小文件存储效率的方案[J].西安交通大学学报,2011,45(6):59-63.

[12] 朱媛媛,王晓京.基于GE码的HDFS优化方案[J].计算机应用,2013,33(3):730-733.

[13] 邓鹏,李枚毅,何诚.Namenode单点故障解决方案研究[J].计算机工程,2012(21):40-44.

[14] Huang Z.DNN:A Distributed Namenode File System for Hadoop[D].University of Nebraska,2014.

[15] Patrick Hunt,Mahadev Konar,Flavio P.Junqueira,Benjamin Reed.ZooKeeper:Wait-free coordination for Internet-scale systems[EB/OL].[2010].http://www.usenix.org/events/usenix10/tech/full_papers/Hunt.pdf.

RESEARCH AND DESIGN OF HDFS-BASED STORAGE ARCHITECTURE FOR INNOVATIVE KNOWLEDGE CLOUD PLATFORM

Ma JianhongHuo Zhenqi

(SchoolofComputerScienceandEngineering,HebeiUniversityofTechnology,Tianjin300401,China)

Because current storage structure cannot meet the storage and service demands brought by massive innovative knowledge, we presented an improved HDFS distributed storage system and applied it to the innovative knowledge cloud platform. First, we introduced the package file and distributed indexing service, thus improved the efficiency of HDFS small files storage problem. Then by optimising the naming space backup and failure recovery services in HDFS we achieved high availability architecture of HDFS with stronger availability and higher resource utilisation. By designing and implementation of the system we proved that the optimisation work greatly reduced the memory pressure of naming node and enhanced the availability of cluster, and the improved HDFS storage system could meet the storage needs of innovative knowledge cloud platform.

Innovative knowledgeHadoop Distributed File System (HDFS)Small files storageSingle point of failure

2014-08-27。马建红，教授，主研领域：软件工程，计算机辅助创新设计过程与方法。霍振奇，硕士生。

TP311

A

10.3969/j.issn.1000-386x.2016.03.013