分布式文件系统HDFS处理小文件的优化方案

作者:杨彬 刊名:软件 上传者:周辉

【摘要】Hadoop分布式文件系统(HDFS)是为可靠地存储和管理海量文件而设计。在HDFS中,所有的文件由单一的服务器NameNode来管理。因此,随着小文件数量的增加,会使HDFS系统性能下降。为了提高存储和访问HDFS上小文件的效率,本文提出了一个解决方案,即:扩展的Hadoop分布式文件系统(EHDFS)。这种方法把一组相关文件组合成一个大文件来减少文件的数量,然后建立一种索引机制,从这个组合文件中识别并访问客户所要的单个文件。实验结果表明EHDFS提高了存储和访问大量小文件的效率。

全文阅读

0引言现代计算机技术、网络技术和通信技术的飞速发展促使国民经济各领域的生产和管理系统全面信息化[1]。Hadoop是一个开源项目,能够为高效的、可扩展的分布式计算开发软件[2]。Hadoop框架已被广泛应用在各种集群中来构建大型、高性能的系统。Hadoop架构主要由Hadoop分布式文件系统(HDFS)和一个编程模型MapReduce组成,对计算机集群执行数据密集型计算。Hadoop分布式文件系统(HDFS)是Hadoop文件系统重要组件。它具主从式架构,带有一个单一NameNode节点和多个DataNode数据节点[3]。NameNode节点管理元数据和HDFS内部的文件系统配置数据。包含在NameNode节点的主存储中的元数据确保对于客户机的读写请求得到快速响应。NameNode控制DataNode节点,来存储文件并为文件读写请求提供服务。存储在HDFS的文件被复制到任意的DataNode,以确保数据的可靠性和可用性。这些集群分布副本能确保快速计算。HDFS中的文件被分成块,默认块的大小是64MB,每个块复制和存储在多个DataNode上。当文件的大小比块的尺寸大时,元数据量根据文件大小调整。然而,有大量比存储块小的文件时,每个文件形成一个存储块,因此,相应的元数据存储是相当多的。例如:假定文件的每一块元数据占用150个字节,因此,对于一个1GB的文件,分为16个64MB的块,元数据存储占用2.4KB。然而,有10500个100KB的文件(共1GB),元数据存储大约占用1.5MB。因此,尽管大量小文件占用文件系统的空间小,但使用NameNode的主存储空间却很大。这就导致集群的可用空间不能被公平地利用,而且访问大量小文件也给Namenode造成瓶颈,这就阻碍了HDFS系统在其它领域的优化应用[4][5][6]。软件杂志欢迎推荐投稿:cosoft@163.com本文通过修改HDFS,为减少NameNode节点主存中的元数据提供一种解决方案。这需要一种在HDFS中存储小文件的有效手段。基本的方法是将经客户确认相关的小文件组合成一个大文件。这有助于减少文件数量,进而减少存储的元数据。从合并的文件中访问单个文件的索引机制已经建立,而且基于文件相关性的小文件预取机制,将有助于减少NameNode元数据请求的负载。相关文件索引也被预取并缓存在客户端,这样能更好的实现读请求性能。1设计本研究提出的解决方案命名为扩展的HDFS(EHDFS)。EHDFS提供了一个改进的检索机制和索引信息的预读取。EHDFS有四种技术:文件合并、文件映射、预取和文件提取,他们在改进HDFS处理小文件的效率方面发挥了重要的作用。系统的总体架构描述的处理这些业务模块的位置如图1所示。下面的部分详细描述了这些技术。1.1文件合并在HDFS中,NameNode为每个文件维护两种类型的元数据:文件的元数据和块的元数据。文件的元数据包括文件的名称、在名称空间树的位置、文件大小、修改时间、访问时间等信息。块的元数据包含文件数据的块列表信息,以及这些块的位置信息。对于小文件来讲,文件合并技术减少了文件的元数据和由NameNode维护的块元数据。文件合并确保NameNode只保持组合文件,而不是它里面的所有小文件的元数据。组合文件的名称和他们的块信息作为一个特殊的数据结构,保存在NameNode节点里。当使用EHDFS创建文件时,文件合并过程在客户端进行。在创建组合文件时,由客户来指定小文件的名称和每个文件相关的数据。这个数据被缓存在客户端直到没有更多的文件的数据可以添加进来(即不超过HDFS块

参考文献

引证文献

问答

我要提问