问可分还是分不分？

EN

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

与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块的文件是可拆分的。

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

我刚刚在HDFS上用Spark1.6.2测试了相同数量的工作人员/处理器，在一个简单的JSON文件之间并被snappy压缩：

• JSON: 4个文件，每个12 by，Spark创建388个任务(1个任务由HDFS块完成)(4* 12GB /128 by => 384)
• Snappy: 4个文件，每个3GB，火花创建4个任务

创建Snappy文件的方式如下：.saveAsTextFile("/user/qwant/benchmark_file_format/json_snappy", classOf[org.apache.hadoop.io.compress.SnappyCodec])

因此，对于JSON来说，Spark是无法拆分的。

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