为 Greenplum 增加 Zstandard 压缩功能
为 Greenplum 增加 Zstandard 压缩功能
作者：Arthur_Qin 禾众
目前在做的基于 Greenplum 的修改将造成额外的数据读写，这就加剧了磁盘 I/O 的代价。我们采取对数据进行有效压缩的方法来抵消这部分代价。
压缩算法比较
压缩算法有很多，较为通用的有 zlib, QuickLZ, LZO, LZ4, Zstandard 。前两者已经原生内嵌在 GPDB 系统中（因版权问题，QuickLZ 在最新的开源版本中已被移除），可直接调用接口使用，但 zlib 的实际使用效果并不理想。而 LZO 和 LZ4，凭借快速压缩解压的特点，在 hive, spark, lucene 等框架中被广泛采用，但压缩率逊与 zlib 。近年，Facebook 在 LZ4 作者 Collet 之前所做的工作基础上发布并开源了 Zstandard（简称 Zstd ），在资源占用和压缩效果方面都优于 zlib 。
下面给出两组分别来自于 Zstd 和 LZ4 的 Benchmarks 比较：
Benchmarks A: Linux Mint Debian edition server (Linux version 4.8.0-1-amd64), with a Core i7-6700K CPU @ 4.0GHz, using lzbench.
| Compressor | Ratio | Compression | Decompression |
|---|---|---|---|
| zstd 1.1.3 -1 | 2.877 | 430 MB/s | 1110 MB/s |
| zlib 1.2.8 -1 | 2.743 | 110 MB/s | 400 MB/s |
| quicklz 1.5.0 -1 | 2.238 | 550 MB/s | 710 MB/s |
| lzo1x 2.09 -1 | 2.108 | 650 MB/s | 830 MB/s |
| lz4 1.7.5 | 2.101 | 720 MB/s | 3600 MB/s |
| snappy 1.1.3 | 2.091 | 500 MB/s | 1650 MB/s |
Benchmarks B: Compiled with GCC v6.2.0 on Linux 64-bits, with s a Core i7-3930K CPU @ 4.5GHz. sing lzbench, in single-thread mode.
| Compressor | Ratio | Compression | Decompression |
|---|---|---|---|
| memcpy | 1.000 | 7300 MB/s | 7300 MB/s |
| LZ4 fast 8 (v1.7.3) | 1.799 | 911 MB/s | 3360 MB/s |
| LZ4 default (v1.7.3) | 2.101 | 625 MB/s | 3220 MB/s |
| LZO 2.09 | 2.108 | 620 MB/s | 845 MB/s |
| QuickLZ 1.5.0 | 2.238 | 510 MB/s | 600 MB/s |
| Snappy 1.1.3 | 2.091 | 450 MB/s | 1550 MB/s |
| Zstandard 1.1.1 -1 | 2.876 | 330 MB/s | 930 MB/s |
| Zstandard 1.1.1 -3 | 3.164 | 200 MB/s | 810 MB/s |
| zlib deflate 1.2.8 -1 | 2.730 | 100 MB/s | 370 MB/s |
| LZ4 HC -9 (v1.7.3) | 2.720 | 34 MB/s | 3240 MB/s |
| zlib deflate 1.2.8 -6 | 3.099 | 33 MB/s | 390 MB/s |
通过比较，我们不难发现。在所有常见压缩算法中，Zstd 拥有最好的压缩率，LZ4 拥有最好的压缩和解压缩时间。使用以上算法测试数据压缩，结论依旧有效。由于在之前的性能分析中已基本确认在我们的系统里数据落盘是性能的较大影响因子，因此我们优先选用 Zstd 算法。
调用 Zdtd 接口实现数据压缩
我们依照 GPDB 自带的 zlib 接口实现 Zstd 压缩。当数据生成后将落盘时，将会调用压缩函数指针，最终写入的是压缩后的数据。同理，当我们需要读出数据时，读操作同样会调用解压缩接口，获取完整可读的数据。因为我们用 Zstd 替代了 zlib ，压缩解压的时间大大减少，压缩率也更加优异，整体有较大收益。
性能分析
为了明确采用压缩方案后各环节的收益和代价，我们设计了若干简单查询，测试在原 TPC-H 500 G 测试数据下的系统性能。
具体内容略。在实验中，Zstd 的实际压缩率为 2.8 - 3.3，I/O 代价降至原来的 1/3 左右。
实验数据显示，在我们的系统中，将内存中的数据写回硬盘是最耗时的操作（左图中绿色柱型图，在不压缩的情况下长度为现在的三倍左右），采用 Zstd 压缩的办法，虽然花费了少量时间用于压缩（深蓝色）和解压缩（红），但整体来看是划算的。我们再对比不压缩的代码版本，我们可以看出，压缩的版本（蓝）在性能上有明显提升。因此在我们的系统中，Zstd 压缩将作为默认选项，用户在实际使用中可以根据具体的环境配置情况选择关闭。
- 注 ：图中的 S1 S2 指的是 slice1、slice2，Greenplum 根据数据交换对查询进行了分层，本查询一共三层。具体参考 Greenplum 的分布式框架结构。
- 注 ：Greenplum源码安装参考 Greenplum 源码安装教程 —— 以 CentOS 平台为例。
- 注 ：Zstd 支持文件压缩、流压缩，以及基于事先学习构造的字典压缩，提供了20多个压缩机别（级别越高，压缩率越好，压缩耗费资源越多）。在我们的系统中使用的是流压缩，压缩级别为1。
Zstd 的文档比较完善，具体请参考以下链接。
https://github.com/facebook/zstd
https://github.com/facebook/zstd/tree/dev/doc
转载请注明 作者 Arthur_Qin(禾众) 及文章地址 http://www.cnblogs.com/arthurqin/p/6594879.html
