网页qq无法使用快捷登录,seo关键词布局技巧,深圳网站建设售后服务怎样,开一家传媒公司需要多少钱前文分别介绍了滴滴自研的ES强一致性多活是如何实现的、以及如何提升ES的性能潜力。由于滴滴ES日志场景每天写入量在5PB-10PB量级#xff0c;写入压力和业务成本压力大#xff0c;为了提升ES的写入性能#xff0c;我们让ES支持ZSTD压缩算法#xff0c;本篇文章详细展开滴滴… 前文分别介绍了滴滴自研的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压缩算法ZSTDZstandard底层基于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 engineDCDR从索引对应的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压缩格式并导入一批线上数据后压缩结果如表所示。 Chunk Size压缩比对表 增大ChunkSize可以获得一个更大的数据区间内的共享字典数据从而获得更好的压缩效果。但这也会导致随机访问时延变大、CPU消耗进一步增大。为保证后期索引压缩格式切换为ZSTD时不会出现数据膨胀问题ChunkSize采用的是60kb。 2、ZSTD压缩等级调优 ZSTD采用多级压缩策略它 提供了从 1 到 22 的压缩等级数值越大表示压缩比越高但压缩和解压缩速度越慢、CPU损耗越高。设置不同的压缩等级导入测试数据压缩结果如下表所示 压缩等级性能比对表 通过增大压缩等级能够降低存储例如将压缩等级调整为9.fdt文件能够下降10%左右的存储索引整体存储下降5%此时CPU损耗和ZIP基本持平。 ES线上日志集群写多读少采用的都是物理机SSD硬盘集群高峰期CPU使用率超过80%集群整体磁盘水位在55%左右CPU使用率是它的瓶颈。因此采用的压缩等级为3该等级在速度和压缩比之间取得了较好的平衡并且能够尽可能地降低集群CPU使用率。 其他 1、解决Lucene打包部分依赖加载失败问题比如Lucene采用ivy进行依赖管理通过引入repo解决Lucene打包过程中Maven主仓库中找不到 org.restlet.jee jar的问题如下图 ivy依赖导入图 2、通过前置初始化zstd模块解决ES运行时动态加载zstd-jni-jar失败问题。 3、通过扩展noop engine的ZSTD压缩能力解决索引close场景ZSTD类型解析失败问题。 // 上线效果 // 经过三个月的实践与优化目前已在16个集群上线了ES-ZSTD版本并将日志集群全量索引6w以及部分公共集群索引的压缩格式均切换为ZSTD上线后所有日志集群高峰期CPU使用率平均降幅达到15%使ES可以提供更高性能、更低成本的检索服务主要效果如下 更高性能 1、某日志集群A上线效果 ES某日志集群A上线ES-ZSTD版本并将全量索引切换压缩切换为ZSTD格式后集群高峰期CPU使用率下降18%写入reject同比下降50%。 集群CPU Idle图集群A DataNode写入reject图集群A 2、某超大日志索引M切换效果 ES某超大线上日志索引M压缩格式由ZIP切换为ZSTD后写入条数不变的情况下集群CPU使用率下降15%写入性能提升25%。 集群CPU Idle图集群B 索引写入总耗时索引M 更低成本 1、LZ4压缩格式索引切换为ZSTD效果 ES日志集群还残留着部分LZ4压缩的日志索引将这些日志索引切换为ZSTD压缩格式后平均索引存储下降达到30%如下图 索引存储图 2、日志集群缩容 将索引压缩格式切换为ZSTD后能够有效降低集群CPU因此可以进行集群资源调整。目前已经缩容机器超过20台仍在持续下线中。 // 总 结 // ZSTD助力ES提供更高性能、更低成本的检索服务。之后也会陆续开启读写分离、ES大版本升级等项目进一步助力业务发展。
