Spark每日半小时（20）——文件压缩

在大数据工作中，我们经常需要对数据进行压缩以节省空间和网络传输开销。对于大多数Hadoop输出格式来说，我们可以指定一种压缩编解码器来压缩数据。我们已经提过，Spark原生的输入方式（textFile和sequenceFile）可以自动处理一些类型的压缩。在读取压缩后的数据时，一些压缩编解码器可以推测压缩类型。

这些压缩选项只适用于支持压缩的Hadoop格式，也就是那些写出到文件系统的格式。写入数据库的Hadoop格式一般没有实现压缩支持。如果数据库中有压缩过的记录，那应该是数据库自己配置的。

选择一个输出压缩编解码器可能会对这些数据以后的用户产生巨大影响。对于像Spark这样的分布式系统，我们通常会尝试从多个不同机器上一起读入数据。要实现这种情况，每个工作节点都必须能够找到一条新纪录的开端。有些压缩格式会使这变得不可能，而必须要单个节点来读入所有数据，这就很容易产生性能瓶颈。可以很容易地从多个节点上并行读取地格式被称为“可分割”的格式。

压缩选项

格式	可分割	平均压缩速度	文本文件压缩效率	Hadoop压缩编解码器	纯Java实现	原生	备注
gzip	否	快	高	org.apache.hadoop.io.compress.GzipCodec	是	是
lzo	是	非常快	中等	com.hadoop.compression.lzo.LzoCodec	是	是	需要在每个节点上安装LZO
bzip2	是	慢	非常高	org.apache.hadoop.io.compress.Bzip2Codec	是	是	为可分割版本使用纯Java
zlib	否	慢	中等	org.apache.hadoop.io.compress.DefaultCodec	是	是	Hadoop的默认压缩编解码器
Snappy	否	非常快	低	org.apache.hadoop.io.compress.SnappyCodec	否	是	Snappy有纯Java的移植版，但是在Spark/Hadoop中不能用

尽管Spark的textFile()方法可以处理压缩过的输入，但即使输入数据被以可分割读取的方式压缩，Spark也不会打开splittable。因此，如果你要读取单个压缩过的输入，最好不要考虑使用Spark的封装，而是使用newAPIHadoopFile或者hadoopFile，并指定正确的压缩编解码器。

有些输入格式（例如SequenceFile）允许我们只压缩键值对数据中的值，这在查询时很有用。其他一些输入格式也有自己的压缩控制：比如，Twitter的Elephant Bird包中的许多格式都可以使用LZO算法压缩的数据。