我读过很多关于“hadoop中的小文件问题”的博客和文章，但其中很多似乎只是前一篇文章的复制粘贴。此外，它们似乎都有点过时，最后一个（2015ish）描述了这个cloudera博客在2009年初所做的一切。
这是否意味着6年来没有找到归档解决方案？
这就是我研究的原因：我需要移动和编目文件，因为他们来了，在不同的数字，有时甚至是单一的，然后存储在hdfs。
这些文件稍后将在web服务层中被访问和返回（必须是快速的），以供人们或软件打开和查看。
这些文件可能是视频、图像、文档等，以后需要使用java类生成的id进行访问 UUID .
选择使用hdfs完全是我的pm个人的事，因为我建议使用hbase来弥补hdfs中索引的不足（虽然我不确定这是一个最佳的解决方案），但他要求我无论如何都要注意hbase，以防处理更大的文件（到目前为止，1000个文件中最大的是2mb，但我们期望1gb的视频）。
据我所知，小文件问题发生在使用mapreduce作业时，因为内存消耗，但我想知道：
如果我使用spark提取hdfs中有多少个文件真的很重要吗？或者我使用的是webhdfs/v1/？还是java？
谈到存储一组小文件，到目前为止，我发现了三种主要的解决方案，它们在生产环境中都很不方便：
har：索引文件提取看起来很棒，但是我不能追加或添加新文件这一事实非常麻烦。hars的开放和再创造对系统有很大影响吗？
序列文件有相反的优点和缺点：您可以附加文件，但它们没有索引，因此有一个o（n）查找时间。值得吗？
合并它们：在我的情况下是不可能的。
对于这个常见的问题，我是否遗漏了一些新技术？在avro或Parquet地板上放些什么文件？