外文翻译中文.docx

对于Hadoop处理小文件的性能优化Neethu Mohandas 和Sabu M. Thampi印度科钦Rajagiri工程与技术学院摘 要Hadoop是由Dong Cutting提出的，一个顶级的Apache项目。用于支持千级别的庞大数据的分布式应用。它是一个开源的软件框架，灵感来自于谷歌的MapReduce编程模型和谷歌的系统文件。它是由全球社区的开发者用java共同研发的。Hadoop被广泛地应用与世界各地的各种学术科研机构和商业组织，还包括了common hadoop，hadoop文件系统(HDFS)和MapReduce作为其子项目。common hadoop包含了支持其他子项目的通用工具。HDFS是一个高性能的分布式文件系统，Hadoop给予了HDFS高度的访问程序数据的性能。它还通过数据复制提高了可靠性，并同时保持数据的完整性。MapReduce的是基于MapReduce算法的一个能在集群上进行大量的分布式数据计算的软件框架。虽然Hadoop被广泛的使用，但是由于种种问题，它的潜力还没有被充分发挥出来，小文件的问题就是其中之一。在hadoop的0.18.0版本开始，hadoop归档被作为处理小文件的解决方案被引入hadoop。文件序列化也可以作为一种解决方案。这两种解决方案各自有自己的优点和缺点。我们提出的与建议预计将获得两个解决方案的优点，同时确保hadoop有一个更好的性能。关键词：hadoop，hadoop分布式文件系统（HDFS）,MapReduce，小文件问题，hadoop归档，文件序列化1绪 论在分布式计算的时代，hadoop飞速发展起来，它在涉及TB和PB级别的计算处理中，表现出极佳的性能和高效的处理能力。这些成就可能源于一个名为MapReduce的底层软件架构和一个名为HDFS的分布式文件系统。MapReduce正像它的名字表现的，是一个基于Map和Reduce两步的支持大量计算的软件框架。Map和Reduce两个步骤的概念都源于函数是编程语言。在2004年的OSDI中，谷歌提交了一份关于MapReduce的文件，标志着这项工程的动工。Hadoop是基于java的MapReduce实现，它的基本概念即为将一个巨大的难以管理的计算分成更小的可管理的块。HDFS，从另一方面来说，是受了谷歌文件系统的启发。它依靠它的可靠的数据存储，数据的高完整性，以及最重要的高吞吐量，来支持hadoop高性能的大型计算。因此，Hadoop广泛地受到了网络，搜索，金融，科研机构等市场的青睐。2研究背景2.1MapReduce程序员们从这个框架中受益良多，因为他们可以避免考虑应用程序复杂的分布式运算所带来的头痛。这是因为分布式运算可能需要将输入分片，分配给集群中一组计算节点，管理系统的故障，节点间的通信都需要实时考虑。程序员可以方便地运用分布式框架进行分布式编程， 即使他们没有多少分布式计算经验，而hadoop就是其中最受程序选喜爱的一个分布式编程框架。基本的编程模型可以描述为一个Map任务和一个Reduce任务的组合。要执行计算，就需要提供的一组键值对作为最初的输入。然后计算完成后，最终产生一组键值对作为输出。在具有MapReduce库的情况下，计算可以被看做是两个函数，Map和Reduce。Map和Reduce函数都会被用户重写。Map函数将接受一组键值对作输入，并且将一组键值对作为中间输出。然后，MapReduce库根据键的唯一性将这些值组合起来，然后将它传递给Reduce函数。如果键值对的列表过大，为了适应内存的容量，可能会进行迭代操作。更新这些从属于一个特有键的值的集合使它们变为一个更小的值的集合是Reduce函数的任务。如果用户希望得到一个更小的输出值的集合，他/她通过将这个输出作为下一个输入，避免人工地将这个输出作为另一个MapReduce的输入，从而完成一嵌套的MapReduce调用。举个简单的例子，我们可以算一组URL的访问频率，如果我们给网页请求的日志作为输入到MapReduce计算。该Map函数产生。Reduce函数总结的值 相同的URL，并生成一个对，从而计算出该URL访问频率。在图1中，我们可以看到Map和Reduce任务被master节点分配道不同的节点，而且将输入划分给不同的节点来分配不同的Map作业，从而产生各自的中间值。master节点将被每个节点告知中间值产生的位置。在获取这些信息的时候，master节点将它传递给指定的节点与reduce任务终于完成了合并工作，产生输出 文件。图1：MapReduce执行概要2.2 Hadoop分布式文件系统hadoop分布式文件系统是被hadoop使用的文件系统。它与UNIX的文件系统非常类似，并且被开发来支持的Hadoop在数据密集型分布式计算。在Hadoop实现一个集群的情况下， 根据雅虎，Apache Hadoop项目最大的贡献者目前的设计，每个集群作为NameNode的一个节点，它存储所有的文件的元数据。应用程序的数据将被存储在的DataNodes之中。 如果用户希望执行读操作，则该请求将被NameNode处理并且它会提供数据块构成的位置的文件。客户端将从最接近的DataNode进行读取操作。对于写操作，NameNode会选择一组DataNodes（默认情况下），负责对每个文件块的备份而客户将以流水闲的方式将这些文件块写入那些DataNodes节点中。在集群中，当一个DataNode启动时，他将和NameNode进行一次握手，这是为了保证数据的完整性。在握手的过程中，命名空间的ID和DataNode软件的版本将会被检测。只有命名空间的ID相同且DataNode软件的版本支持的情况下DataNode才会被允许进入集群。每个DataNode都会定期发送块报告给Namenode，来提供关于块拷贝的信息，从而帮助NameNode收集每个块拷贝文件的信息。这样，就保持了数据的一致性。此外，DataNode每隔3秒钟就发送一次心跳（heartbeats），来确认现在可用的节点，同时文件块拷贝他持有的信息。如果NameNode在一段时间内，比如说10分钟，没有收到来自DataNode的心跳，那么他将认为DataNode以及它的块拷贝是不可用的，并且在集群中选择那些可用的块中重建它们的新拷贝。图2HDFS结构NameNode会为元数据分配空间，并且平衡集群中正在使用包含心跳信息的DataNode之间的负载。从图2我们可以看出HDFS体系结构的示意图，以及读取和写入操作。3小文件问题让我们来讨论这个问题对我们之前讨论的hadoop的两大组件，Hadoop分布式文件系统和MapReduce的影响。科研的应用环境中，如气候学，天文学中，含有大量的小文件。3.1对HDFS的影响默认情况下，HDFS块大小为64 MB。任何比这个空间更小的文件都被认为是小文件。我们知道，NameNode会负责保持集群中DataNode中的每个DataNode的元数据。如果每一个DataNode都含有数量不确定的小文件，显然NameNode将很难去管理大量的元数据。此外，这将导致一个低效率的数据访问模式，因为它将需要大量的有DataNode到DataNode的寻道操作，以搜索和检索请求的文件块。3.2对MapReduce的影响数量庞大的小文件将消耗MapReduce的额外开销，由于Map任务通常在同一时刻只读取一块的输入数据，并且每个Map任务将只处理很少的一点数据。这样就会导致大量的Map任务。3.3为什么小文件被制作出来？无论这些文件时比较大文件的碎片或者他们是自然产生的。一两个这两种情况会在大多数环境中使我们面临小文件问题。图3：小文件问题3.4小文件问题的特征这个问题中的一个重要的原因是NameNode不得不管理大量的元数据在它的内存中。另外一个问题涉及每个DataNode启动时扫描它的文件系统来取得它持有的文件中的数据被发送到的NameNode所需要的块报告所经历的时间。小文件的数量越大，需要时间就越长。在集群中，管理员将对目录用户配额提供两种选择：1. 每个目录下存放最大数量的文件2. 每个目录下使用最大的文件空间在图3中，允许的最大文件数是7，并且对于允许一个用户目录最大文件空间是7GB。用户1既没有超出 的文件最大限制数，也没有超出最大的文件空间的限制。所以传入一个新的文件请求马上处理。但对于用户2，因为他已经达到了的文件限制数，虽然很多文件允许的空间仍然存在，对于一个新文件传入的请求不能被处理。但用户n具有到达文件空间限制虽然他还没有超过第一准则限制文件的最大数量对于一个新文件传入的请求不能被处理。4存在的解决方案如果较小的文件是一个较大的文件的一部分，那么这个问题可以通过写一个连接小文件来产生一个和默认块大小几乎一样的大文件的程序来解决。但是，如果这些文件是本身就小，那么他们就需要通过某些方式进行分组。对于这方面的一些现有的解决方案如下。4.1Hadoop归档Hadoop在后来的版本中，引入了归档来作为对小文件问题的解决方案。Hadoop的归档文件，总是以*.har作为拓展名，包含了元数据和数据文件。元数据将被组织成索引和主索引文件，而数据文件将会以part-*文件的方式存储。这些归档文件的名字和位置信息将会被存储在索引文件中。用于归档的文件系统的修改是对用户不可见的，然而，对系统性能的提升则是用户显著能感受到的。此外，该 在HDFS中的文件数量已减少导致更好的NameNode性能。该解决方案是只在Hadoop版本0.18.0以后的版本中存在，而以前的版本仍然被广泛使用。如果一个MapReduce任务正被超出配额进行处理，那么该任务将会由调度中心终止，不管任务是多么地重要，或者多么接近完成。虽然文件归档文件的压缩是不可能用这种方法。读操作仍可能会很慢，因为每个文件的访问需要两个索引文件的读取和一个数据文件读取。图4：hadoop归档格式4.2序列化文件在这个方法中，现有的数据被转化为序列化文件。即，那些小文件被放在一个文件序列中，并且这个序列可以被流程化处理。序列化文件还允许被压缩，不像Hadoop归档一样。此外，序列化文件可以被分成更小的块，而且MapReduce可以以独立的方式来操作它们。转换为序列化文件可能需要一些时间，并这个方法主要是依赖于java的，即，它不提供一个跨平台方式。5建议的解决方案建议的解决方案维持了上一章所列出的现有解决方案的优点，并且试图去避免它们的缺点。虽然Hadoop的归档成功分组小文件，读操作仍然会很慢，因为它需要读取两个索引文件和一个最终的数据文件。另一方面，序列化文件是有效的数据处理方式，但是它对平台完全依赖。我们提出了一种自动分析输入数据块大小的方法。如果它小于HDFS的默认块大小，它会自动降低的数量减少任务到一个最佳数目。这是基于Hadoop的每一个Reduce任务的输出，而不管Reduce任务可能不会产生任何数据这一事实。此外，压缩是被允许的。建议在一个独立于平台的实现方式上用这种方法。在执行MapReduce任务的时候，这种方法将跟踪内存剩余空间，保证了一个文件最低的解压空间是可用的。因为要求在他们的原始文件，未压缩格式。既然归档不是用这种方式完成的，那么读操作可以用正常的方式进行，虽然写操作将需要所要求的解压缩的文件中进行。与可能会使用超过所需要的时间的转换成序列化的文件的方法不同，这种方法有效地分析手头的输入任务，决定了块的大小，并相应设置的reduce任务的数目。并且该方法中，提出了被实现为工具，可以被用于早些的Hadoop版本中，那些版本没有归档这个工具。在社交网络上进行的一项研究发现，许多地方仍在使用Hadoop的原版本， 这意味着，该方法可以帮助他们提高它们所使用的版本的性能。6结论Hadoop的在有效地进行大量的计算中的作用是显而易见的。Hadoop有很大的潜力。这是因为独特的分布式计算的方法和最终合并的结果。伴随着被定制的高效的文件系统保证全部潜力的发挥。我们已经讨论了所面临的Hadoop的一个缺点，在某些环境中，那里有大量的小文件降低Hadoop的性能。简要解释了两种现有的解决方案，以及它们各自的优点和缺点。最后，我们提出了结合现有解决方案的优点的解决方案。同时筛选出他们所面对的缺点。提出的解决方案，完全实施后，预计将提高Hadoop在所谓的小文件问题导致性能下降问题中的性能。7未来的工作在我们的工作的下一个里程碑将是成功提高输入文件本质上是小的情况下的hadoop运算效率。这方面的一个扩展可以是一个能够有效地管理小文件，无论是本身就是小文件还是其他的情况，这样能更加方便程序员编程，使他们减少对分布式复杂性的考虑。参考文献1. Dean, J., Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters.In: Proceedings of the 6th Symposium on Operating Systems Design andImplementation, San Francisco CA (December 2004)2. Shvachko, K., Kuang, H., Radia, S., Chansler, R.: The Hadoop Distributed FileSystem. In: Proceedings of the 26th IEEE Symposium on Massive Storage Systemsand Technologies (May 2010)3. Mackey, G., Sehrish, S.,Wang, J.: ImprovingMetadata Management for Small Filesin HDFS. In: Proceedings of IEEE International Conference on Cluster Computingand Workshops, pp. 14 (August 2009)4. Satyanarayanan, M.: A Survey of Distributed File Systems, Technical ReportCMU-CS-89- 116, Department of Computer Scie