Snappy是可拆分还是不可拆分?

时间:2015-09-03 17:51:20

标签: hadoop snappy

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

  

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

但是从hadoop权威指南来看,Snappy是不可拆分的。 enter image description here

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

4 个答案:

答案 0 :(得分:23)

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

根据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

答案 1 :(得分:3)

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

答案 2 :(得分:0)

我刚在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也是如此)。

答案 3 :(得分:0)

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

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

enter image description here

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

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

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