Question

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

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

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

网上也有一些令人信服的信息。有人说它可以拆分，有些人说它不是。

Answer 1

两者都是正确的，但处于不同的层次。

根据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块 NOT splittable 但带有snappy块的文件是splittables 。

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个任务

创建的快照文件如下：type(self).var

因此Snappy无法通过Spark for JSON进行拆分。

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

Answer 4

Snappy实际上不能作为bzip进行拆分，但是当与镶木地板或Avro等文件格式一起使用时，不是压缩整个文件，而是使用snappy压缩文件格式中的块。

要了解使用活泼的压缩方式压缩镶木地板文件时发生的情况，请检查镶木地板文件的结构[源link]

在拼花文件中，记录被分为行组（基本上是原始文件中的行的子集），每个行组由数据页组成（图像中的列块），每个列块都由组成实际记录以元数据的编码格式存储在许多页面中。启用快照压缩后，它将压缩整个页面！不是整个文件。基本上，您将获得可压缩的可拆分实木复合地板。

snappy的优点是它是一种重量很轻的压缩编解码器。

注意：行组和列块分别有默认大小限制，分别为128MB和1MB [您可以更改这些默认设置]，您可以在实木复合地板上使用其他压缩编解码器，例如gzip

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

4 个答案: