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開源庫的性能和壓縮率。敬請期待。