Zstd压缩算法介绍

介绍

我们称 Zstandard 或 Zstd 是一种快速的无损压缩算法，是针对 zlib 级别的实时压缩方案，以及更好的压缩比。它由一个非常快的熵阶段，由 Huff0 和 FSE 库提供。这个项目是作为开源的 BSD 许可收费的库，以及一个生成和解码 .zst 格式。

性能测试对比

Zstd 还可以压缩速度为代价提供更强的压缩比，Speed vs Rtrade 可以通过小增量进行配置。在所有设置中，解压速度保持不变，并在所有 LZ压缩算法( 比如 zlib 或者lzma) 共享的属性中保持不变。

以前的压缩方式，都是适用于典型文件和二进制的压缩方案( MB/GB)的情况。然而，要压缩的数据量越小，压缩就越困难。这是所有压缩算法都存在的问题，原因是压缩算法从过去的数据中学习如何压缩未来的数据。但是在一个新的数据集的开始，没有“过去”可以参考。

为了解决这种情况，Zstd 提供了一种新的训练模式，可以使用这种模式对所选数据类型的算法进行调优。 训练 Zstandard 是通过提供一些样本(每个样本一个文件)来实现的，训练的结果存储在称为“字典”的文件中，该文件必须在压缩和解压缩之前加载。使用此字典，可以在小数据上实现的压缩率大大提高。

以下示例，使用由 github 公共 API 创建的 github 用户示例集。它由大约 10K 条记录组成，每条记录 1KB 左右。

小数据压缩的案例

如果在一组小的数据样本中存在某种相关性，那么训练就是有效的。一个字典的数据越具体，它的效率就越高(没有通用字典)。因此，为每种类型的数据部署一个字典将带来最大的好处。字典增益在前几个 KB 中最有效。然后，压缩算法将逐步使用先前解码的内容，以更好地压缩文件的其余部分。

字典压缩使用示例

1
2
3
4
5
6

# 训练字典
$ zstd --train FullPathToTrainingSet/* -o dictionaryName
# 用字典压缩
$ zstd -D dictionaryName FILE
# 用字典解压缩
$ zstd -D dictionaryName --decompress FILE.zst

二进制工具

主要介绍 zstd 工具的安装和全部的参数命令

安装方式

1
2
3
4
5
6
7
8
9

# Ubuntu
$ apt install zstd

# CentOS
$ yum install zstd

# 编译安装
$ git clone https://github.com/facebook/zstd.git
$ cd zstd; make; sudo make instal

参数

1

zstd --help

使用方式 :

1

zstd [args] [FILE(s)] [-o file]

参数选项 :

1
2
3
4
5
6
7
8

 -#     : 压缩级别(1-19，默认值为3)
 -d     : 解压
 -D file: 使用文件作为字典
 -o file: 结果存储在文件中
 -f     : 在没有提示的情况下覆盖输出并(解压)压缩链接
--rm    : 成功解压缩后删除源文件
 -k     : 保存源文件(默认)
 -h/-H  : 显示帮助/长帮助并退出

高级选项 :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 -V     : 显示版本号并退出
 -v     : 详细模式
 -q     : 静默输出
 -c     : 强制写入标准输出
 -l     : 输出zstd压缩包中的信息
--ultra : 启用超过19级，最多22级(需要更多内存)
 -T#    : 使用几个线程进行压缩(默认值:1个)
 -r     : 递归地操作目录
--format=gzip : 将文件压缩为.gz格式
 -M#    : 为解压设置内存使用限制

字典生成器 :

1
2
3
4
5
6

--train ## : 从一组训练文件中创建一个字典
--train-cover[=k=#,d=#,steps=#] : 使用带有可选参数的cover算法
--train-legacy[=s=#] : 有选择性地使用遗留算法(默认值:9)
 -o file : “file”是字典名(默认:字典)
--maxdict=# : 将字典限制为指定大小(默认值:112640)
--dictID=# : 强制字典ID为指定值(默认:随机)

性能测试参数 :

1
2
3
4
5

 -b#    : 基准测试文件，使用#压缩级别(默认为1)
 -e#    : 测试从-bX到#的所有压缩级别(默认值:1)
 -i#    : 最小计算时间(秒)(默认为3s)
 -B#    : 将文件切成大小为#个独立块(默认:无块)
--priority=rt : 将进程优先级设置为实时

使用技巧

主要介绍一些关于 zstd 工具的使用示例和参数解释

简单使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 将一个文件压缩成一个后缀为.zst的新文件

# 如果命令后面没有文件或文件为-的话，则读取标准输入

$ zstd file

# 在压缩操作后删除源文件

# 默认情况下，源文件在成功压缩或解压缩后不会被删除

$ zstd --rm file

# 解压zst压缩包

$ zstd -d file.zst

# 解压zst压缩包到标准输出

$ zstd -dc file.zst

# 查看zst压缩包

$ zstd -l file.zst
$ zstdcat file.zst

高级用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 输出详细信息

$ zstd -v file
$ zstd -v -d file.zst

# 压缩一个文件同时指定压缩级别(19最高，0最低，3为默认)

$ zstd -level file
$ zstd -9 file

# 使用更多的内存(压缩和解压时)以达到更高的压缩比

$ zstd --ultra -level file

# 解压缩为单进程

# 多个进程并发执行压缩过程(0表示自动使用所有CPU核心)

$ zstd -T0 file
$ zstd -T4 file
$ zstd -T4 -d file.zst

日志文件测试

大文件压缩

从上面可以看出：

• 解压时间各种算法差别不大
• 压缩时间（越小越好）：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的字典方式，压缩效果更为突出。

kafka测试

Apache Kafka 2.1.0正式支持ZStandard —— ZStandard是Facebook开源的压缩算法，旨在提供超高的压缩比(compression ratio)，具体细节参见https://facebook.github.io/zstd/。本文对Kafka支持的这几种压缩算法(GZIP、Snappy、LZ4、ZStandard)做了一下基本的性能测试，希望能够以不同维度去衡量不同压缩算法在Kafka>中的表现。

测试producer端

使用kafka-producer-perf-test.sh脚本依次为4个topic发送60,000,000条消息，每条消息1KB大小，去计算各种压缩算法的TPS以及其他指标。结果如下：

1、客户端CPU使用率统计图

结论：Snappy算法使用的CPU资源最多，其他3种压缩算法相差不多。

2、Broker服务器带宽统计

结论：Snappy算法占用的带宽最多且遥遥领先，LZ4次之，而新引入的ZStandard使用的带宽最少。一个可能的原因是ZStandard有较高的压缩比，减少了总体的网络IO传输量。

3、producer吞吐量(TPS)统计

结论：配置LZ4的producer TPS最高——LZ4算法有着最快的压缩时间（至少是top3），故整体TPS最高也不令人惊讶。Snappy次之，ZStandard位居第三位。说明ZStandard不是一个很快的压缩算法。

4、producer延时分布统计

结论：GZIP算法的延时最低，ZStandard次之。有意思的是，Snappy算法的平均值和99.9分位均值比较接近，而LZ4算法方差较大（当然也可能因为异常点导致）。总之从延时角度来看GZIP最优。

5、磁盘占用统计

结论：配置ZStandard算法producer生产的消息有着最高的压缩比，这符合ZStandard算法官方的定位：“Zstd can trade compression speed for stronger compression ratios.” —— 即该算法牺牲一部分压缩速度去换取更高的压缩比。

测试consumer端

使用kafka-consumer-perf-test.sh脚本依次消费4个topic，每个topic消费60,000,000条消息，去计算consumer端解压缩性能以及其他核心指标，结果如下：

1、客户端CPU使用率统计

结论：基本上4种压缩算法的客户端CPU使用率基本持平，ZStandard算法略高一些

2、Broker端带宽占用统计

结论：Snappy占用带宽最多，ZStandard最少——同理，这是因为ZStandard有最高的压缩比，极大地降低了网络IO传输量。

3、consumer吞吐量(TPS)统计

结论：配置LZ4算法的consumer有着最高的TPS，而ZStandard算法最低。

总结

相比于其他压缩算法，ZStandard有着最高的压缩比，相同的消息量占用最少的磁盘容量，因此带宽的占用也是比较少的，但是在TPS方面的表现并不抢眼，因此对于那些在乎磁盘和带宽资源的用户而言，配置ZStandard算法似乎是个不错的选择，但如果追求应用TPS，就目前的Kafka而言LZ4依然是最好的选择。

参考

zstd，未来可期的数据压缩算法

轻松使用zstd来解压缩

Kafka 2.1.0压缩算法性能测试