hadoop - 大量小文件和 128 Mb block 大小的 HDFS 行为

Question

我有很多(多达数十万个)小文件，每个 10-100 Kb。我的 HDFS block 大小等于 128 MB。我的复制因子等于 1。

为每个小文件分配 HDFS block 有什么缺点吗？

我见过非常矛盾的答案:

1. Answer which said the smallest file takes the whole block
2. Answer which said that HDFS is clever enough, and small file will take small_file_size + 300 bytes of metadata

我在 this answer 中做了一个测试，它证明第二个选项是正确的——HDFS 不会为小文件分配整个 block 。

但是，从 HDFS 批量读取 10.000 个小文件怎么样？它会因为 10.000 个 block 和元数据而变慢吗？是否有任何理由将多个小文件保存在一个 block 中？

更新:我的用例

我只有一个小文件用例，从 1.000 到 500.000。我计算一次这些文件，存储它，而不是一次读取它们。

1) 据我了解，NameNode 空间问题对我来说不是问题。 500.000 是绝对最大值，我永远不会拥有更多。如果每个小文件在 NN 上占用 150 个字节，那么对我来说绝对最大值是 - 71.52 MB，这是可以接受的。

2) Apache Spark 是否消除了 MapReduce 问题？序列文件或 HAR 会帮助我解决问题吗？据我了解，Spark 不应该依赖于 Hadoop MR，但它仍然太慢。读取 490 个文件需要 38 秒，读取 3420 个文件需要 266 秒。

sparkSession
    .read()
    .parquet(pathsToSmallFilesCollection)
    .as(Encoders.kryo(SmallFileWrapper.class))
    .coalesce(numPartitions);

Answer 1

正如您已经注意到的，HDFS 文件占用的空间不会超出它的需要，但是将小文件放在 HDFS 集群中还有其他缺点。让我们先解决问题而不考虑批处理:

1. NameNode(NN) 内存消耗。我不知道 Hadoop 3(目前正在开发中)，但在以前的版本中，NN 是单点故障(您可以添加辅助 NN，但它最终不会替换或增强主要 NN)。 NN 负责维护内存和磁盘上的文件系统结构，资源有限。 NN 维护的文件系统对象中的每个条目被认为是 150 字节 (check this blog post)。更多文件 = NN 消耗更多 RAM。
2. MapReduce 范式(据我所知，Spark 也有同样的症状)。在 Hadoop 中，映射器是按拆分分配的(默认情况下对应于 block )，这意味着，对于您拥有的每个小文件，都需要启动一个新的映射器来处理其内容。问题在于，对于小文件，Hadoop 启动映射器实际上比处理文件内容花费的时间要多得多。基本上，您的系统将做不必要的启动/停止映射器的工作，而不是实际处理数据。这就是 Hadoop 处理 1 个 128MBytes 文件( block 大小为 128MBytes)比处理 128 个 1MBytes 文件( block 大小相同)快得多的原因。

现在，如果我们谈论批处理，您可以选择的选项很少:HAR、序列文件、Avro 模式等。这取决于用例来准确回答您的问题。假设您不想合并文件，在这种情况下您可能正在使用 HAR 文件(或任何其他具有高效归档和索引功能的解决方案)。在这种情况下，NN 问题已解决，但 Mappers 的数量仍将等于 split 的数量。如果可以选择将文件合并成大文件，您可以使用序列文件，它基本上将小文件聚合成大文件，在一定程度上解决了这两个问题。在这两种情况下，尽管您不能真正像处理小文件那样直接更新/删除信息，因此需要更复杂的机制来管理这些结构。

一般来说，维护许多小文件的主要原因是为了快速读取，我建议看看不同的系统，如 HBase，它们是为快速数据访问而不是批处理而创建的。