優點：節省磁碟空間，提公升磁碟利用率，加速磁碟/網路io；
缺點：解壓/壓縮是需要cpu的，壓縮會使集群cpu利用率高，所以當集群負載高了就不要使用壓縮了；
總結來說，需不需要使用壓縮是磁碟和cpu的取捨，也反映了大資料層面的任何調優都不是萬能的，都需要根據實際需求來做調優。
從是否分片考慮
bzip2 預設支援分片
lzo 預設不支援分片，但是建立索引後支援壓縮
以 flume採集資料，經過mapreduce任務做etl，最後資料輸入到hdfs為例：
input過程：將資料輸入到hadoop集群，準備做etl任務。這個過程是肯定需要做壓縮的，因為涉及到網路的傳輸。選用什麼壓縮格式？由於準備要做etl操作，需要使用mapreduce/spark，如果不支援分片的話，就只有乙個maptask，速度就很慢。
flume --可分片的壓縮–> hdfs 之後在hdfs上解壓
output過程：選哪種壓縮需要看場景，看之後資料是直接落地了還是還需要再操作，如果作為下乙個作業的輸入，這個過程就得考慮是否需要分片
reduce --壓縮–> 之後 (這種情況的壓縮需要分情況，如果這個資料結果歸檔了，就需要高壓縮比的；如果這個資料結果要作為下乙個mapreduce的輸入，則需要可分片的)
maptask的數量是由inputformat來指定的，inputformat生成多少個inputspilt就會有多少個task。
之前總有誤區，乙個block會有乙個maptask，這是因為inputformat對於每個檔案，預設是乙個block生成乙個inputsplit。所以在上面的input過程有些矇圈，覺得落入hdfs上的檔案，在使用沒有分片能力的壓縮格式下，為什麼只能有乙個maptask？其實這時候，壓縮後的檔案落入hdfs後，也分成了很多很多block，但是這時候的inputsplit不再是根據block的數量，而是根據壓縮格式的型別。所以不能分片的壓縮格式下，生成的檔案只能有乙個maptask。
在 $haoop_home/etc/hadoop/core-site.xml和mapred-site.xml配置
在命令列中 set hive.exec.compress.output=true;
set mapreduce.output.fileoutputformat.compress.codec=***;
大資料中的相關壓縮
可以在輸入端，中間資料和輸出資料段進行壓縮 並同步core site.xml到其他機器 io.compression.codecsname org.apache.hadoop.io.compress.gzipcodec,org.apache.hadoop.io.compress.defaultcod...
大資料裡常見的幾種壓縮格式壓縮
離線處理流程 為什麼使用壓縮 當使用mapreduce經過etl後落到hdfs上時，若使用普通文字格式txt 那一般副本數為三，若乙個副本為500t，500 3 1500？顯然是不現實的。壓縮的第乙個好處，就是節省我們的磁碟空間，提公升磁碟利用率，第二個就是加速我們網路的傳輸。缺點 需要占用cpu資...
大資料 常用壓縮方式總結
名gzip bzip2 lzohadoopcodec類 gzipcodec bzip2codec lzopcodec 演算法deflate gzip2 lzo副檔名 gz.bz2 lzo hadoop內嵌是是 否否可切片否是是 否壓縮比 測試值 2 13.4 1 13.2 3 20.5 4 22.2...