ClickHouse数据压缩

ClickHouse支持多种方式的数据压缩：LZ4和ZSTD。
关于压缩算法的测试，见这篇文章。简而言之，LZ4在速度上会更快，但是压缩率较低，ZSTD正好相反。尽管ZSTD比LZ4慢，但是相比传统的压缩方式Zlib，无论是在压缩效率还是速度上，都可以作为Zlib的替代品。
下面我们对比一下这两种压缩方式。压缩测试所用的表（lineorder）结构和数据来自这里。未压缩的数据集是680GB。
把上述数据加载到ClickHouse后，默认的LZ4压缩算法下，数据容量是184G（压缩到27%），而ZSTD达到了135GB（压缩到20%）。
如果想要使用ZSTD压缩方式，修改为如下配置即可：

    
        zstd  
    

压缩比率对比

Compression	Ratio
LZ4	3.7
ZSTD	5.0

压缩后的查询性能如何，我们来跑如下查询看看：

SELECT toYear(LO_ORDERDATE) AS yod, sum(LO_REVENUE) FROM lineorder GROUP BY yod;

为了保持客观，查询测试会跑两次，第一次是冷数据请求，这次的数据没有被操作系统缓存，第二次是热数据情求，这次的数据已经被操作系统的内存缓存了。
LZ4的性能如下：

# Cold run:
7 rows in set. Elapsed: 19.131 sec. Processed 6.00 billion rows, 
36.00 GB (313.63 million rows/s., 1.88 GB/s.)
# Hot run:
7 rows in set. Elapsed: 4.531 sec. Processed 6.00 billion rows, 
36.00 GB (1.32 billion rows/s., 7.95 GB/s.)

ZSTD性能如下：

# Cold run:
7 rows in set. Elapsed: 20.990 sec. Processed 6.00 billion rows, 
36.00 GB (285.85 million rows/s., 1.72 GB/s.)
# Hot run:
7 rows in set. Elapsed: 7.965 sec. Processed 6.00 billion rows, 
36.00 GB (753.26 million rows/s., 4.52 GB/s.)

冷数据查询情况下，两者区别不大，因为消耗在IO方面的时间，远大于消耗在数据解压缩上面的时间。
热数据请求下，LZ4会更快，此时IO代价小，数据解压缩成为性能瓶颈。
综上所述，默认的LZ4压缩方式，会给我们提供更快的执行效率，但是同时需要占用较多的磁盘容量。
ClickHouse抛开高效的SQL执行效率，数据压缩比率也是一个非常喜人的地方。使用Hadoop Node低配置服务器，再加上ClickHouse优秀的压缩性能，单机容量轻松可达几十T，推荐直接使用默认的LZ4压缩方式，用可以接受的少量空间来换查询执行效率的提升。