大家都知道，在音频压缩领域，有两种压缩方式，分别是有损压缩和无损压缩。
 
我们常见到的MP3、WMA、OGG被称为有损压缩，有损压缩顾名思义就是降低音频采样频率与比特率，输出的音频文件会比原文件小。
 
另一种音频压缩被称为无损压缩，也就是我们今天所要说的主题内容。无损压缩能够在100%保存原文件的所有数据的前提下，将音频文件的体积压缩的更小，而将压缩后的音频文件还原后，能够实现与源文件相同的大小、相同的码率。
 
目前无损压缩格式有APE、FLAC、 WavPack、LPAC、WMALossless、AppleLossless、La、OptimFROG、Shorten，而常见的、主流的无损压缩 格式目前只有APE、FLAC。下面就针对这两种无损压缩格式进行一下对比！
 
APE是Monkey’s Audio，一种无损压缩格 式。这种格式的压缩比远低于其他音频格式，但能够做到真正无损，同时其开放源码的特性，也获得了不少音乐发烧友的青睐。在现有不少无损压缩方案中，APE 是一种有着突出性能的格式，令人满意的压缩比以及飞快的压缩速度，在国内应用比较广泛，成为了不少朋友私下交流发烧音乐的选择之一。
FLAC 是Free Lossless Audio Codec的简称，是一种非常成熟的无损压缩格式，名气不在APE之下！该格式的源码完全开放，而且兼容几乎 所有的操作系统平台。它的编码算法相当成熟，已经通过了严格的测试，当在编码损坏时依然能正常播放。另外，该格式是最先得到广泛硬件支持的无损格式，世界 知名数码产品如：Rio公司的硬盘随身听Karma，建伍的车载音响MusicKeg以及PhatBox公司的数码播放机都能支持FLAC格式。
 
前面已经说明，无损压缩是在保证不损失源文件所有码率的前提下，将音频文件压缩的更小，也就是说这两种音频格式都能保证源文件码率的无损。但两种压缩格式毕竟为两种压缩算法，下面列举一下两种压缩格式的异同点：
 
一、相同点
 
1、压缩比决定无损压缩文件所占存储空间
 
FLAC与AEP的压缩比基本相同，FLAC的压缩比为58.70%，而APE的压缩比则要更高一些，为55.50%，都能压缩到接近源文件一半大小。
 
2、编码速度考验用户的耐心，速度快者优
 
非常值得赞扬的是，FLAC与APE的编码速度都相差无几，这是因为两者的压缩技术是开源的，开发者可以借鉴两者在编码上的不同优势进行开发，不过目前编码速度最快的是WavPack和Shorten两种无损压缩格式，但这两种格式的非开源性限制了其普及。
 
3、平台的支持决定普及度
 
音频压缩不但需要硬件的支持，也需要的软件的支持，因此能够被更广泛的平台支持，也就意味着被更多用户使用。FLAC与APE在这方面做的都非常出色，能够 兼容所有系统平台，现在无论您是Windows用户还是众多版本的Linux用户，哪怕您是Mac OS的忠实FANS，都无需担心无法使用FLAC或 APE。
 
4、两者的开源特性，完全免费的技术
 
两者的开源特性，意味着任何组织或个人都可以免费使用这两种压缩技术，任何 组织或个人都可以修改和发布基于这两种技术的新产品，这给众多MP3厂商降低成本提供了有力保障，且消费者也能够以相对低廉的价格购买到只有世界级 MP3（例如：iPod支持ALAC）才支持的无损压缩音频、CD级的音质表现！
 
二、不同点
 
1、自我纠错能力，谁更人性化？
 
很 多消费者都经历过MP3的爆音问题，然后归咎于MP3质量有问题，其实，很大一部分爆音是因为音频压缩过程中，编码的微小损坏，造成在解码时，处理出来的 数据与音频不一致，导致爆音现象。无损格式压缩的不好也会导致编码损坏，而在处理这种问题时，FLAC的会以静音方式代替有损部分，而APE的处理则与常 见的有损压缩格式处理的方式相同，以爆音方式代替有损部分。这一点FLAC设计的更人性化！
 
2、优化的编码结构，决定了解码的速度
 
由于编码方式的不同，将影响两种无损压缩格式的解码速度，通常FLAC的解码速度比APE快30%，这是因为，FLAC只需执行整数运算，而无需执行占用系统更高频率和更大数据处理量的浮点运算。基于这一点，一般硬件均可完美实现实时解码。
 
3、方便的资源获取，意味着能够得到更广泛的应用与支持
 
无论FLAC还是APE，在资源获取上，两者都能通过网络搜索轻松获得！
 
三、总结
 
通过以上的对比，相信很多用户对FLAC和APE的认识更加深了一些，单从技术角度讲，FLAC要明显比APE优秀，原因在于，FLAC是第一个开源的且被世界公认的无损压缩格式，有来自世界各地的顶尖级开发高手对FLAC进行免费的开发与技术完善，同时，FLAC有广泛的硬件平台的支持，几乎所有采用便携式设计的高端解码芯片都能够支持FLAC格式的音乐，FLAC第三个优势在于：优秀的编码使得硬件在解码时只需采用简单的整数运算即可，这将大大降低所占用的硬件资源！不过两种公开的技术具有极强的互补性，任何一方都不可能全面超越另一方！

 
文章目录
 
原理记录
测试过程
结论
   
  
 

 
原理记录
 
 
划重点： 压缩率取决于文件的信息熵，文件的信息熵越小，被压缩后的文件体积越小，因此文件压缩有一定的限度。
 
举个栗子（仅说明原理，不涉及实际算法）：
 
一个文件内容为：abc123qqqq6562abc123abc123abc123
 
压缩时，令1=abc123，这个对应关系即所谓的字典，则压缩后文件变为1qqqq6562111，解压即还原过程。
 
一些文本文件之所以能被压缩的很小，是由于文件内容有很多内容是重复的，可以被替代掉，这也解释了为什么很多代码的压缩包只有几十兆，而解压后却能达到几个G的大小。
 
测试过程
 
 
测试文件信息：
              包含一个mp4视频的文件夹
 
zip
 使用360ZIP，参数设置如下：
 
 
rar
 rar格式已申请专利，所以相关产品属于付费产品，使用winrar，参数设置如下：
 

 
 
7z
 使用7z-zip，参数设置如下：
 
 
结论
 
 
结果对比：
 

 使用7z-zip，压缩算法为LAMA，得到如下结果：
 
 
由对比结果可见：压缩算法的选择，对压缩率影响很大，同样的zip，使用LAMA算法也可以达到7z相同的效果！
 
 
参考文献：
 如何压缩文件到最小（压缩参数调整教程 for 7z）

xz这个压缩可能很多都很陌生，不过您可知道xz是绝大数Linux默认就带的一个压缩工具。
 
之前xz使用一直很少，所以几乎没有什么提起。
 
我是在下载phpmyadmin的时候看到这种压缩格式的，phpmyadmin压缩包xz格式的居然比7z还要小，这引起我的兴趣。
 
最新一段时间会经常听到xz被采用的声音，像是最新的archlinux某些东西就使用xz压缩。不过xz也有一个坏处就是压缩时间比较长，比7z压缩时间还长一些。不过压缩是一次性的，所以可以忽略。
 
xz压缩文件方法或命令
 
xz -z 要压缩的文件
 
如果要保留被压缩的文件加上参数 -k ，如果要设置压缩率加入参数 -0 到 -9调节压缩率。如果不设置，默认压缩等级是6.
 
xz解压文件方法或命令
 
xz -d 要解压的文件
 
同样使用 -k 参数来保留被解压缩的文件。
 
创建或解压tar.xz文件的方法
 
习惯了 tar czvf 或 tar xzvf 的人可能碰到 tar.xz也会想用单一命令搞定解压或压缩。其实不行 tar里面没有征对xz格式的参数比如 z是针对 gzip，j是针对 bzip2。
 
创建tar.xz文件：只要先 tar cvf xxx.tar xxx/ 这样创建xxx.tar文件先，然后使用 xz -z xxx.tar 来将 xxx.tar压缩成为 xxx.tar.xz
 
解压tar.xz文件：先 xz -d xxx.tar.xz 将 xxx.tar.xz解压成 xxx.tar 然后，再用 tar xvf xxx.tar来解包

 
文章目录
 
1.压缩的好处和坏处
2.压缩格式
3.压缩测试
4.优缺点
5.图解MapReduce
6.总结
7.应用场景
   
  
 


 为什么会出现需要对文件进行压缩？

 在Hadoop中，文件需要存储、传输、读取磁盘、写入磁盘等等操作，而文件的大小，直接决定了这些这些操作的速度。
 
1.压缩的好处和坏处
 
好处
 
减少存储磁盘空间
降低IO(网络的IO和磁盘的IO)
加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度
 
坏处
 
由于使用数据时，需要先将数据解压，加重CPU负荷。而且压缩的越狠，耗费的时间越多。
 
2.压缩格式
 
压缩格式
工具
算法
扩展名
是否支持分割
Hadoop编码/解码器
DEFLATE
N/A
DEFLATE
.deflate
No
org.apache.hadoop.io.compress.DefalutCodec
gzip
gzip
DEFLATE
.gz
No
org.apache.hadoop.io.compress.GzipCodec
bzip2
bzip2
bzip2
.bz2
Yes
org.apache.hadoop.io.compress.Bzip2Codec
LZO
Lzop
LZO
.lzo
Yes(if index)
com.hadoop.compression.lzo.LzoCodec
LZ4
N/A
LZ4
.lz4
No
org.apache.hadoop.io.compress.Lz4Codec
Snappy
N/A
Snappy
.snappy
No
org.apache.hadoop.io.compress.SnappyCodec

 支持native表示，hadoop自己提供了功能的实现，而不是依赖外部，如bzip2是不支持native，则表示物理机要另行安装支持bzip2压缩的软件。
 
3.压缩测试
 
一个简单的案例对于集中压缩方式之间的压缩比和压缩速度进行一个感观性的认识
 
测试环境:
8 core i7 cpu 
8GB memory
64 bit CentOS
1.4GB Wikipedia Corpus 2-gram text input
 
压缩比
 
 压缩时间/解压时间
 
 可以看出，压缩比越高，压缩时间越长，压缩比：Snappy<LZ4<LZO<GZIP<BZIP2
 
4.优缺点
 
a. gzip
 
优点：压缩比在四种压缩方式中较高；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便
缺点：不支持split
 
b. lzo
 
优点：压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；需要在linux系统下自行安装lzop命令，使用方便
缺点：压缩率比gzip要低；hadoop本身不支持，需要安装；lzo虽然支持split，但需要对lzo文件建索引，否则hadoop也是会把lzo文件看成一个普通文件（为了支持split需要建索引，需要指定inputformat为lzo格式）
 
c. snappy
 
优点：压缩速度快；支持hadoop native库
缺点：不支持split；压缩比低；hadoop本身不支持，需要安装；linux系统下没有对应的命令
 
d. bzip2
 
优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便
缺点：压缩/解压速度慢；不支持native
 
5.图解MapReduce
 
 
1.第一次传入压缩文件，应选用可以切片的压缩方式，否则整个文件将只有一个Map执行。Use Compressd Map Input:从HDFS中读取文件进行Mapreuce作业，如果数据很大，可以使用压缩并且选择支持分片的压缩方式（Bzip2,LZO），可以实现并行处理，提高效率，减少磁盘读取时间，同时选择合适的存储格式例如Sequence Files，RC,ORC等。
2.第二次压缩应选择压缩解压速度快的压缩方式，生产中，Map阶段数据落盘通常使用snappy压缩格式（快速压缩解压）。Compress Intermediate Data:Map输出作为Reducer的输入，需要经过shuffle这一过程，需要把数据读取到一个环形缓冲区，然后读取到本地磁盘，所以选择压缩可以减少了存储文件所占空间，提升了数据传输速率，建议使用压缩速度快的压缩方式，例如Snappy和LZO。
3.第三次压缩有两种场景分别是：一.当输出文件为下一个job的输入，选择可切分的压缩方式例如：BZip2。二.当输出文件直接存到HDFS，作为归档，选择压缩比高的压缩方式。reduce阶段数据落盘通常使用gzip或bzip2进行压缩（减少磁盘使用）。Compress Reducer Output:进行归档处理或者链接Mapreduce的工作（该作业的输出作为下个作业的输入），压缩可以减少了存储文件所占空间，提升了数据传输速率，如果作为归档处理，可以采用高的压缩比（Gzip,Bzip2），如果作为下个作业的输入，考虑是否要分片进行选择。
 
6.总结
 
不同的场景选择不同的压缩方式，肯定没有一个一劳永逸的方法，如果选择高压缩比，那么对于cpu的性能要求要高，同时压缩、解压时间耗费也多；选择压缩比低的，对于磁盘io、网络io的时间要多，空间占据要多；对于支持分割的，可以实现并行处理。
 ☆若该压缩格式不支持文件分割，则后续无法实现并行处理，生产优化核心是让每个文件大小略微低于块大小，如块128M文件怎样为125M。未压缩的文件是支持文件分割的
 
7.应用场景
 
一般在HDFS 、Hive、HBase中会使用；
 当然一般较多的是结合Spark 来一起使用。