我最近一直在研究 hadoop 和 HDFS。当您将文件加载到 HDFS 中时，它通常会将文件拆分为 64MB 的块并将这些块分布在您的集群中。除非它不能对 gzip 文件执行此操作，因为 gzip 文件无法拆分。我完全理解为什么会这样（我不需要任何人解释为什么不能拆分 gzip 文件）。但是为什么 HDFS 不能将纯文本文件作为输入并像平常一样拆分它，然后分别使用 gzip 压缩每个拆分？当访问任何拆分时，它只是在运行中解压缩。
在我的场景中，每个拆分都是完全独立压缩的。拆分之间没有依赖关系，因此您不需要整个原始文件来解压缩任何一个拆分。这就是这个补丁所采用的方法：https ://issues.apache.org/jira/browse/HADOOP-7076 ，请注意这不是我想要的。
这似乎很基本......我错过了什么？为什么不能这样做？或者如果可以做到，hadoop 开发人员为什么不看这条路呢？考虑到我发现有多少关于人们想要在 HDFS 中拆分 gzip 文件的讨论，这似乎很奇怪。
原因很简单，就是“关注点分离”的设计原则。
如果你按照你的建议去做，那么 HDFS 必须知道文件的实际位和字节的含义。还必须使 HDFS 能够对其进行推理（即提取、解压缩等）。一般来说，您不希望在软件中混合这种责任。
因此，理解位含义的“唯一”部分是必须能够读取它的应用程序：这通常使用 Hadoop 的 MapReduce 部分编写。
正如 HADOOP-7076 的 Javadoc 中所述（我写了那个东西；））：
永远记住，还有其他方法：
- 解压缩原始 gzip 文件，将其拆分为多个片段，然后重新压缩这些片段，然后再将它们提供给 Hadoop。
例如： 拆分 gzip 压缩的日志文件而不将未压缩的拆分存储在磁盘上- 解压缩原始 gzip 文件并使用不同的可拆分编解码器进行压缩。例如 BZip2Codec 或根本不压缩。
高温高压
HDFS 的范围有限，仅作为分布式文件系统服务，不执行诸如压缩数据之类的繁重操作。数据压缩的实际过程委托给分布式执行框架，如 Map-Reduce、Spark、Tez 等。因此数据/文件的压缩是执行框架的关注点，而不是文件系统的关注点。
此外，Sequence-file、Parquet 等容器文件格式的存在消除了 HDFS 自动压缩数据块的需要，如问题所建议的那样。
因此，总而言之，由于设计理念的原因，任何数据压缩都必须由执行引擎完成，而不是由文件系统服务完成。