tl;dr（太长不读）：
- zstd是Facebook在2016年开源的新无损压缩算法，优点是压缩率和压缩/解压缩性能都很突出。
- 在我们测试的文本日志压缩场景中，压缩率比gzip提高一倍，压缩性能与lz4、snappy相当甚至更好，是gzip的10倍以上。
- zstd还有一个特别的功能，支持以训练方式生成字典文件，相比传统压缩方式能大大的提高小数据包的压缩率。
- 在过去的两年里，Linux内核、HTTP协议、以及一系列的大数据工具（包括Hadoop 3.0.0，HBase 2.0.0，Spark 2.3.0，Kafka 2.1.0）等都已经加入了对zstd的支持。
- 可以预见，zstd将是未来几年里会被广泛关注和应用的压缩算法。
最近了解到了zstd这种新的压缩算法。不像lz4，lzo，snappy等近几年流行的压缩算法专注于压缩和解压缩性能，zstd在性能不错的同时号称压缩率跟Deflate（zip/gzip的算法）相当。下面是官网列出的数据：
我们知道，压缩算法的效果和性能跟被压缩的数据类型和模式有很大的关系，光看别人的测试数据、benchmark是不够的。正好有功能开发需要，于是结合我们的使用场景真实测试的一下。
惊喜的是，实测的结果比官方提供的还好，终于找到了我们的cup of tea。
测试环境
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 8G内存
CentOS 7.0
测试对象
对几种支持流式写入的压缩算法，使用对应的命令行工具进行压缩测试。
| 压缩算法 | 工具名称 | 默认压缩级别 | 版本 | 安装方法 |
|---|---|---|---|---|
| deflate | gzip | 5 | 1.5 | centos自带 |
| snappy | snzip | n/a | 1.0.4 | https://github.com/kubo/snzip 编译安装 |
| lz4 | lz4 | 0 | 1.7.3 | yum install lz4 |
| lzo | lzop | 0 | 2.06 | yum install lzop |
| zstd | zstd | 3 | 1.3.8 | yum install zstd |
除了snappy，各种压缩算法/工具都支持设置压缩级别，高级别意味着以更长的压缩时间换取更高的压缩率。
测试输入
100万行不重复的某个应用的日志文件，大小为977MB。
测试结果
大文件压缩
从上面可以看出：
- 解压时间各种算法差别不大
- 压缩时间（越小越好）：
lz4, zstd < lzo < snappy << gzip-1 < lz4-9 < gzip < gzip-9 < lzo-9 - 压缩率（越大越好）：
zstd-10 > zstd >> lz4-9 > gzip-9 > gzip, lzo-9 >> lz4, gzip-1 > snappy, lzo
zstd无论从处理时间还是压缩率来看都占优。snappy, lz4, lzo的压缩率较低，但压缩速度都很快，而zstd甚至比这些算法更快。Gzip的压缩率比lz4等高不少，而zstd的压缩率比gzip还提升一倍。
如果从上面的比较还不是特别直观的话，我们再引入一个创造性的指标（从网上其他压缩算法对比没有见过使用这项指标）：
压缩效率 = 权重系数 * 压缩去掉的冗余数据大小 / 压缩时间
代表单位处理时间可以压缩去掉多少冗余数据。其中权重系数用来指定压缩率和压缩速度哪个更重要，这里我们认为在我们的使用场景里两者同样重要，取系数为1。
从这里我们可以明显看出，zstd > lz4 > lzo > snappy >> 其他。
小数据量压缩
对1000行、大小约为1MB的文件进行压缩测试，各种算法的压缩率跟1GB大文件的压缩率几乎一样。
下面再对更小的数据量——10行日志数据的压缩率进行对比。虽然我们的使用场景里没有对小数据量的压缩处理，但还是比较好奇zstd字典模式的效果。
其中最后一组数据为zstd使用10000行日志进行训练生成字典文件，并利用字典文件辅助压缩测试数据。
可以看出来，除了zstd字典模式外，各种压缩算法在处理更小的数据量时压缩率都下降很多。而zstd字典模式对压缩率带来帮助非常明显，与gzip对比，压缩率从1000行时相差1倍，到10行时变为了相差接近3倍。
结论
- 对大数据量的文本压缩场景，zstd是综合考虑压缩率和压缩性能最优的选择，其次是lz4。
- 对小数据量的压缩场景，如果能使用zstd的字典方式，压缩效果更为突出。
- 综上所述，zstd凭着优异的特性，今后应用将会越来越广，值得及早了解和尝试。
下一篇文章将给大家对比这几种算法的golang开源库的性能和压缩率。敬请期待。
