如何让ES低成本、高性能？滴滴落地ZSTD压缩算法的实践分享

前文分别介绍了滴滴自研的ES强一致性多活是如何实现的、以及如何提升ES的性能潜力。由于滴滴ES日志场景每天写入量在5PB-10PB量级，写入压力和业务成本压力大，为了提升ES的写入性能，我们让ES支持ZSTD压缩算法，本篇文章详细展开滴滴在落地ZSTD压缩算法上的思考和实践。

// 背景 //

ES通过索引（Index）对外提供数据检索能力，索引是用于组织和存储数据的逻辑单元。每个索引由若干个分片（shard）组成，每个分片就是一个Lucene索引，可以在不同的节点上进行分布式存储和并行处理，提高性能和可伸缩性。每个分片由一组段文件（segment）组成，段是分片中更小的存储和搜索单元，是一组物理文件，包含了检索需要的倒排索引（词项和文档ID的映射关系）和文档存储（字段值和其他元数据），如下图：

ES数据模型

Lucene作为ES的底层索引引擎，提供了灵活的数据检索能力，同时也导致CPU、存储占用较为严重。为实现降本增效，23年上半年，ES团队开启了Lucene压缩编码优化专项，通过改进存储层压缩算法，从而降低单位Document所占用的资源。本文概述了ES的底层索引文件，并介绍了Lucene存储压缩编码的优化。

// Lucene索引文件介绍 //

ES的压缩编码优化专项涉及到Lucene底层的文件存储，Lucene索引由一组Segment构成，每个Segment包含了一系列文件，重点文件类型如下图：

行存文件：包括原文存储文件和原文索引文件。原文存储文件，即.fdt文件。用户写入的原始数据都被存储于该文件中，因其占比大，为节约存储，Lucene在原文存储上支持LZ4压缩和ZIP压缩；原文索引文件，即.fdx文件，它存储了原文数据在原文存储文件中的位置信息，建立起了doc id和原文之间的联系，以支持快速访问和定位。

列存文件：即.dvd文件，常被应用于一些OLAP分析引擎中。列存文件按列组织数据，不同Document中的同一列数据（Field），相邻存放在一起，这样可以加速该列聚合分析性查询。同时，相邻每列类型相同，在存储的时候可以进行统一性的编码优化，提高压缩率，减少存储磁盘空间的占用。

索引相关文件：ES依靠分词产生倒排索引，使其具备强大的全文检索能力。索引相关文件中，重点文件包含：字典数据文件&倒排索引文件。字典数据文件，即.tim文件，通过用户配置的索引分词器，能够从用户数据中提取分词信息并存储在.tim文件中。同一列的分词信息，相邻存放，按块组织；倒排索引文件，即.doc文件，也被称为"倒排拉链表"，它记录了每一个分词所关联的文档列表，能够实现快速的单词到文档的倒排查找。

// ZSTD压缩算法调研与分析 //

ES线上集群中资源比较紧张的主要是日志集群，集群写多读少，高峰期CPU使用率在85%左右，写入性能是它的主要瓶颈。通过调研可以发现原文存储文件的占比最大，基本都超过了30%，有些索引甚至超过了70%。由此，我们明确了索引文件压缩编码优化的重心。

目前滴滴ES线上采用的是7.6.0版本，对应的Lucene版本是8.4.0，该版本支持两种压缩策略：

BEST_SPEED，是ES索引默认的压缩算法，使用了LZ4压缩。压缩与解压速度快，CPU占用低，但压缩效果弱。
BEST_COMPRESSION，使用了ZIP压缩。压缩与解压速度慢，CPU占用高，但压缩效果好。

Lucene的压缩算法仅针对占比最大的行存文件生效，其他文件通过自定义编码优化来降低存储。目前滴滴ES日志集群采用BEST_COMPRESSION压缩算法，通过ES压缩比测试发现，日志场景下，同一个索引采用ZIP比LZ4低20% ~ 40%的磁盘存储占用空间。但通过分析日志集群的CPU使用情况可以发现，ES压缩模块的CPU占比较高，一些日志集群甚至超过30%，如下图：

CPU损耗占比

在上述背景下，我们调研了ZSTD压缩算法，ZSTD（Zstandard）底层基于FSE编码实现，具有出色的压缩和解压速度。ZSTD算法的实现经过了高度优化，通过SIMD等指令集能够充分利用硬件并行性，同时编码过程大量依赖位移运算来完成状态的切换，以此提高处理速度。ZSTD采用字典压缩算法，通过引用字典中的匹配项，能够大大减少重复数据的存储空间，提高压缩比。与此同时，ZSTD采用多级压缩策略，在不同的压缩级别中应用不同的压缩算法，能够在不同的应用场景中灵活地平衡速度和压缩比。

为了验证它的性能，采用bamai线上1GB的日志文件做压缩性能测试，测试发现，ZSTD的压缩速度是ZIP的4.5倍，解压缩速度是ZIP的1.5倍，压缩比几乎持平，如下图所示，ZSTD压缩算法兼顾了LZ4压缩的"快"及ZIP压缩的"效果好"。

压缩算法对比

// ZSTD压缩算法落地 //

为了实现ZSTD在滴滴ES的落地，我们从以下方面着手：

源码开发

1、ES setting和engine扩展

ES通过setting给每个索引配置压缩格式，需要在ES setting中支持ZSTD压缩格式。ES会为每个shard初始化一个engine，不同的分片类型或状态对应不同的engine，例如索引close对应的是noop engine，DCDR从索引对应的following engine，需要在不同类型的engine上抽象并扩展它的ZSTD压缩能力。

2、Lucene CompressionMode 扩展

Lucene是一个由Java编写的全文搜索引擎库，而ZSTD算法是基于C++实现的，因此在Lucene端引入了zstd-jni来扩展ZSTD压缩能力。通过扩展CompressionMode，自定义ZStandardDecompressor和ZStandardCompressor来实现数据的按块压缩、解压缩。

参数调优

1、Chunk Size调优

行存文件内部是以Chunk形式组织的，Chunk Size通常为数十KB级别。滴滴ES7.6.0版本采用的是Lucene 8.4版本， LZ4压缩算法设置的Chunk Size为16kb，而ZIP压缩算法设置的是60kb。将索引设置为ZSTD压缩格式并导入一批线上数据后，压缩结果如表所示。