为啥 hadoop 不能拆分一个大文本文件，然后使用 gzip 压缩拆分？

Posted 2023-03-06

【中文标题】为啥 hadoop 不能拆分一个大文本文件，然后使用 gzip 压缩拆分？

【英文标题】：Why can't hadoop split up a large text file and then compress the splits using gzip?为什么 hadoop 不能拆分一个大文本文件，然后使用 gzip 压缩拆分？

【发布时间】：2011-06-28 18:20:46

【问题描述】：

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

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

这看起来很基本......我错过了什么？为什么不能这样做？或者如果可以做到，hadoop 开发人员为什么不看这条路呢？考虑到我发现了很多关于人们想要在 HDFS 中拆分 gzip 文件的讨论，这似乎很奇怪。

【问题讨论】：

我只是想为这个问题添加评论。我正在考虑的将与 git 对其对象存储中的对象所做的完全一样。每个单独的 blob、提交和树对象在保存到磁盘之前都经过 zlib 压缩。这与实际对象是什么无关，并且在 git 管道“之上”工作的任何工具都不需要了解有关压缩格式的任何信息。

【参考方案1】：

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

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

因此，理解位含义的“唯一”部分是必须能够读取它的应用程序：这通常使用 Hadoop 的 MapReduce 部分编写。

正如 HADOOP-7076 的 Javadoc 中所述（我写了那个东西；））：

永远记得有 替代方法：

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

HTH

【讨论】：

Hadoop 不必知道这些位的含义，就像它对可拆分的 bzip2 一样。我只是在谈论拆分完成后如何存储数据。因此，将文件拆分为 67108864 字节的块（对这些位和字节一无所知），然后在存储之前压缩每个块。我想我更多地将其视为一种存储后端格式，而不是实际的文件格式。这样，绝对可以使用任何压缩算法。

另外，bzip2 直到 0.21 才真正可拆分，这并不稳定。谁知道什么时候会发布 0.22。

HDFS 级别的 64M 块仅与这些文件如何放置在集群的数据节点上有关。此外，如果您的 gzipped 文件更大，这将对这些 GZipped 文件的作业性能产生负面影响。

HDFS 也不知道文件的位和字节是什么意思。对于 HDFS，HDFS 块和 HDFS 文件之间没有太大区别。有些文件只位于一个块中..

【参考方案2】：

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

此外，Sequence-file、Parquet 等容器文件格式的存在使 HDFS 无需按照问题的建议自动压缩数据块。

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

【讨论】：

我想实现我的想法，你可以简单地使用一个支持透明压缩的文件系统，用于数据节点用于存储块的所有卷。

您的意思是基于硬件的压缩？...不包括此功能可能是 HDFS 实施者有意识的决定。他们将来可能会包括它..

不是硬件压缩。许多像 zfs 这样的文件系统可以进行透明压缩。