HDFS小文件问题解决方案与启发实践

前言

---

继上文聊聊HDFS BlockManager的服务化改造之后，本文我们继续来讨论HDFS扩展性相关的问题。在本文的阐述过程中，我们将通过一个平时遇到的典型问题-HDFS小文件过多问题作为贯穿全文的一个核心要点。在下文中，笔者将会介绍小文件的缘由，现有解决办法，新的解决方案等等内容。

小文件的产生以及影响

---

这里“小文件”的一个标准定义不应该说是绝对大小非常小的文件，这样说不够准确，而是应该值不满足一个块大小并且文件本身非常小的文件（比如大量不大1MB的文件）。小文件产生过多的原因很大一部分归结于用户的应用程度在执行的时候没有很好的预估写出数据量的规模，导致写出过多的小文件。

如果小文件产生过多了，它会有什么严重的影响呢?主要为下面2点：

• 加重HDFS的namespace命名空间，因为过多的小文件意味着更多文件元数据信息需要NameNode来保存了。
• 读取小文件数据的任务执行时，消耗过多的集群资源。因为map task在执行的时候一般只处理1个文件，如果这个时候要读取的文件过多，就会造成大量的map task启动。

以上两点影响中第二点可能会被大家所忽视。下面我们来看现有条件下的
几种解决方案。

现有小文件问题解决方案

---

小文件问题往往在集群数据规模迅速扩张的时候被暴露出来，它的影响不是说本身占据了多少存储空间，而是说它会大大加大NameNode的负载，从而会影响到NameNode的性能问题。在现有的Hadoop系统中，有什么办法可以解决小文件问题呢？在cloudera官方的一篇博客（博客链接可见本文末尾链接处）中，给了我们一个很好的答案。下面是笔者对其的简要概括。

第一个解决方案，通过文件归档的方式进行处理。文件归档在这里的意思是将文件再次进行整理和保存，使之更易管理和保存。而Hadoop中的归档是在HDFS之上又构建了一个新的抽象层，叫HAR（Hadoop Archives ），访问的格式变为了har:// URL。它的实现原理如下图1-1所示。

图 1-1 Hadoop 归档原理

从上图我们可以看出，Hadoop在归档文件时通过二层索引文件的查找