轉：http://www.cnblogs.com/gaopeng527/p/4934474.html
當大片連續區域進行數據存儲并且存儲區域中數據重復性高的狀況下，數據適合進行壓縮。數組或者對象序列化后的數據塊可以考慮壓縮。所以序列化后的數據可以壓縮，使數據緊縮，減少空間開銷。
1. Spark對壓縮方式的選擇
壓縮采用了兩種算法：Snappy和LZF，底層分別采用了兩個第三方庫實現，同時可以自定義其他壓縮庫對Spark進行擴展。Snappy提供了更高的壓縮速度，LZF提供了更高的壓縮比，用戶可以根據具體需求選擇壓縮方式。壓縮格式及解編碼器如下。
·LZF：org.apache.spark.io.LZFCompressionCodec。
·Snappy：org.apache.spark.io.SnappyCompressionCodec。
壓縮算法的對比，如圖4-9所示。
（1）Ning-Compress
Ning-compress是一個對數據進行LZF格式壓縮和解壓縮的庫，這個庫是T
atuSaloranta（tatu.saloranta@iki .fi）書寫的。用戶可以在Github地址：https://github.com/ning/compress下載，進行學習和研究。
（2）snappy-java
Snappy算法的前身是Zippy，被Google用于MapReduce、BigTable等許多內部項目。snappy-java由谷歌開發，是以C++開發的Snappy壓縮解壓縮庫的Java分支。Github地址為：https://github.com/xerial /snappy-java。Snappy的目標是在合理的壓縮量情況下，提供高壓縮速度的庫。
因此Snappy的壓縮比和LZF差不多，并不是很高。根據數據集的不同，壓縮比能達到20%~100%。有興趣的讀者可以看一個壓縮算法Benchmark，它對基于JVM運行語言的壓縮庫進行對比。
這個Benchmark對snappy-java和其他壓縮工具LZO-java/LZF/Qui ckLZ/Gzip/Bzip2進行了比較。地址為Github。
這個Benchmark是由Tatu Saloranta@cotowncoder開發的。
Snappy通常在達到相當壓縮的情況下，要比同類的LZO、LZF、FastLZ和Qui ckLZ等快速的壓縮算法快。它對純文本的壓縮比大概是1.51.7x，對HTML網頁是24x，對圖片等二進制數據基本沒有壓縮，為1x。Snappy分別對64位和32位處理器進行了優化，不論是32位處理，還是64位處理器，都能達到很高的效率。據官方介紹，Snappy經過PB級別的大數據的考驗，穩定性方面沒有問題，Google的map reduce、rpc等很多框架都用到了Snappy壓縮算法。
2. 在Spark程序中使用壓縮
用戶可以通過下面兩種方式配置壓縮。
（1）在Spark-env.sh文件中配置 用戶可以在啟動前配置文件spark-env.sh設定壓縮配置的參數。
export SPARK_JAVA_OPTS="-Dspark.broadcast.compress"
（2）在應用程序中配置 sc是SparkContext對象，conf是SparkConf對象。
val conf=sc.getConf
1）獲取壓縮的配置。
conf.getBoolean（"spark.broadcast.compress"，true）
2）壓縮的配置。
conf.set（"spark.broadcast.compress"，true）
其他參數如表4-2所示：
在分布式計算中，序列化和壓縮是兩個重要的手段。Spark通過序列化將鏈式分布的數據轉化為連續分布的數據，這樣就能夠進行分布式的進程間數據通信，或者在內存進行數據壓縮等操作，提升Spark的應用性能。通過壓縮，能夠減少數據的內存占用，以及IO和網絡數據傳輸開銷。
