17

根据这篇Cloudera 帖子，Snappy 是可拆分的。

对于 MapReduce，如果您需要压缩数据可拆分，BZip2、LZO 和 Snappy 格式是可拆分的，但 GZip 不是。可拆分性与 HBase 数据无关。

但是从 hadoop 权威指南来看，Snappy 是不可拆分的。 在此处输入图像描述

网上也有一些矛盾的信息。有人说它是可拆分的，有人说它不是。

4

4 回答 4

33

两者都是正确的，但水平不同。

根据 Cloudera 博客http://blog.cloudera.com/blog/2011/09/snappy-and-hadoop/

需要注意的一点是，Snappy 旨在用于
容器格式，如序列文件或 Avro 数据文件，而不是直接用于纯文本，例如，因为后者不可拆分且无法处理并行使用 MapReduce。这与 LZO 不同，LZO 可以通过索引 LZO 压缩文件来确定分割点，以便在后续处理中高效处理 LZO 文件。

这意味着如果使用 Snappy 压缩整个文本文件，则该文件不可拆分。但是，如果文件中的每条记录都使用 Snappy 进行压缩，则该文件可以是可拆分的，例如在具有块压缩的序列文件中。

说得更清楚一点，是不一样的：

<START-FILE>
  <START-SNAPPY-BLOCK>
     FULL CONTENT
  <END-SNAPPY-BLOCK>
<END-FILE>

比

<START-FILE>
  <START-SNAPPY-BLOCK1>
     RECORD1
  <END-SNAPPY-BLOCK1>
  <START-SNAPPY-BLOCK2>
     RECORD2
  <END-SNAPPY-BLOCK2>
  <START-SNAPPY-BLOCK3>
     RECORD3
  <END-SNAPPY-BLOCK3>
<END-FILE>

Snappy 块不可拆分，但带有 snappy 块的文件是可拆分的。

于 2015-09-07T02:40:51.587 回答
4

hadoop 中的所有可拆分编解码器都必须实现org.apache.hadoop.io.compress.SplittableCompressionCodec. 查看截至2.7的hadoop源代码，我们看到org.apache.hadoop.io.compress.SnappyCodec没有实现这个接口，所以我们知道它是不可拆分的。

于 2016-08-26T16:03:47.573 回答
4

我刚刚在 HDFS 上使用 Spark 1.6.2 测试了相同数量的工人/处理器，在一个简单的 JSON 文件之间并由 snappy 压缩：

  • JSON：4个文件，每个12GB，Spark创建388个任务（HDFS块1个任务）（4*12GB/128MB => 384）
  • Snappy：4 个文件，每个 3GB，Spark 创建 4 个任务

Snappy 文件是这样创建的：.saveAsTextFile("/user/qwant/benchmark_file_format/json_snappy", classOf[org.apache.hadoop.io.compress.SnappyCodec])

所以 Snappy 不能使用 Spark for JSON 进行拆分。

但是，如果您使用parquet（或 ORC）文件格式而不是 JSON，这将是可拆分的（即使使用 gzip）。

于 2018-09-06T19:21:23.107 回答
2

Snappy 实际上不像 bzip 那样可拆分，但是当与 parquet 或 Avro 等文件格式一起使用时，不是压缩整个文件，而是使用 snappy 压缩文件格式中的块。

要了解使用 snappy 压缩压缩 parquet 文件时发生了什么，请检查 parquet 文件的结构 [源链接]

在此处输入图像描述

在 parquet 文件中，记录被分成行组[基本上是原始文件中行的子集]，每个行组由数据页组成 [图像中的列块]，每个列块由许多页组成其中实际记录以编码格式 [columnar] 与元数据一起存储。当您启用快速压缩时，它会压缩整个页面！不是整个文件。基本上你得到了一个具有快速压缩的可拆分镶木地板。

snappy 的优点是它是一个非常轻量级的压缩编解码器。

注意：行组和列块有一个默认大小限制，分别为 128MB 和 1MB [您可以更改这些默认设置]，您可以使用不同的压缩编解码器和 parquet，例如 gzip

于 2020-09-17T14:39:24.830 回答