运用Hadoo高效存储海量碎片文件的方法

刘扬 刘冰

摘 要学院综合管理信息系统，是学院开展各项工作的信息化方式和途径，在信息共享的同时，减少工作数据报送的重复现象，结合技术手段以实现工作效率的提高。本文从实际出发，从技术的角度，就目前本单位所使用的综合管理信息系统中存在的问题进行了深入研究和剖析，对系统性能进行了技术优化和改进，减少了碎片化数据的产生，提升了系统的整体效能。

【关键词】Hadoop 碎片化

在目前单位使用的综合管理信息系统中，应用层中体现为多用户并发访问系统出现数据传输过慢造成大量的数据延迟，系统卡死以及用户掉线的情况。在系统底层体现为CPU和内存使用率长时间保持在较高状态。

为了优化并提高系统整体效能，从根本上解决系统碎片化处理问题，找到解决碎片化处理的方法和机制，所以我们进行了本次实验。

实验环境如表1所示。

实验选取功能相对VirtualBox更强的VMware Workstation虚拟机软件，以学院服务器使用的Ubuntu 16.04作为虚拟机的操作系统，同时使用稳定的Hadoop-2.7.4部署伪分布式Hadoop实验环境，Hadoop的源代码由Java实现，故选取稳定的Openjdk-8-jdk版本进行Java环境的配置。

在完成伪分布式hadoop部署后启动hadoop将预先准备好的75K个文件从本地存储到hdfs分布式文件系统中，在一次性存储如此大量文件时，虚拟机出现了短暂性死机情况，几分钟后，shell出现大量警告，如图1。

着手开始分析出现警告的原因，使用hdfs shell命令查看hdfs分布式文件系统上存储数据的文件，发现只有部分文件被成功的从本地存储到分布式文件系统，这说明所执行的命令没有错误。那究竟是什么原因导致还有大量的文件没有被成功存储到分布式文件系統上？带着这个疑问，开始查询hdfs分布式文件系统存储文件的相关资料。

首先，hdfs分布式文件系统的存储分为元数据存储和真实数据存储，元数据存储在namenode节点上，真实数据则存储在datanode节点上，结合本次实验环境，所部署的是ubuntu下的伪分布式hadoop，datanode节点和namenode节点在同一台虚拟机上，所以元数据和真实的数据都是存储在同一台虚拟机上的。在分析原因的过程中，我注意到了一个地方，就是hdfs分布式文件系统不适合做的事——存储大量小文件。因为namenode要存储HDFS的metadata（比如目录的树状结构，每个文件的文件名、ACL、长度、owner、文件内容存放的位置等等信息）会受到namenode内存的限制。分析到这里似乎找到了出现警告的根源。

根据分析得知namenode节点的元数据需要放在内存中。其中，saveFSImage方法的参数代表内存元数据将要保存的位置，磁盘确实有块空间，对元数据进行持久化存储，名为fsimage，如果直接读取磁盘文件，速度肯定跟不上，内存中也要放一些元数据信息，虽然很容易丢失，但可以提供查询服务，实际上就是读写分离，由读写分离就有了数据一致性的问题，因为写入数据，没有写入内存中，最新的元数据记录在哪呢？实际上是记录在一个很小的文件中，这个文件不提供修改，只提供追加，以日志的形式记录，一直都保持着几十兆大小，名为edits***.log，比如在上传一个文件时，先对NAMENODE进行询问，往哪里写？NAMENODE一边分配一边记录，将空间分配信息记录edits**.log，当完成一个副本的写入工作后，通知NAMENODE，被认为是写入成功，这时，将edits**.log的数据更新至内存，此时，内存中的数据是最新的，即使现在断电，最新的元数据在edits**.log也有保存。

既然如此，之前遇到的警告就是因为内存的原因使得件没有全部都存储到hdfs分布式文件系统中，有一部分存储成功，很容易让人联想到是不是因为内存不足导致的呢？

Namenode元数据在内存中所占空间的计算方法如表2。

元数据在内存中所占空间包含文件和块两部分，由于实验环境为伪分布式Hadoop，文件块的副本数目为一，忽略文件名长度对计算结果的影响，分步计算过程如下：

文件所占内存：

75000*100*1000B≈750MB

块所占内存：

5000*（250*1000B+24*1）≈750MB

计算元数据需要总内存：

750MB+750MB≈1.5GB

然而这只是粗略计算，其中并没有包含块信息和其他信息，实际情况会比所计算的结果多出很多。通过使用hdfs的oiv和ls这两个命令测得namenode实际使用内存大约2.2G，而在实验环境中分给虚拟机内存正好是2.5G。一直到现在，之前遇到的问题才真正得到正确的解答。让我更进一步地了解hdfs分布式文件系统存储的机制。hdfs分布式文件系统无法高效完成对海量碎片文件的存储，仔细想一想真的是这样，七万个文件会占据2.2G内存的硬件资源，那七千万个文件，乃至七亿个文件，将会占据多少的内存硬件资源，而一个大型的分布式系统，在存储大文件时所产生的“碎片”文件的数量是不可预估的，当务之急是针对这个问题提出一种行之有效的解决方法。

在上面提到的Namenode元数据所需内存的计算公式中，注意到所需内存大小与文件名长度有很大关系，那么，如果能够找到一种方法，能够像windows和linux操作系统那样实现对文件的压缩，是不是能够有效的解决这个问题呢？

在这里就要探讨一种hdfs存储海量“碎片”文件的解决方法——Hadoop Archive。它是通过archive工具来将多个文件建立为归档文件，这种归档文件并不同于windows和linux操作系统下的压缩文件，首先归档文件的扩展名是*.har，并且在归档后还可以直接访问每一个文件，但是并没有实现压缩的功能，除此之外，archive文件一旦创建就无法改变，这就意味这你要改一些东西的话，你需要重新创建archive文件。在Hadoop archive中包含两种文件，分别是元数据和数据文件，元数据以两种形式存在———_index和_masterindex文件，在_index文件中包含了归档文件所含文件的文件名和位置信息。

从图2所示布局图中可以看出，Masterindex指向index，index的各个部分则指向不同的数据，这种布局使得归档文件实现了类似于目录的功能，而归档文件中的数据文件对于用户来说又是透明的，用户在建立归档文件后仍然能够直接访问内部的数据文件，唯一的缺点就是没有实现数据追加的功能，一旦归档文件被创建，如果想要实现对归档文件内容的调整，就只能重新创建归档文件。

通过图4所示效能比对图我们可以看出在系统底层集成了Hadoop Archive方法后，对照原有系统在碎片哈数据处理方面有了较大的提高。并且在系统响应和并发响应中也有了很大的提高，这样一来我们可以看出构建归档文件方法对于碎片化处理底层数据和优化十分有效，也是我们找出了这样一条系统优化和提升的新思路。

参考文献

[1]查礼.基于Hadoop的大数据计算技术[J].科研信息化技术与应用，2012（06）.

作者简介

刘扬（1982-），男，山东省济南市人。大学本科学历，初级职称。研究方向为软件工程，现从事一线教学工作。

刘冰（1997-），男，山东省潍坊市人。山东电子职业技术学院大二学生。

作者单位

山东电子职业技术学院 山东省济南市 250000