导读：在做ADB PG的业务表DDL设计时，应该如何选取压缩算法和压缩级别？本文以实际场景PoC测试来为用户提供压缩算法选取相关最佳实践。

数据压缩技术在控制数据存储成本，提高数据传输效率方面具有重要技术价值，同时在数据访问性能、数据管理复杂度方面带来“负作用”；本文就ADB PG的数据压缩技术在压缩、解压缩效率方面进行实测，为使用者在大数据量存储方面选择合适的压缩算法和压缩级别提供参考，以期能够在ADB PG使用最佳实践方面抛砖引玉。

首先对业界常用数据压缩技术进行初步调研，可以看到在数据压缩算法方面较为通用的有zlib, QuickLZ, LZO, LZ4, Zstandard几种，其中 LZO 和 LZ4凭借快速压缩解压的特点在 hive, spark, lucene 等框架中被广泛采用，但压缩率逊于 zlib。值得一提的是，LZ4和Zstd都是Facebook技术大牛先后发明的高效算法，在资源占用和压缩效果方面都优于 zlib ；开源Greenplum的原生压缩技术支持zstd、zlib、rle_type、lz4几种压缩算法，其中rle_type算法仅适用于列存表模式。ADB PG 6.0的压缩算法完全继承自开源Greenplum 6.0原生压缩技术，在数据压缩和解压缩方面表现如何呢？我们站在最终使用者角度通过测试来看一下ADB PG的压缩和解压效率：

一、压缩效率评测

选择一款高效压缩算法能大大降低用户的存储成本，提升数据传输效率，因此首先就需要考察压缩算法在数据压缩能力方面的表现。

（1）测试标的选取：

站在最终用户角度在某银行客户现场选取业务表sor.cst表作为测试标的，该表包含34个字段涵盖定长字符串、date/integer/varchar/smallint/timestamp等常见字段类型，包含94,229,105条记录，裸文件大小35,150MB。同时之所以选取该业务表所谓测试标的，是考虑到大部分金融客户场景的业务数据规模普遍性。

CREATE TABLE SOR.CST  (
          CST_ID CHAR(18) NOT NULL , 
          CST_NPL_ST_DT DATE , 
          CST_LCS_TP_ID INTEGER , 
          CST_LCS_DT DATE , 
          CST_RLN_VAL_TP_ID INTEGER , 
          CST_RLN_AGE_SEG_ID INTEGER , 
          EFF_CST_DT DATE , 
          CST_RLN_AGE_SEG_DT DATE , 
          RLN_EP_ID CHAR(18) , 
          PRIM_BR_ID CHAR(18) , 
          CST_NPL_ST_ID INTEGER , 
          CST_CTY_ID CHAR(3) , 
          CST_EN_NM VARCHAR(128) , 
          CST_FUL_NM VARCHAR(128) , 
          CST_NO CHAR(23) , 
          CST_SHRT_NM CHAR(32) , 
          CST_SPCL_ST_TP_ID INTEGER , 
          INIT_CRTN_DT DATE , 
          INIT_CRTN_EP_ID CHAR(18) , 
          INIT_CRTN_OU_ID CHAR(18) , 
          LAST_UPDT_DT DATE , 
          LAST_UPDT_EP_ID CHAR(18) , 
          LAST_UPDT_OU_ID CHAR(18) , 
          PST_ADR_RANK SMALLINT , 
          TEL_ADR_RNK SMALLINT , 
          AREA_LVL1_TP_ID INTEGER NOT NULL , 
          AREA_LVL2_TP_ID INTEGER NOT NULL , 
          AREA_LVL3_TP_ID INTEGER NOT NULL , 
          ETL_FL_NM VARCHAR(128) , 
          PPN_TMSTAMP TIMESTAMP , 
          SRC_STM_ID SMALLINT , 
          JOB_SEQ_ID INTEGER , 
          LAST_ETL_ACG_DT DATE , 
          DEL_F SMALLINT )   
with (appendonly=true, orientation=?, compresstype=?, compresslevel = ?);

上述DDL中，属性orientation为row/colum，compresstype为[lz4,zlib,zstd,rle_type,none]，compresslevel为[0-9]，分别测试不同属性值情况下的压缩、解压缩性能表现。

（2）测试方法：

使用gp业界通用高效加载/卸载数据组件gpfdist将裸文件导入到ADB PG的分区表中，该分区表使用不同压缩算法及对应压缩级别实现，对比裸文件大小和入库后的表大小。

图1：通过gpfdist批量加载文件到adb pg示意

（3）测试结果：

测试结果如下，如图中N/A表示当前产品不支持对应压缩算法的压缩级别。

图2：行存表和列存表分别在不同压缩算法及压缩级别下的表现

压测结果说明：

压测结果中NONE表示为启用ADB压缩算法场景，加入测试集作为参照使用。
测试中RLE_TYPE算法只适用于列存表，而且能且只能支持4个压缩级别（compresslevel=1/2/3/4）
需注意的是压缩级别从1~9，不是从0开始，这个和计算机常用参数设置有差异

（4）测试结论：

（1）同等条件下，经过压缩后的列存表比行存表节省30%~50%的空间；不压缩约能节省15%

（2）行存表模式下，压缩效率zstd>zlib>lz4>未压缩，压缩表比未压缩表节省4~7倍的空间；列存表模式下，压缩效率zstd≈zlib>lz4>未压缩，压缩表比未压缩表节省4~5倍的空间。

（3）压缩级别越高（0->9）,对应压缩效率也更高；最高压缩级别（9）比最低压缩级别（0）效率提升10%~30%。

二、解压效率评测

数据落盘存储持久化的目的是满足日后高效访问服务的需求，因此压缩算法的选取标准不是一元化的，还需要考虑解压缩效率。

承接上文测试表sort.cst成功导入数据后，测试该表以列存的形式在不同压缩算法、压缩级别均为5下的解压缩效率，测试指标为不同并发下随机访问sort.cst表时的集群吞吐量（TPS），结果如下图所示：

图3：不同并发访问情况下、不同压缩算法在相同压缩级别（Compress Level=5）的系统吞吐量测试

从压缩级别=5的四种压缩算法加持场景不同并发数下集群吞吐量测试结果可以看出解压缩时集群吞吐量整体趋势共振，但是具体情况下还是存在相对明显的性能差距。

进一步地下钻，从四种压缩算法在表现最佳的40并发数情况观察不同压缩算法对ADB集群的性能影响。

图4：并发度为40、相同压缩级别情况下不同压缩算法的系统吞吐量测试

可以看出在相同并发数下集群吞吐性能none > zlib > lz4 > zstd

三、最佳实践建议

网络上关于大数据的压缩算法的效率问题，普遍从算法角度进行阐释说明，一致认为lz4是压缩界的速度之王，但是我们从上述规模化的测试数据看，lz4算法并不是最优选择，从综合性价比上看也应该是zlib算法；这一点也和Greenplum社区官方手册以ZLIB作为默认压缩算法不谋而合。

compresstype — Set to ZLIB (the default), ZSTD, RLE_TYPE, or QUICKLZ1 to specify the type of compression used. The value NONE disables compression. Zstd provides for both speed or a good compression ratio, tunable with the compresslevel option. QuickLZ and zlib are provided for backwards-compatibility. Zstd outperforms these compression types on usual workloads. The compresstype option is valid only if appendoptimized=TRUE.

综合考虑压缩算法的选取，在实际业务中应该对业务表特征进行合理识别有效应用ADB PG的压缩技术，以下几点建议可以作为工程实践（至少亿级数据量下情况适用）参考：

（1）维度表一般数据量较少，建议优先考虑不压缩来获取最佳访问效率；

（2）如果是访问较频繁的事实表，在压缩效率和访问效率之间进行权衡建议选用的压缩算法及压缩级别优先级为（zlib,5）、（lz4,5）和（zstd,5）