天地一体化网络中基于HDFS的元数据优化策略

2018-12-29邱雪松

无线电通信技术 2018年1期

王坤，杨杨，邱雪松

(北京邮电大学可信网络通信协同创新中心，北京 100876)

10.3969/j.issn.1003-3114.2018.01.02

王坤，杨杨，邱雪松.天地一体化网络中基于HDFS的元数据优化策略[J].无线电通信技术,2018,44(1):09-13.

[WANG Kun,YANG Yang,QIU Xuesong.Metadata Optimization Strategy Based on HDFS in Integrated Space-ground Network [J].Radio Communications Technology,2018,44(1):09-13.]

天地一体化网络中基于HDFS的元数据优化策略

王坤，杨杨，邱雪松

(北京邮电大学可信网络通信协同创新中心，北京 100876)

Hadoop分布式文件系统(HDFS)是Hadoop的核心之一，已经广泛应用于天地一体化网络数据的存储。但由于HDFS存储和管理的数据容量受限于命名节点(NameNode)的内存大小，其扩展性受到制约。针对NameNode管理元数据时存在的加载文件系统镜像(FSImage)时间过长、容量受内存大小限制等问题，提出将HDFS层级化的元数据结构调整为扁平化结构，并将元数据移出内存的优化思路，设计了基于日志结构合并树(Log-Structured Merge-Tree，LSM)与内存映射文件进行元数据管理的F-HDFS架构，并介绍了F-HDFS的元数据管理方式。通过F-HDFS的原型系统与HDFS的对比实验，表明F-HDFS性能整体优于HDFS，可提供稳定快速的元数据服务，能存储与管理超过HDFS 5.3倍以上的数据。

Hadoop; HDFS; 元数据管理; 扩展性; 内存映射文件

TP274

1003-3114(2018)01-09-5

2017-09-19

北京邮电大学可信网络通信协同创新中心预研基金项目；中央高校基本科研业务费专项资金项目；国家科技支撑计划项目 (2015BAI11B01)

MetadataOptimizationStrategyBasedonHDFSinIntegratedSpace-groundNetwork

WANG Kun,YANG Yang,QIU Xuesong

(Collaborative Innovation Center of Trusted Cyber Communications, Beijing University of Posts and Telecommunications,Beijing 100876,China)

Hadoop distributed file system (HDFS) is one of the cores of Hadoop.It has been widely used in data storage of integrated space and terrestrial information network.However,the scalability of HDFS is limited by the memory size of the NameNode.In order to solve the problem of long time when loading file system mirror (FSImage) to NameNode memory and the problem of capacity restricted by memory size,F-HDFS is designed by adjusting the HDFS hierarchical metadata structure to flat structure and moving metadata out of memory.The design of F-HDFS is based on log structured merge tree and memory mapped files.Through the contrast experiment of F-HDFS prototype system and HDFS,it's proved that the performance of F-HDFS is better than HDFS in general,and it can provide stable and fast metadata service,and can store and manage more than 5.3 times more data than HDFS.

Hadoop; HDFS;metadata management; expansibility; memory mapped file

0 引言

大数据和云计算技术独有的无限扩展、随时获取的资源管理方式对于部队作战数据平台的建设将带来深刻影响与变革。足够高的、可靠的、低成本的、容易获取的带宽资源，是云计算和大数据产业发展的前提和基础。但是在天地一体化网络中，由于通信、侦察、导航气象等多种功能的异构卫星/卫星网络、深空网络、空间飞行器以及地面有线和无线网络设施所产生的空、天、地、海等多维信息的海量性和安全性将对大数据平台的构建提出挑战。同时，带宽竞争所引发的数据同步过程中传输中断、网络延迟、内容丢失等问题将严重制约天地一体化网络中大数据同步的效率。HADOOP因其具有高可靠性、高扩展性、高效性、高容错性和低成本等优点，自推出以来在学术界得到了广泛的关注，同时得到了迅速的普及和应用。随着HADOOP的不断成熟，现已发展成为包含HBASE、HIVE、ZOOKEEPER、MAHOUT等基本子系统的完整的大数据处理平台。在进行天地一体化网络数据的存储中，HDFS文件系统因其流式读写等特点，性能较为高效。

与PVFS[1]、MooseFS[2]和GFS[3]等分布式文件系统类似，HDFS也采用主从模式，在一个HDFS集群中有一个NameNode和多个DataNode，NameNode负责存储和管理元数据[4]，DateNode负责以块为单位存储实际文件数据。此外，集群中通常还会有Standby Node用来保证高可用性。由于Namenode负责管理整个集群的所有元数据， HDFS将集群中每个文件、数据块和目录项都视为一个对象(Object)，保存每个对象的元数据，并在集群运行期间将所有元数据加载入NameNode内存，以提供高速的元数据访问服务。因此，HDFS的NameNode会由于元数据过多而导致内存溢出，限制整个集群可存储的文件数和块数量。

在NameNode中，命名空间(NameSpace)占据了NameNode的大部分内存[5]。NameNode是HDFS文件系统的入口，访问HDFS的应用或客户端需要从NameNode处获知分布式文件系统的树状目录和文件结构，进而访问实际的文件内容。NameNode对命名空间的管理数据除在内存中常驻外，还会保存到磁盘的FSImage和Editslog文件中。当NameNode重启或灾备切换后，会根据磁盘中数据在内存中重新构造命名空间。NameNode采用这种方式的主要问题在于：

① 元数据扩展性受限。NameNode在内存中加载所有元数据，元数据量过大将会引起JVM频繁的垃圾回收，影响集群性能；若超过NameNode内存大小，集群将完全不可用。

② 元数据加载耗时。NameNode每次重启都要根据磁盘中的Editslog和FSImage还原命名空间，并逐步加载入内存。元数据加载十分耗时，且在该阶段NameNode无法提供服务。

为突破上述限制，提高HDFS元数据管理性能，本文从NameNode层次化的元数据管理方式入手，将元数据分离出内存，借鉴LSM[6-7]设计了一种轻量化元数据存储结构MDDB(Metadata Data Base)，将元数据从内存转移到内存映射文件与磁盘中，不受NameNode内存容量限制，且可提供优秀的元数据操作访问性能。通过基于LSM与内存映射文件的扁平化方式进行元数据管理与操作，并构建了原型系统F-HDFS验证其可行性与有效性。

1 F-HDFS方案设计

将文件目录进行扁平化处理，在NameNode中加入了新的元数据存储组件元数据数据库(MetaData Data Base，MDDB)，NameNode通过与MDDB交互进行元数据操作，为客户端提供文件服务。F-HDFS的架构如图1所示，其中元数据存储在MDDB中，MDDB采用LSM与内存映射文件和针对性的优化措施，提供高效的元数据访问。由于将元数据的存储和处理分离出了NameNode内存，F-HDFS对于文件系统的操作也与原本的HDFS不同，下面将详细介绍F-HDFS中MDDB和元数据操作的相关设计与优化。

图1 F-HDFS架构

1.1 MDDB设计

针对F-HDFS的NameNode元数据存取场景设计了MDDB，它是一种基于LSM树(Log-Structured Merge-Tree)与内存映射文件[8]的轻量化键值数据库。不同于HDFS将元数据加载入内存，并在磁盘中持久化存储FSImage的方式，F-HDFS的元数据存储和处理都在MDDB中进行。MDDB借鉴了LevelDB的设计思想，针对F-HDFS的应用场景进行了重新设计和优化。

MDDB由4个层次组成，包括活跃层、L0层、L1层和L2层，结构如图2所示。

其中，顶层为活跃层。元数据的插入和删除操作仅发生在活跃层，该层包含一个活跃表。当活跃表的大小超过阈值时，将转变为只读表并被放入L0层。同时，一个新的空表将会被创建，成为当前活动的活跃表。

图2 MDDB层次结构

活跃表包含两部分，一部分是驻留在NameNode内存中的HashMap，一部分是以内存映射方式加载的索引文件和数据文件。数据文件包含实际的元数据内容，索引文件是对数据文件每条元数据的索引，便于快速访问。

当NameNode向MDDB中插入新的文件元数据时，例如对于文件K及其元数据V，首先K与V将被追加到活跃表的数据文件末；然后，索引文件中将生成对应的索引i，记录K、V的位置；接着，HashMap中将插入一条映射记录，该记录的关键字为K，值为索引i。若从活跃层读取文件K的元数据，需要先根据K从HashMap中取出对应的索引i，然后根据索引i到数据文件中读取元数据V的值。为了加快数据读写速度，数据文件和索引文件均以内存映射的形式加载与访问。

L0层中表的构成成分、读取过程和活跃表一致，但从L0层开始，只支持表读取操作。当L0层的表达到一定数量(如2个)，多个表将会被排序归并为一个表，归并结果将被放入L1层。在排序和归并过程中，表中键重复的旧数据将被淘汰。

L1层的每个表包含两部分内容，一部分是布隆过滤器[9](BloomFilter)，另一部分是数据文件。数据文件经由L0层排序归并得到。在L0层的排序与归并过程中，数据同时被写入BloomFilter和数据文件中。L1层的读取操作需要先在布隆过滤器中检索，若布隆过滤器报告目标项可能存在，则通过二分法查询索引文件。

当L1层的表达到一定数量(如4个或8个)，多个表将会被排序归并为一个新表，并放入L2层中。如果L2层中存在旧表，则旧表将参与排序归并，最终L2层中只保留一张表。在归并过程中，所有被删除或更新的旧数据都会被清除。

MDDB中的删除操作可以视为特殊的插入操作，对于待删除的文件或目录，MDDB会针对该条目插入一条拥有删除标记特殊数据，在后续的归并中会将标记删除的无效数据清除。查询与读取操作从活跃层开始，根据数据新鲜度按从上往下、同层内从表队列队首向队尾的顺序搜索。

由于NameNode是运行在Java虚拟机上的， HDFS在运行期间将元数据驻留在NameNode的JVM堆内存中，因此元数据存取性能较高。但JVM存在垃圾回收机制，存储大量元数据会频繁触发垃圾回收，影响NameNode的正常使用。内存映射文件的性能介于纯内存和纯磁盘之间，并持久化保存在磁盘上，无数据丢失风险，且不受垃圾回收机制影响。F-HDFS可在NameNode重启后，节省将FSImage文件反序列化和载入内存的时间。此外L2层的数据文件以磁盘文件的形式存放，避免大量的“冷数据”[10]浪费内存地址空间。MDDB中所有数据文件都是直接或间接持久化保存的，如果NameNode宕机或进程意外结束，元数据不会丢失，重启后即可快速恢复。

1.2 元数据扁平化管理机制

F-HDFS对于HDFS的扁平化处理包括两方面：一方面是目录结构的扁平化。在F-HDFS中，每个目录项的目录名和父目录编号“pid”构成唯一的标识依据“(pid，name)”，与目录项对应的访问控制信息、数据块信息等内容一并保存在MDDB中，形成扁平化的目录结构。另一方面是元数据的扁平化。F-HDFS按照原HDFS中INode的格式，将INode处理为扁平字节数组，其中每一种元数据属性都是定长。NameNode可通过预定义的偏移位置，直接读取元数据字段内容，而不用将全部元数据反序列化为INode对象再读取，节省了访问时间。

在扁平化目录中，访问目录的过程也异于树形结构。例如图3所示的目录结构，访问目录“/foo/dira”的步骤为：① 由根目录出发，通过“(0，root)”得到根目录root的ID为1；② 构造“(1，foo)”得到目录foo的ID为2；③ 通过“(2，dira)”即可查找到目录dira的元数据信息。本示例为了简洁省略了实际中访问控制的检查过程。

图3 扁平化目录示例

与访问目录的步骤类似，对于mkdir等操作，例如“mkdir /foo/a”，首先需要根据“/foo/a”查找是否存在该目录项，若不存在，直接向MDDB活跃层插入“(2，a)”与目录a的元数据即可。若需更新某目录项的元数据，如rename等操作，则需要执行一次原子更改操作，同时将操作记录写入Editslog。删除文件或目录的操作与更新操作类似，更新或删除操作完成后，无效数据在L1、L2层发生排序归并时才会被清除。

2 仿真实验

以Hadoop 2.7.3版本源码为基础，修改并编译完成了F-HDFS的原型系统，另外还将扁平化处理适配了LevelDB，以验证本文方案所设计的MDDB及相关元数据访问优化的有效性。本节将展示本文针对HDFS、F-HDFS(以MDDB为引擎的F-HDFS记为F-HDFS_M、以LevelDB为引擎的F-HDFS记为F-HDFS_L)的对比实验结果。

2.1 实验环境

本文实验在3个规格相同的集群上展开，各集群的NameNode配置均为2.4 GHz CPU、8 GB RAM、1 GB Ethernet、200 GB HDD。每个集群包含5个DataNode，配置为4 GB RAM、1 GB Ethernet、500 GB HDD。所有节点的操作系统为Ubuntu 14.04 64 bit、Java 1.8。HDFS、F-HDFS_M与F-HDFS_L分别运行在3个独立的集群上。

2.2 元数据操作基准测试

实验首先采用Hadoop官方提供的Benchmark测试套件[11]作为测试工具，测试HDFS和F-HDFS的NameNode对元数据和目录项的“mkdir”操作性能。

对于“mkdir”操作，本文利用测试工具分别以1、2、4、8、16、32和64线程，对HDFS、F-HDFS_M和F-HDFS_L各创建100 000个目录。针对不同线程数量分别测试3次，每次测试完成都重新格式化NameNode，每种线程数量取3次每秒操作数(op/s)的平均数为测试结果。测试结果的单位是每秒的操作数，数值越大表明性能越好。从图4中可以看出，虽然在64线程的实验中，F-HDFS_M的数据为9 569.97 op/s，低于HDFS的数据10 512.7 op/s，但F-HDFS_M结果整体优于对比项。F-HDFS_L在1、2、4线程时与HDFS性能接近，但随着线程数的增加，测试结果增长缓慢。F-HDFS_L与F-HDFS_M相差较大的原因在于LevelDB仅采用内存和磁盘存储数据，每次新建目录项之前的判存操作都要查询，形成了性能瓶颈。而F-HDFS_M通过集中式的追加写和优化的索引，实现了优于HDFS的性能。

图4 mkdir测试结果

2.3 FSImage负载测试

除了针对NameNode的元数据性能测试，还利用Load Generator[12]对3个集群进行了实际文件读写的负载测试。实验测试3个集群在不同文件数量负载下的吞吐量，每次测试分为3个步骤：首先以最大目录深度为8、子目录数最大为100、文件平均大小1 MB，副本数为3、本次文件数量为基数，生成目录结构文件；然后根据目录结构文件，在集群中自动生成相应的目录和文件；最后建立64个客户端对NameNode进行文件读写和目录访问，最终输出本次测试的综合吞吐量。

虽然在元数据操作基准测试中，F-HDFS_M的mkdir操作吞吐量优于HDFS，而对于open操作，F-HDFS_M的最大吞吐量低于HDFS。但在图5所示结果中，F-HDFS_M响应多客户端操作的的综合吞吐量均优于HDFS。由于本实验中副本数为3，实际上当HDFS达到可用极限时，该集群的NameNode共管理至少600万个对象(包括文件、目录、块等)，而当F-HDFS达到可用极限时，NameNode共管理至少3 200万个对象，是HDFS的5.3倍以上。

图5 负载测试结果

3 结束语

针对天地一体化信息网络背景中基于HDFS文件系统进行元数据管理的局限，提出了F-HDFS改进方案，通过将元数据分离出NameNode内存与FSImage，实现元数据扩容与快速加载。首先，本文介绍了F-HDFS的设计方案，包括元数据的存储引擎MDDB、扁平化的目录与元数据管理措施。其次，通过原型系统与HDFS的对比实验，展现并分析了F-HDFS的性能。实验结果表明，F-HDFS具有优秀的元数据操作性能，能提供多于HDFS容量5.3倍以上的数据存储和管理能力。

[1] Haddad I F.PVFS: A Parallel Virtual File System for LinuxClusters[J].Linux Journal,2000,2000(80es):5.

[2] Bai S, Wu H.The Performance Study on Several Distributed File Systems[C]∥ International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery.IEEE,2011:226-229.

[3] Ghemawat S, Gobioff H,Leung S T.The Google File System[C]∥ Nineteenth ACM Symposium on Operating Systems Principles.ACM,2003:29-43.

[4] Shafer J,Rixner S,Cox A L.The Hadoop Distributed Filesystem: Balancing Portability and Performance [C]∥ Performance Analysis of Systems & Software (ISPASS).2010 IEEE International Symposium on.IEEE,2010:122-133.

[5] Shvachko K V.HDFS Scalability: the Limits to Growth[J].login:the Magazine of USENIX & SAGE,2010,35: 6-16.

[6] O'Neil P,Cheng E,Gawlick D,et al.The Log-structured Merge-tree (LSM-tree)[J].Acta Informatica ,1996,33(4): 351-385.

[7] Chang F.Bigtable: A Distributed Storage System for Structured Data[J].ACM Transactions on Computer Systems (TOCS),2006,26(2):205-218.

[8] Song N Y,Son Y,Han H,et al.Efficient Memory-mapped i/o on Fast Storage Device[J].ACM Transactions on Storage (TOS),2016 ,12(4): 19.

[9] Kumar A,Xu J,Wang J.Space-code Bloom Filter for Efficient Per-flow Traffic Measurement[J].IEEE Journal on Selected Areas in Communications ,2006,24(12): 2327-2339.

[10] Run A K,Chitharanjan K.A review on hadoop — HDFS infrastructure extensions[C]∥ Information & Communication Technologies.IEEE,2013:132-137.

[11] Hadoop Benchmarking [EB/OL].http:∥hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Benchmarking.html.

[12] Load Generator[EB/OL].http:∥hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/SLGUser Guide.html.

[13] Dev D,Patgiri R.Dr.Hadoop:an Infinite Scalable Metadata Management for Hadoop-How the Baby Elephant Becomes Immortal[J].Frontiers of Information Technology & Electronic Engineering,2016,17(1):15-31.