壓縮優缺點
優點：節省磁盤空間，提升磁盤利用率，加速磁盤/網絡IO；
缺點：解壓/壓縮是需要CPU的，壓縮會使集羣cpu利用率高，所以當集羣負載高了就不要使用壓縮了；
總結來說，需不需要使用壓縮是磁盤和CPU的取捨，也反映了大數據層面的任何調優都不是萬能的，都需要根據實際需求來做調優。
壓縮格式
大數據中常用的壓縮格式：Bzip2，Gzip，Lzo，Lz4，Snappy
在具體的情況下到底選用哪種壓縮方式主要是由壓縮比、壓縮速度、是否支持分片來決定的。另外，因爲壓縮比和壓縮速度是成反比的，所以比較了壓縮比實際上也就比較了壓縮速度：
- 從壓縮比方面考慮：
![在這裏插入圖片描述]()
壓縮比：Snappy < Lz4 < Lzo < Gzip < Bzip2
Bzip2和Gzip是一個級別的，壓縮比都比較大；
Snappy的壓縮比是最小的，所以也是壓縮速度最快的，所以很多時候如果更看重壓縮速度，就選擇使用Snappy壓縮 - 從是否分片考慮
Bzip2 默認支持分片
Lzo 默認不支持分片，但是建立索引後支持壓縮
壓縮的使用場景
以 Flume採集數據，經過MapReduce任務做ETL，最後數據輸入到HDFS爲例：
- Input過程：將數據輸入到hadoop集羣，準備做ETL任務。這個過程是肯定需要做壓縮的，因爲涉及到網絡的傳輸。選用什麼壓縮格式？由於準備要做ETL操作，需要使用MapReduce/Spark，如果不支持分片的話，就只有一個MapTask，速度就很慢。
Flume --可分片的壓縮–> HDFS 之後在HDFS上解壓 - Temp：因爲之後就要進行Shuffle的操作，沒有必要使用高壓縮比的，而且之前已經分片過了，所以只需要使用速度快的壓縮方式，通常使用Snappy壓縮
Map --壓縮（快速的）–> shuffle --解壓–>Reduce - Output過程：選哪種壓縮需要看場景，看之後數據是直接落地了還是還需要再操作，如果作爲下一個作業的輸入，這個過程就得考慮是否需要分片
Reduce --壓縮–> 之後 (這種情況的壓縮需要分情況，如果這個數據結果歸檔了，就需要高壓縮比的；如果這個數據結果要作爲下一個MapReduce的輸入，則需要可分片的)
MapTask的決定因素
MapTask的數量是由InputFormat來指定的，InputFormat生成多少個InputSpilt就會有多少個task。
之前總有誤區，一個block會有一個MapTask，這是因爲InputFormat對於每個文件，默認是一個block生成一個InputSplit。所以在上面的Input過程有些蒙圈，覺得落入HDFS上的文件，在使用沒有分片能力的壓縮格式下，爲什麼只能有一個MapTask？其實這時候，壓縮後的文件落入HDFS後，也分成了很多很多block，但是這時候的InputSplit不再是根據block的數量，而是根據壓縮格式的類型。所以不能分片的壓縮格式下，生成的文件只能有一個MapTask。