Hadoop不适用于许多小文件，而是需求更少的大文件。这可能是您之前听过的声明。但是，为什么Hadoop会呈现许多小文件的问题？并且，“小”究竟是什么意思呢？在本系列的榜首部分中，我将回答这些问题。后续部分将评论处理或处理小文件问题。

什么是小文件？

小文件能够定义为任何显着小于Hadoop块巨细的文件。Hadoop块巨细一般设置为64,128, 256 MB，越来越大。在本博客的其余部分供给示例时，咱们将运用128MB的块巨细。假如一个文件的巨细不是块巨细的75%，那么它便是一个小文件。然而，小文件问题并不只是影响小文件。假如Hadoop集群中的许多文件略微大于块巨细的增量，那么您将遇到与小文件相同的应战。

例如，假如您的块巨细为128MB，但加载到Hadoop的一切文件都是136MB，那么您将具有许多小的8MB块。好消息是处理小块问题就像挑选适宜的（较大的）块巨细一样简略。处理小文件问题要杂乱得多。留意我从来没有说到行数。虽然行数能够影响MapReduce功能，但在确定如何将文件写入HDFS时，它远不如文件巨细重要。

为什么会呈现小文件？

小文件问题是咱们经常在Hadoop项目中看到的问题。公司可能在Hadoop中具有小文件的原因有许多，包括：

  • 公司越来越渴望能够实时取得数据，导致Hadoop吸取进程每小时/每周/每周运转，每个周期只生成10MB的新数据。
  • 源系统生成数千个小文件，这些文件无需修改即可直接复制到Hadoop中。
  • MapReduce作业的配置运用超越必要数量的reducer，每个reduceup输出自己的文件。相同，假如数据中的偏差导致大部分数据转到一个减速器，那么剩下的减速器将处理十分少的数据并发生小的输出文件。

为什么Hadoop有一个小文件问题？

Hadoop存在小文件问题有两个主要原因：NameNode内存办理和MapReduce功能。namenode内存问题Hadoop中的每个目录，文件和块都表明为NameNode内存中的对象。依据经历，每个对象需求150个字节的内存。假如你有2000万个文件，每个文件需求1个块，你的NameNode需求6GB的内存。这显然是十分可行的，但随着您的扩展，您最终会到达NameNode能够处理的文件（块）数量的实际约束。十亿个文件需求300GB的内存，并假设每个文件都在同一个文件夹中！让咱们考虑300GB NameNode内存要求的影响……

  • 当NameNode从头发动时，它有必要从本地磁盘上的缓存中读取每个文件的元数据。这意味着从磁盘读取300GB的数据 – 可能会导致发动时刻延迟。
  • 在正常操作中，NameNode有必要不断盯梢并检查群集中每个数据块的存储方位。这是经过监听数据节点来陈述其一切数据块来完成的。数据节点有必要陈述的块越多，它将耗费的网络带宽就越多。即使节点之间存在高速互连，这种规模的简略块陈述也可能会造成破坏性。

优化很显着。假如能够削减群集中的小文件数，则能够削减NameNode内存占用，发动时刻和网络影响。

MapReduce的功能问题

具有许多小文件会下降MapReduce处理的功能，无论是Hive，Pig，Cascading，Pentaho MapReduce还是Java MapReduce。榜首个原因是许多的小文件意味着许多的随机磁盘IO。磁盘IO一般是MapReduce功能的最大约束要素之一。一次大的次序读取总是胜过经过几回随机读取相同数量的数据。假如您能够将数据存储在更少，更大的块中，则能够减轻磁盘IO的功能影响。

功能下降的第二个原因有点杂乱，需求了解MapReduce如何处理文件和调度资源。我将在此解说中运用MapReduce版别1术语，由于它比运用Yarn更容易解说，但相同的概念适用于Yarn。当MapReduce作业发动时，它会为每个正在处理的数据块方案一个映射使命。存储在Hadoop中的每个文件至少有一个块。假如您有10,000个文件，每个文件包含10 MB的数据，则MapReduce作业将组织10,000个map使命。一般配置Hadoop，以便每个map使命在其自己的JVM中运转。

您的Hadoop集群只有这么多资源。在MapReduce v1中，为防止节点过载，请指定节点能够处理的最大并发map数。一般，map的最大数量在5到20范围内。因此，要同时运转10,000个map，您有必要具有500到2000个节点。大多数Hadoop集群都小于此，导致JobTracker在等候打开的插槽时对map使命进行排队。假如您有一个包含总共100个插槽的20个节点群集，则您的队列将变得十分大，并且您的进程将花费很长时刻。不要忘掉，您的作业可能不是竞赛集群资源的唯一作业。

假如您具有800个128 MB的文件而不是10,000个10MB文件，那么您只需求800个map使命。这将需求一个数量级削减JVM维护时刻，并将导致更好的磁盘IO。即使处理128 MB的单个map使命将花费比处理10 MB的map使命处理更长的时刻，但是当处理800个更大的文件时，一切处理时刻的总和几乎总是要快几个数量级。

假如你有小文件，你会怎么做？

现在咱们已经评论了什么构成一个小文件以及为什么Hadoop更喜爱更大的文件，你如何防止小文件问题？在下一篇文章中，我将评论NameNode内存问题的处理方案以及处理MapReduce功能问题的一些初始方案。在本系列一篇文章中，我将评论功能问题的其他处理方案以及如何为您的情况挑选最佳处理方案。