java - 在 Hadoop HDFS 中存储小文件的方法，而不是 HAR 或 Sequence Files + 对它们的疑惑

Question

我已经阅读了很多博客条目和关于“hadoop 中的小文件问题”的文章，但是其中很多似乎只是复制粘贴以前的。此外，它们似乎都有点过时，最后一个(2015 年左右)描述的是什么 this cloudera blog 2009年初做的。
这是否意味着 6 年内没有找到归档解决方案？

这是我研究的原因:我需要移动和编目文件，当它们以不同的数量出现时，有时甚至是单个文件，然后将它们存储在 HDFS 中 .
这些文件将稍后被访问并返回到网络服务层(必须很快)，以供人或软件打开和查看。
这些文件可能是视频、图像、文档等等，以后需要使用我用 Java 类 UUID 生成的 ID 进行访问。
使用 hdfs 的选择完全由我的 PM 个人决定，因为我建议使用 HBase 来弥补 HDFS 中索引不足的问题(尽管我不确定这是一个最佳解决方案)，但他有要求我无论如何都要查看 HBase 之外的文件，以防不得不处理更大的文件(到目前为止，1000 个文件中最大的文件是 2MB，但我们希望有 1Gb 的视频)。
据我了解，当您使用 MapReduce 作业时会发生小文件问题，因为内存消耗，但我想知道:
如果我使用 Spark 提取文件，HDFS 中有多少文件真的很重要吗？或者如果我使用的是 webhdfs/v1/？还是 Java？

关于存储一组小文件，目前我找到了三种主要的解决方案，它们在生产环境中都非常不方便:

• HAR:索引文件提取看起来棒极了，但我无法追加或添加新文件这一事实相当麻烦。 HAR 的打开和重新创建对系统的影响很大吗？
• 序列文件具有相反的优点和缺点:您可以附加文件，但它们没有索引，因此查找时间为 O(n) . 值得吗？
• 合并它们:在我的情况下不可能。

关于这个常见问题，我是否遗漏了一些新技术？文件是 Avro 还是 Parquet？

Answer 1

这里是对您的解决方案的一些反馈:

a) HAR 不可追加。您可以通过 HDFS 命令行界面使用新文件取消存档和存档 har 存档。这两种方法都作为 MapReduce 作业实现，因此执行时间取决于您的计算集群以及存档文件的大小。我和我的同事使用和开发AHAR .一种允许您更有效地附加数据而无需重写整个存档的工具。

b) 据我所知，您的索引查找时间长是对的。但请注意，由于两步索引策略，使用 HAR 时您的查找时间也更长。

这post为您提供了关于小文件问题和可能解决方案的非常好的概述。也许您可以“只是”增加 NameNode 的内存。