Data Compression

看一個壓縮算法的優劣，有兩個重要的指標：一個指標是壓縮比，原先佔 100 份空間的東西經壓縮之後變成了佔 20 份空間，那麼壓縮比就是 5，顯然壓縮比越高越好；另一個指標就是壓縮 / 解壓縮吞吐量，比如每秒能壓縮或解壓縮多少 MB 的數據。同樣地，吞吐量也是越高越好。

從表中我們可以發現 zstd 算法有著最高的壓縮比，而在吞吐量上的表現只能說中規中矩。 反觀 LZ4 算法，它在吞吐量方面則是毫無疑問的執牛耳者。 GZIP、Snappy、LZ4 甚至是 zstd 的表現各有千秋。 但對於 Kafka 而言，它們的性能測試結果卻出奇得一致，即在吞吐量方面：LZ4 > Snappy > zstd 和 GZIP； 而在壓縮比方面，zstd > LZ4 > GZIP > Snappy。如果網絡不好且 CPU 資源夠的話,建議使用 zstd 壓縮

具體到物理資源，使用 Snappy 算法佔用的網絡帶寬最多，zstd 最少，這是合理的，畢竟 zstd 就是要提供超高的壓縮比； 在 CPU 使用率方面，各個算法表現得差不多，只是在壓縮時 Snappy 算法使用的 CPU 較多一些，而在解壓縮時 GZIP 算法則可能使用更多的 CPU。

• 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

測試對象

對幾種支持流式寫入的壓縮算法，使用對應的命令行工具進行壓縮測試。

除了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憑著優異的特性，今後應用將會越來越廣，值得及早了解和嘗試。

作者：petergz 鏈接：https://www.jianshu.com/p/71eb3071d3e0 來源：簡書 著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

壓縮比：壓縮率越高，壓縮後的檔案大小越小，但壓縮和解壓速度可能會較慢。 壓縮速度：壓縮速度越快，可以更快地完成壓縮操作，但壓縮比可能會較低。 解壓速度：解壓速度越快，可以更快地解壓檔案，但壓縮比和壓縮速度可能會受到影響。 記憶體使用：記憶體使用量越低，可以更好地適應內存受限的應用場景，但可能會對壓縮比和壓縮速度產生影響。

• Zstd vs LZ4 vs LZO vs Snappy: Compression algorithm comparison
• LZ4 vs LZO vs ZSTD Benchmarks – Which is faster?

Evaluating Database Compression Methods: Update

The compression speed was not significantly affected by the LZ4 block size, which makes it great for compressing both large and small objects

We saw some positive impact on the compression ratio by increasing the block size, However, increasing the block size over 64K did not substantially improve the compression ratio, making 64K an excellent block for LZ4, where it had the best compression speed and about as-good-as-it-gets compression.

Reference

• LZ4：https://lz4.github.io/lz4/
• Zstd：https://facebook.github.io/zstd/
• Gzip：https://www.gzip.org/
• 压缩算法性能对比
• zstd，未来可期的数据压缩算法
• Evaluating Database Compression Methods: Update