Snappy 是可拆分的还是不可拆分的？

Question

根据这个Cloudera post，Snappy 是可拆分的。

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

但是从 hadoop 权威指南来看，Snappy 是不可拆分的。

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

Answer 1

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

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

需要注意的一点是，Snappy 旨在与 a
容器格式，如序列文件或 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 块的文件可拆分。

Answer 2

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

Answer 3

我刚刚在 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）。

Answer 4

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

要了解使用 snappy 压缩压缩 parquet 文件时发生的情况，请检查 parquet 文件的结构 [来源 link]

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

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

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