根据cloudera的帖子，snappy是可拆分的。对于mapreduce，如果您需要压缩的数据是可拆分的，bzip2、lzo和snappy格式是可拆分的，但是gzip不是。可拆分性与hbase数据无关。但是从hadoop权威指南来看，snappy是不可拆分的。网上也有一些限制性的信息。有人说它是可拆分的，有人说它不是。
yk9xbfzb1#
我刚刚在hdfs上用spark 1.6.2测试了相同数量的worker/处理器，在一个简单的json文件和snappy压缩之间：json:4个12gb文件，spark创建388个任务（1个hdfs块任务）（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）。
.saveAsTextFile("/user/qwant/benchmark_file_format/json_snappy", classOf[org.apache.hadoop.io.compress.SnappyCodec])
sc4hvdpw2#
hadoop中的所有可拆分编解码器都必须实现 org.apache.hadoop.io.compress.SplittableCompressionCodec . 查看2.7版本的hadoop源代码，我们可以看到 org.apache.hadoop.io.compress.SnappyCodec 没有实现这个接口，所以我们知道它是不可拆分的。
org.apache.hadoop.io.compress.SplittableCompressionCodec
org.apache.hadoop.io.compress.SnappyCodec
j91ykkif3#
两者都是正确的，但层次不同。根据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块的文件是可拆分的。
lbsnaicq4#
snappy实际上并不像bzip那样可拆分，但是当与parquet或avro这样的文件格式一起使用时，文件格式中的块不是压缩整个文件，而是使用snappy进行压缩。要了解使用snappy压缩压缩Parquet文件时发生的情况，请检查Parquet文件的结构[源链接]在Parquet文件中，记录被分成行组[基本上是原始文件中的行的子集]，每个行组由数据页[图像中的列块]组成，每个列块由许多页组成，其中实际记录以编码格式[列]和元数据存储。启用snappy压缩时，它会压缩整个页面！不是整个文件。基本上，你得到一个分裂Parquet与快速压缩。snappy的优点是它是一个非常轻量级的压缩编解码器。注：行组和列块有一个默认大小限制，分别为128mb和1mb[您可以更改这些默认设置]，您可以使用不同的压缩编码解码器，例如gzip
4条答案
按热度按时间yk9xbfzb1#
我刚刚在hdfs上用spark 1.6.2测试了相同数量的worker/处理器，在一个简单的json文件和snappy压缩之间：
json:4个12gb文件，spark创建388个任务（1个hdfs块任务）（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）。
sc4hvdpw2#
hadoop中的所有可拆分编解码器都必须实现
org.apache.hadoop.io.compress.SplittableCompressionCodec. 查看2.7版本的hadoop源代码，我们可以看到org.apache.hadoop.io.compress.SnappyCodec没有实现这个接口，所以我们知道它是不可拆分的。j91ykkif3#
两者都是正确的，但层次不同。
根据cloudera博客http://blog.cloudera.com/blog/2011/09/snappy-and-hadoop/
需要注意的一点是，snappy用于
容器格式，如序列文件或avro数据文件，而不是直接用于纯文本，例如，因为后者是不可拆分的，不能使用mapreduce并行处理。这与lzo不同，在lzo中可以索引lzo压缩文件以确定分割点，以便在后续处理中可以有效地处理lzo文件。
这意味着，如果使用snappy压缩整个文本文件，则该文件不可拆分。但是，如果文件中的每个记录都是用snappy压缩的，那么文件可能是可拆分的，例如在带有块压缩的序列文件中。
更清楚地说，这是不一样的：
比
snappy块不是可拆分的，但是具有snappy块的文件是可拆分的。
lbsnaicq4#
snappy实际上并不像bzip那样可拆分，但是当与parquet或avro这样的文件格式一起使用时，文件格式中的块不是压缩整个文件，而是使用snappy进行压缩。
要了解使用snappy压缩压缩Parquet文件时发生的情况，请检查Parquet文件的结构[源链接]
在Parquet文件中，记录被分成行组[基本上是原始文件中的行的子集]，每个行组由数据页[图像中的列块]组成，每个列块由许多页组成，其中实际记录以编码格式[列]和元数据存储。启用snappy压缩时，它会压缩整个页面！不是整个文件。基本上，你得到一个分裂Parquet与快速压缩。
snappy的优点是它是一个非常轻量级的压缩编解码器。
注：行组和列块有一个默认大小限制，分别为128mb和1mb[您可以更改这些默认设置]，您可以使用不同的压缩编码解码器，例如gzip