为什么hadoop不能拆分大文本文件，然后使用gzip压缩拆分？

Question

我最近一直在研究hadoop和HDFS。将文件加载到HDFS时，它通常会将文件拆分为64MB块，并在群集周围分发这些块。除非gzip文件无法执行此操作，因为无法拆分gzip文件。我完全明白为什么会这样（我不需要任何人解释为什么gzip文件无法拆分）。但是为什么HDFS不能将纯文本文件作为输入并像普通文件一样拆分，然后分别使用gzip压缩每个拆分？访问任何拆分时，它只是即时解压缩。

在我的场景中，每个分割都是完全独立压缩的。拆分之间没有依赖关系，因此您不需要整个原始文件来解压缩任何一个拆分。这是此修补程序采用的方法：https://issues.apache.org/jira/browse/HADOOP-7076，请注意这是不我想要的。

这看起来非常基本......我错过了什么？为什么不能这样做？或者如果可以做到，为什么hadoop开发人员不会忽视这条路线？考虑到我在HDFS中想要分割gzip文件的人们进行了多少讨论，这似乎很奇怪。

Answer 1

简单的原因是“关注点分离”的设计原则。

如果你按照你的建议做，那么HDFS必须知道文件的实际位和字节是什么意思。还必须使HDFS能够对其进行推理（即提取，解压缩等）。 一般来说，你不希望这种混合责任在软件中。

所以理解这些位意味着什么的“唯一”部分是必须能够读取它的应用程序：通常使用Hadoop的MapReduce部分编写。

如HADOOP-7076的Javadoc所述（我写了那篇文章;））：

  

永远记住有   替代方法：

     

  
• 解压缩原始的gzip压缩文件，将其拆分成碎片   在提供之前重新压缩碎片   他们到Hadoop。
  例如：   Splitting gzipped logfiles without storing the ungzipped splits on disk
  
• 解压缩原始gzip文件并使用其他文件进行压缩   可分割编解码器。例如   BZip2Codec或根本不压缩。
  

HTH

Answer 2

HDFS仅具有分布式文件系统服务的有限范围，并且不执行诸如压缩数据之类的繁重操作。实际的数据压缩过程被委托给Map-Reduce，Spark，Tez等分布式执行框架。因此，数据/文件的压缩是执行框架的关注，而不是文件系统的关注。

此外，像Sequence-file，Parquet等容器文件格式的存在否定了HDFS根据问题的建议自动压缩数据块的需要。

因此，总结一下，由于设计理念的原因，任何数据压缩都必须由执行引擎而不是文件系统服务来完成。