1、天地一体化网络中基于 HDFS 的元数据优化策略 王坤 杨杨 邱雪松 北京邮电大学可信网络通信协同创新中心 摘 要： Hadoop 分布式文件系统 (HDFS) 是 Hadoop 的核心之一, 已经广泛应用于天地一体化网络数据的存储。但由于 HDFS 存储和管理的数据容量受限于命名节点 (Name Node) 的内存大小, 其扩展性受到制约。针对 Name Node 管理元数据时存在的加载文件系统镜像 (FSImage) 时间过长、容量受内存大小限制等问题, 提出将 HDFS 层级化的元数据结构调整为扁平化结构, 并将元数据移出内存的优化思路, 设计了基于日志结构合并树 (Log-Struct
2、ured Merge-Tree, LSM) 与内存映射文件进行元数据管理的 F-HDFS 架构, 并介绍了 F-HDFS 的元数据管理方式。通过 F-HDFS 的原型系统与 HDFS 的对比实验, 表明 F-HDFS 性能整体优于HDFS, 可提供稳定快速的元数据服务, 能存储与管理超过 HDFS 5.3 倍以上的数据。关键词： Hadoop; HDFS; 元数据管理; 扩展性; 内存映射文件; 作者简介：王坤 (1994) , 男, 硕士研究生, 主要研究方向:大数据与分布式存储系统;作者简介：杨杨 (1981) , 女, 副教授, 主要研究方向:无线传感网应用与大数据分析;作者简介：邱雪松
3、 (1973) , 男, 教授, 主要研究方向:网络管理与通信软件。收稿日期：2017-09-19基金：北京邮电大学可信网络通信协同创新中心预研基金项目Metadata Optimization Strategy Based on HDFS in Integrated Space-ground NetworkWANG Kun YANG Yang QIU Xuesong Collaborative Innovation Center of Trusted Cyber Communications, Beijing University of Posts and Telecommunication
4、s; Abstract： 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 Name Node.In order to solve the problem of long time
5、when loading file system mirror (FSImage) to Name Node 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
6、 and memory mapped files.Through the contrast experiment of F-HDFS prototype system and HDFS, its 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.Keyword： Hadoo
7、p; HDFS; metadata management; expansibility; memory mapped file; Received： 2017-09-190 引言大数据和云计算技术独有的无限扩展、随时获取的资源管理方式对于部队作战数据平台的建设将带来深刻影响与变革。足够高的、可靠的、低成本的、容易获取的带宽资源, 是云计算和大数据产业发展的前提和基础。但是在天地一体化网络中, 由于通信、侦察、导航气象等多种功能的异构卫星/卫星网络、深空网络、空间飞行器以及地面有线和无线网络设施所产生的空、天、地、海等多维信息的海量性和安全性将对大数据平台的构建提出挑战。同时, 带宽竞争所引发的
8、数据同步过程中传输中断、网络延迟、内容丢失等问题将严重制约天地一体化网络中大数据同步的效率。HADOOP 因其具有高可靠性、高扩展性、高效性、高容错性和低成本等优点, 自推出以来在学术界得到了广泛的关注, 同时得到了迅速的普及和应用。随着 HADOOP 的不断成熟, 现已发展成为包含HBASE、HIVE、ZOOKEEPER、MA-HOUT 等基本子系统的完整的大数据处理平台。在进行天地一体化网络数据的存储中, HDFS 文件系统因其流式读写等特点, 性能较为高效。与 PVFS1、Moose FS2和 GFS3等分布式文件系统类似, HDFS 也采用主从模式, 在一个 HDFS 集群中有一个 N
9、ame Node 和多个 Data Node, Name Node 负责存储和管理元数据4, Date Node 负责以块为单位存储实际文件数据。此外, 集群中通常还会有 Standby Node 用来保证高可用性。由于 Namenode 负责管理整个集群的所有元数据, HDFS 将集群中每个文件、数据块和目录项都视为一个对象 (Object) , 保存每个对象的元数据, 并在集群运行期间将所有元数据加载入 Name Node 内存, 以提供高速的元数据访问服务。因此, HDFS 的 Name Node 会由于元数据过多而导致内存溢出, 限制整个集群可存储的文件数和块数量。在 Name Nod
10、e 中, 命名空间 (Name Space) 占据了 Name Node 的大部分内存5。Name Node 是 HDFS 文件系统的入口, 访问 HDFS 的应用或客户端需要从 Name Node 处获知分布式文件系统的树状目录和文件结构, 进而访问实际的文件内容。Name Node 对命名空间的管理数据除在内存中常驻外, 还会保存到磁盘的FSImage 和 Editslog 文件中。当 Name Node 重启或灾备切换后, 会根据磁盘中数据在内存中重新构造命名空间。Name Node 采用这种方式的主要问题在于:(1) 元数据扩展性受限。Name Node 在内存中加载所有元数据, 元数
11、据量过大将会引起 JVM 频繁的垃圾回收, 影响集群性能;若超过 Name Node 内存大小, 集群将完全不可用。(2) 元数据加载耗时。Name Node 每次重启都要根据磁盘中的 Editslog 和FSImage 还原命名空间, 并逐步加载入内存。元数据加载十分耗时, 且在该阶段 Name Node 无法提供服务。为突破上述限制, 提高 HDFS 元数据管理性能, 本文从 Name Node 层次化的元数据管理方式入手, 将元数据分离出内存, 借鉴 LSM6-7设计了一种轻量化元数据存储结构 MDDB (Metadata Data Base) , 将元数据从内存转移到内存映射文件与磁盘
12、中, 不受 Name Node 内存容量限制, 且可提供优秀的元数据操作访问性能。通过基于 LSM 与内存映射文件的扁平化方式进行元数据管理与操作, 并构建了原型系统 F-HDFS 验证其可行性与有效性。1 F-HDFS 方案设计将文件目录进行扁平化处理, 在 Name Node 中加入了新的元数据存储组件元数据数据库 (Meta Data Data Base, MDDB) , Name Node 通过与 MDDB 交互进行元数据操作, 为客户端提供文件服务。F-HDFS 的架构如图 1 所示, 其中元数据存储在 MDDB 中, MDDB 采用 LSM 与内存映射文件和针对性的优化措施, 提供
13、高效的元数据访问。由于将元数据的存储和处理分离出了 Name Node 内存, F-HDFS 对于文件系统的操作也与原本的 HDFS 不同, 下面将详细介绍 F-HDFS 中MDDB 和元数据操作的相关设计与优化。图 1 F-HDFS 架构 下载原图1.1 MDDB 设计针对 F-HDFS 的 Name Node 元数据存取场景设计了 MDDB, 它是一种基于 LSM 树 (Log-Structured Merge-Tree) 与内存映射文件8的轻量化键值数据库。不同于 HDFS 将元数据加载入内存, 并在磁盘中持久化存储 FSImage 的方式, F-HDFS的元数据存储和处理都在 MDDB
14、 中进行。MDDB 借鉴了 Level DB 的设计思想, 针对 F-HDFS 的应用场景进行了重新设计和优化。MDDB 由 4 个层次组成, 包括活跃层、L0 层、L1 层和 L2 层, 结构如图 2 所示。其中, 顶层为活跃层。元数据的插入和删除操作仅发生在活跃层, 该层包含一个活跃表。当活跃表的大小超过阈值时, 将转变为只读表并被放入 L0 层。同时, 一个新的空表将会被创建, 成为当前活动的活跃表。图 2 MDDB 层次结构 下载原图活跃表包含两部分, 一部分是驻留在 Name Node 内存中的 Hash Map, 一部分是以内存映射方式加载的索引文件和数据文件。数据文件包含实际的元
15、数据内容, 索引文件是对数据文件每条元数据的索引, 便于快速访问。当 Name Node 向 MDDB 中插入新的文件元数据时, 例如对于文件 K 及其元数据 V, 首先 K 与 V 将被追加到活跃表的数据文件末;然后, 索引文件中将生成对应的索引 i, 记录 K、V 的位置;接着, Hash Map 中将插入一条映射记录, 该记录的关键字为 K, 值为索引 i。若从活跃层读取文件 K 的元数据, 需要先根据 K 从Hash Map 中取出对应的索引 i, 然后根据索引 i 到数据文件中读取元数据 V 的值。为了加快数据读写速度, 数据文件和索引文件均以内存映射的形式加载与访问。L0 层中表的
16、构成成分、读取过程和活跃表一致, 但从 L0 层开始, 只支持表读取操作。当 L0 层的表达到一定数量 (如 2 个) , 多个表将会被排序归并为一个表, 归并结果将被放入 L1 层。在排序和归并过程中, 表中键重复的旧数据将被淘汰。L1 层的每个表包含两部分内容, 一部分是布隆过滤器9 (Bloom Filter) , 另一部分是数据文件。数据文件经由 L0 层排序归并得到。在 L0 层的排序与归并过程中, 数据同时被写入 Bloom Filter 和数据文件中。L1 层的读取操作需要先在布隆过滤器中检索, 若布隆过滤器报告目标项可能存在, 则通过二分法查询索引文件。当 L1 层的表达到一定
17、数量 (如 4 个或 8 个) , 多个表将会被排序归并为一个新表, 并放入 L2 层中。如果 L2 层中存在旧表, 则旧表将参与排序归并, 最终 L2层中只保留一张表。在归并过程中, 所有被删除或更新的旧数据都会被清除。MDDB 中的删除操作可以视为特殊的插入操作, 对于待删除的文件或目录, MDDB会针对该条目插入一条拥有删除标记特殊数据, 在后续的归并中会将标记删除的无效数据清除。查询与读取操作从活跃层开始, 根据数据新鲜度按从上往下、同层内从表队列队首向队尾的顺序搜索。由于 Name Node 是运行在 Java 虚拟机上的, HDFS 在运行期间将元数据驻留在Name Node 的
18、JVM 堆内存中, 因此元数据存取性能较高。但 JVM 存在垃圾回收机制, 存储大量元数据会频繁触发垃圾回收, 影响 Name Node 的正常使用。内存映射文件的性能介于纯内存和纯磁盘之间, 并持久化保存在磁盘上, 无数据丢失风险, 且不受垃圾回收机制影响。F-HDFS 可在 Name Node 重启后, 节省将FSImage 文件反序列化和载入内存的时间。此外 L2 层的数据文件以磁盘文件的形式存放, 避免大量的“冷数据”10浪费内存地址空间。MDDB 中所有数据文件都是直接或间接持久化保存的, 如果 NameNode 宕机或进程意外结束, 元数据不会丢失, 重启后即可快速恢复。1.2 元
19、数据扁平化管理机制F-HDFS 对于 HDFS 的扁平化处理包括两方面:一方面是目录结构的扁平化。在 F-HDFS 中, 每个目录项的目录名和父目录编号“pid”构成唯一的标识依据“ (pid, name) ”, 与目录项对应的访问控制信息、数据块信息等内容一并保存在 MDDB 中, 形成扁平化的目录结构。另一方面是元数据的扁平化。F-HDFS 按照原 HDFS 中 INode 的格式, 将 INode 处理为扁平字节数组, 其中每一种元数据属性都是定长。Name Node 可通过预定义的偏移位置, 直接读取元数据字段内容, 而不用将全部元数据反序列化为 INode 对象再读取, 节省了访问时
20、间。在扁平化目录中, 访问目录的过程也异于树形结构。例如图 3 所示的目录结构, 访问目录“/foo/dira”的步骤为: (1) 由根目录出发, 通过“ (0, root) ”得到根目录 root 的 ID 为 1; (2) 构造“ (1, foo) ”得到目录 foo 的 ID 为 2; (3) 通过“ (2, dira) ”即可查找到目录 dira 的元数据信息。本示例为了简洁省略了实际中访问控制的检查过程。图 3 扁平化目录示例 下载原图与访问目录的步骤类似, 对于 mkdir 等操作, 例如“mkdir/foo/a”, 首先需要根据“/foo/a”查找是否存在该目录项, 若不存在,
21、直接向 MDDB 活跃层插入“ (2, a) ”与目录 a 的元数据即可。若需更新某目录项的元数据, 如 rename 等操作, 则需要执行一次原子更改操作, 同时将操作记录写入 Editslog。删除文件或目录的操作与更新操作类似, 更新或删除操作完成后, 无效数据在 L1、L2层发生排序归并时才会被清除。2 仿真实验以 Hadoop 2.7.3 版本源码为基础, 修改并编译完成了 F-HDFS 的原型系统, 另外还将扁平化处理适配了 Level DB, 以验证本文方案所设计的 MDDB 及相关元数据访问优化的有效性。本节将展示本文针对 HDFS、F-HDFS (以 MDDB 为引擎的 F-
22、HDFS 记为 F-HDFS_M、以 Level DB 为引擎的 F-HDFS 记为 F-HDFS_L) 的对比实验结果。2.1 实验环境本文实验在 3 个规格相同的集群上展开, 各集群的 Name Node 配置均为 2.4 GHz CPU、8 GB RAM、1 GB Ethernet、200 GB HDD。每个集群包含 5 个 Data Node, 配置为 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
23、元数据操作基准测试实验首先采用 Hadoop 官方提供的 Benchmark 测试套件11作为测试工具, 测试HDFS 和 F-HDFS 的 Name Node 对元数据和目录项的“mkdir”操作性能。对于“mkdir”操作, 本文利用测试工具分别以 1、2、4、8、16、32 和 64 线程, 对 HDFS、F-HDFS_M 和 F-HDFS_L 各创建 100 000 个目录。针对不同线程数量分别测试 3 次, 每次测试完成都重新格式化 Name Node, 每种线程数量取 3 次每秒操作数 (op/s) 的平均数为测试结果。测试结果的单位是每秒的操作数, 数值越大表明性能越好。从图 4
24、 中可以看出, 虽然在 64 线程的实验中, F-HDFS_M的数据为 9569.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 相差较大的原因在于Level DB 仅采用内存和磁盘存储数据, 每次新建目录项之前的判存操作都要查询, 形成了性能瓶颈。而 F-HDFS_M 通过集中式的追加写和优化的索引, 实现了优于 HDFS 的性能。图 4 mkdir 测试结果 下载原图2.3 FSI
25、mage 负载测试除了针对 Name Node 的元数据性能测试, 还利用 Load Generator12对 3 个集群进行了实际文件读写的负载测试。实验测试 3 个集群在不同文件数量负载下的吞吐量, 每次测试分为 3 个步骤:首先以最大目录深度为 8、子目录数最大为100、文件平均大小 1 MB, 副本数为 3、本次文件数量为基数, 生成目录结构文件;然后根据目录结构文件, 在集群中自动生成相应的目录和文件;最后建立 64个客户端对 Name Node 进行文件读写和目录访问, 最终输出本次测试的综合吞吐量。虽然在元数据操作基准测试中, F-HDFS_M 的 mkdir 操作吞吐量优于 H
26、DFS, 而对于 open 操作, F-HDFS_M 的最大吞吐量低于 HDFS。但在图 5 所示结果中, F-HDFS_M 响应多客户端操作的的综合吞吐量均优于 HDFS。由于本实验中副本数为3, 实际上当 HDFS 达到可用极限时, 该集群的 Name Node 共管理至少 600 万个对象 (包括文件、目录、块等) , 而当 F-HDFS 达到可用极限时, Name Node 共管理至少 3 200 万个对象, 是 HDFS 的 5.3 倍以上。图 5 负载测试结果 下载原图3 结束语针对天地一体化信息网络背景中基于 HDFS 文件系统进行元数据管理的局限, 提出了 F-HDFS 改进方
27、案, 通过将元数据分离出 Name Node 内存与 FSImage, 实现元数据扩容与快速加载。首先, 本文介绍了 F-HDFS 的设计方案, 包括元数据的存储引擎 MDDB、扁平化的目录与元数据管理措施。其次, 通过原型系统与 HDFS的对比实验, 展现并分析了 F-HDFS 的性能。实验结果表明, F-HDFS 具有优秀的元数据操作性能, 能提供多于 HDFS 容量 5.3 倍以上的数据存储和管理能力。参考文献1Haddad I F.PVFS:A Parallel Virtual File System for Linux ClustersJ.Linux Journal, 2000, 2
28、000 (80es) :5. 2Bai S, Wu H.The Performance Study on Several Distributed File SystemsCInternational Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery.IEEE, 2011:226-229. 3Ghemawat S, Gobioff H, Leung S T.The Google File SystemCNineteenth ACM Symposium on Operating Systems Pri
29、nciples.ACM, 2003:29-43. 4Shafer J, Rixner S, Cox A L.The Hadoop Distributed Filesystem:Balancing Portability and PerformanceCPerformance Analysis of Systems&Software (ISPASS) .2010 IEEE International Symposium on.IEEE, 2010:122-133. 5Shvachko K V.HDFS Scalability:the Limits to GrowthJ.login:the Mag
30、azine of USENIX&SAGE, 2010, 35:6-16. 6ONeil P, Cheng E, Gawlick D, et al.The Log-structured Merge-tree (LSM-tree) J.Acta Informatica, 1996, 33 (4) :351-385. 7Chang F.Bigtable:A Distributed Storage System for Structured DataJ.ACM Transactions on Computer Systems (TOCS) , 2006, 26 (2) :205-218. 8Song
31、N Y, Son Y, Han H, et al.Efficient Memory-mapped i/o on Fast Storage DeviceJ.ACM Transactions on Storage (TOS) , 2016, 12 (4) :19. 9Kumar A, Xu J, Wang J.Space-code Bloom Filter for Efficient Per-flow Traffic MeasurementJ.IEEE Journal on Selected Areas in Communications, 2006, 24 (12) :2327-2339. 10
32、Run A K, Chitharanjan K.A review on hadoopHDFS infrastructure extensionsCInformation&Communication Technologies.IEEE, 2013:132-137. 11Hadoop BenchmarkingEB/OL.http:hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Benchmarking.html. 12Load GeneratorEB/OL.http:hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/SLGUser Guide.html. 13Dev D, Patgiri R.Dr.Hadoop:an Infinite Scalable Metadata Management for Hadoop-How the Baby Elephant Becomes ImmortalJ.Frontiers of Information Technology&Electronic Engineering, 2016, 17 (1) :15-31.
