爲 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 指的是 slice一、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