Elasticsearch核心应用场景-日志优化实践

南征

作者：daniel1.背景日志领域是Elasticsearch（ES）最重要也是规模最大的应用场景之一。这得益于ES有高性能倒排索引、灵活的schema、易用的分布式架构，支持高吞吐写入、高性能查询，同时有强大的数据治理生态、端到端的完整解决方案。但原生ES在高吞吐写入、低成本存储、高性能查询等方面还有非常大的优化空间，本文重点剖析腾讯云大数据ES团队在这三个方面的内核增强优化。2.日志领域的挑战我们先来看看日志领域的挑战有哪些。首先从日志本身的数据特点来看，主要以半结构化、非结构化为主，传统的数据库方案没法很好的解决解析、存储等问题。ES支持JSON且支持动态映射，高版本还支持RuntimeFeilds，能在查询时动态提取字段，天然支持了日志场景复杂、灵活的数据结构。日志数据进入ES则面临高并发、高吞吐的写入性能挑战。内核层面我们进行了定向路由、物理复制等重磅优化，有效解决日志入口吞吐瓶颈，提升写入性能一倍+。日志数据的存储是另一大挑战，日志往往是海量的且往往价值不高，存储成本成为用户最顾虑的痛点之一。腾讯云ES一方面通过压缩编码优化来降低单位文档存储成本，另一方面我们通过基于云原生环境自研混合存储方案，实现存储与计算分离，降低存储成本50%以上。日志数据的出口，查询性能也是一大挑战，海量数据场景下，大查询对资源的开销非常高，带来的查询延时也非常明显。ES原生支持了倒排索引，点查过滤的性能非常好，但无法满足日志场景大范围查询、聚合分析等性能需求。对此，腾讯云ES进行了查询裁剪、查询并行化等一系列系统性优化，提升查询性能数十倍。下面是日志领域的挑战总结，后面将针对高吞吐写入、低成本存储、高性能查询层面的优化进行详细分析。日志领域的挑战3.高吞吐写入3.1定向路由定向路由ES的一个Bulk写入先进到协调节点（任意一个数据节点），会被拆分为若干个分片粒度的子写入请求，并分发给对应的数据节点。当集群规模较大，索引的分片数较多的场景下，分布式写入的扇出放大非常严重，很容易受到个别长尾节点的GC、慢盘、网络抖动等影响，导致写入堆积，资源利用率低，拒绝率高。腾讯云ES内核通过引入写入定向路由优化，将用户的一个Bulk请求路由到一个分片数可控的分片组，降低写入请求扇出影响，容忍慢节点，在不可靠的环境中提供可靠的服务。基于定向路由优化，某日志业务场景，写入吞吐提升一倍多，CPU资源利用率提升58%，拒绝率从3%降至0。定向路由解决了慢节点对写入的影响，接下来我们看看如何优化写入层面冗余的计算开销来提升性能。3.2物理复制物理复制ES单机引擎写入，底层数据接收到可见分为三个步骤，如上图所示。数据在内存中构建各种数据类型，包括行存、列存、各种索引。写入Translog，相当于WAL确保数据可靠性，机器挂掉数据可重放。周期性refresh将内存中的数据结构buffer构建成完整的segment并打开reader可查。ES分布式层的写入，数据先从协调节点转发至Primary，主分片写完Lucene和Translog之后并行转发给多个Replica，副本分片完成Lucene和Translog的写入。这个过程中，副本分片的Lucene写入是冗余的，因为这个写入栈在Primary上进行了一遍，在Replica上会完整的再来一遍，开销非常高。物理复制解决的就是从分片上冗余写入栈的开销。物理复制方案如上图方案所示，第一步当Primary产生新的Segment之后，会及时通过物理拷贝方式同步至Replica，使得Segment在Replica上可见，同时消除Replica上内存构建Segment过程的计算开销。当Primary上产生新的Commit文件之后，也会及时同步至Replica。同步Commit文件的目的主要是在Replica侧清理过期的Translog和被合并的Segment。例如在上面第三、四步中就描述了Primary侧Segment合并之后同步到Replica侧清理的过程。通过Segment物理复制的能力，有效裁剪了Replica写入的计算开销，在主从副本场景下提升写入性能接近一倍。4.低成本存储前面我们重点介绍了海量日志数据高吞吐写入层面的性能优化。海量的数据流入到ES之后，存储是另一大挑战，接下来我们来探讨一下海量存储场景如何进行成本优化，我们先来看看背景。低成本存储存储成本的影响面主要分为三个层面：云原生环境下分布式架构层。ES的主从副本乘以底层云盘、对象存储等三份副本（EC编码优化推出可能在1.33左右）。单机存储引擎层。由于ES是行列混存，且有丰富的索引结构，应用场景丰富的同时，也导致了单位文档存储成本放大较多。底层基础设施。为了应对高吞吐写入，往往需要引入SSD硬盘，其成本高寿命短。如果用冷热架构，温层往往会挂多块HDD盘来扩大容量，此时单盘的损坏会导致整个节点替换，存在大量的数据恢复搬迁，代价太大。另外机器运维的人力成本也不低。从上面几个维度的成本影响面来看，我们的优化重点一方面是降低单位文档的存储成本，另一方面是降低冗余副本、存储介质的成本。4.1压缩编码优化压缩编码优化压缩编码优化是在原始数据结构不变的前提下，降低单位文档存储成本非常有效的方式。上图中描述了ES底层Lucene的存储格式，以及这些格式所用到的压缩算法。其中列存压缩是由腾讯贡献给社区的。4.1.1列存压缩列存压缩Lucene列存存储分为两部分，termdictionary和termords，每个字段值的原始内容存储在termdictionary中，实际编码、计算的时候为了避免冗余而采用termords，后者会随着新数据的持续写入而动态更新。优化的主要内容是对termdictionary中的原始字段字面内容进行压缩存储。从优化后的压缩效果对比来看，写入、merge耗时基本不变的情况下，列存存储下降了40%+。4.1.2扩展基础压缩算法除了优化列存以外，我们还引入了新的通用压缩算法。扩展基础压缩算法Zstandard算法在压缩比上比LZ4更优，在性能上比Deflate更优，能兼容两者的优点。我们将该通用压缩算法引入到行存、列存、索引文件压缩中，实测业务开启Zstandard算法之后，整体存储成本下降30%+。4.2混合存储引擎前面主要介绍了通过压缩编码优化降低单位文档存储成本，而单位文档的存储优化是有极限的。另一个方向是从存储架构层面进行优化。在云原生的背景下，我们引入了自研混合存储引擎方案。混合存储引擎混合存储引擎的整体设计思路是基于典型的delta+base架构。其中delta部分我们采用SSD，主要目的为了扛高并发写入，以及小segment的存储及合并；而base部分采用对象存储，用于存储大量不可变的大segment，一方面其高可用（4个9一个5）、高可靠（12个9）、按量付费、免运维的架构降低了大量运维成本，更重要的是其提供的标准、低频、归档等灵活的低成本存储方案能大幅降低海量日志的存储成本。接下来我们结合索引数据的生命周期看看混合存储引擎的整体设计。整体设计混合存储引擎整体分为两层。上层存储介质为SSD，提供高并发的写入能力，准实时产生的segment会通过物理复制的能力从primary拷贝至replica。同时主从副本均写入translog，确保主从切换数据无缝对接及重启数据不丢失，更重要的是主从副本之间的数据、segment完全一致，这便于我们在primary上将数据下沉至底层共享存储后，replica可以无缝挂载查询。每个分片本地都会有一个RemoteDirectoryWrapper封装了对远程共享存储数据的访问，包含了数据缓存的逻辑。底层共享存储采用对象存储，数据按照索引、分片粒度分目录存储，segment数据文件一对一映射，方便存取。下面我们细分流程看看整体方案的设计细节。设计流程1如上图所示，前五个阶段，主要是我们之前描述的物理复制的流程，主要目的是为了提升写入性能，确保primary和replica数据保持完全一致，为后续的数据共享提供基础。前面已描述详细流程，这里不展开分析。设计流程2第六个阶段，本地segment通过merge产生了较大的segment，会被冻结不再参与merge，并下沉至底层共享存储。注意这个阶段是从热数据就开始的，并不是数据降温后才启动下沉，可以避免数据降温后整体下沉的排队拥塞，当然可以根据用户的需求进行灵活配置。此时，日志场景大量的查询会集中在本地，本地primary和replica也能很好的抗住读写压力。第七个阶段，数据的查询频次有所降低。一般情况，本地的primary即可满足绝大部分查询性能需求。此时replica会从本地卸载，读取会走远端共享存储，同时本地会有缓存机制保存用户常用查询数据提升性能。此时的查询会优先打到primary。通过卸载本地replica，我们可以缩减约50%的SSD容量。设计流程3第八个阶段，查询频率大幅缩减。Primary上只有部分数据或部分segment需要被查询，此时primary上的部分文件或segment会先被卸载。同时本地构建缓存体系加速查询。本阶段SSD的缩减达到70%左右，但仍然能满足业务的查询需求。第九个阶段，查询几乎没有了，数据处于归档状态。本地的primary彻底实现卸载，依靠本地的缓存加速满足极少量的查询需求。本阶段SSD的缩减到达90%左右。Segment三种形态在整个数据生命周期中，segment呈现三种形态：LocalSegment。行列存、索引文件等全部在本地，抗住热数据高并发读写请求。MixedSegment。行列存等数据文件可能卸载，只有部分索引文件在本地，满足少量的查询请求。RemoteSegment。行列存、索引文件等全部在远程，本地只有少量元数据文件，满足冷数据低成本归档需求。索引生命周期上面是完整的索引生命周期中数据的演变过程，存储重心随着数据逐渐降温过程逐步从SSD到对象存储迁移，且用户无明显感知，最终整体存储成本下降50%-80%。与现有方案的区别日志场景传统的降本方案一般采用冷热分层。混合存储引擎与冷热分层主要的区别包括：存储架构差异。1).传统冷热分层索引级别存储介质固定。2).混合存储SSD和对象存储是一个整体，数据可以双向局部流通。副本差异。1).传统冷热分层存在冗余副本。2).混合存储底层采用共享存储，上层分片最终形态为逻辑分片，消除了云原生环境下的冗余副本。数据搬迁差异。1).传统冷热分层数据降温后索引需要整体搬迁。2).混合存储支持在热数据阶段segment级别的数据下沉。配置策略差异。1).传统冷热分层依赖用户的静态配置策略，灵活性低、运维成本高。2).混合存储除了支持用户配置外，还可根据用户访问统计信息自动决策数据下沉、卸载时机，实现数据智能分层。截止目前日志场景海量数据的低成本存储优化到这里就介绍完毕了，后面继续介绍查询性能优化。5.高性能查询5.1查询性能影响面前面我们分析了日志场景的海量存储成本优化。数据存储降本之后，接下来要考虑的是数据流出，如何解决用户查询性能问题。因为混合存储底层采用对象存储，其和SSD的性能差异肯定是有一个量级的区别。我们需要系统性做一些查询优化、缓存优化来找回这种存储介质的变更带来的性能损耗。高性能查询背景我们先来看看混合存储引擎背景下，查询性能的瓶颈在哪些方面。5.1.1大量查询空转扫描ES有高效的倒排索引，点查的性能是非常强悍的。多索引或通过别名关联索引查询也是相对传统数据库的一个优势特性，而这一特性也会带来一些性能瓶颈问题。如上图所示，当我们查询的索引是一个星号，或者一个索引前缀匹配，或是一个别名的时候，底层可能关联多个物理索引，而我们的查询可能只有部分索引会有数据命中。而ES实际执行查询会将底层所有匹配的索引、包括每个索引底层的每个分片逐一遍历查询。这样会存在大量的无用索引、分片、segment的查询空转扫描。5.1.2Segment串行化执行ES底层分片之间是可以并行化的，但是单个分片内部多个segment之间是串行化的。混合存储引擎的底层是对象存储，多个segment串行化导致IO排队严重，查询效率低下，尤其是在大查询拉取数据较多的场景下。5.2索引分片级时序裁剪优化基于上面两大影响面分析，我们针对性的优化思路是查询裁剪和查询并行化，下面我们来展开分析。索引分片级时序裁剪在日志场景，索引一般是按照一定的时间周期进行滚动，腾讯自研了自治索引，帮助用户托管索引分片的管理，用户无需关心底层分片的数量、大小、分布配置。简化数据接入门槛。在此基础上，我们维护了索引级别的Min/Max，当查询请求进来的时候，可以针对用户的查询区间进行精准的物理索引过滤裁剪，大幅降低无用索引的空转扫描过程。通过索引分片维度的时序裁剪，大幅提升查询性能，内部视频日志业务实测查询性能提升8倍。5.3Segment级别查询裁剪单个分片包含多个segment，在查询过程中会依次遍历segment进行查询。但往往只有部分segment或者segment内部部分数据段存在有效数据，因此segment维度的查询裁剪也是优化的重点。Segment查询裁剪Segment级别查询裁剪分为两个维度：Segment整体裁剪。社区版本已经支持列存、数值索引等维度的裁剪，对Terms维度还缺少整体裁剪，腾讯进行了优化，并提交给了社区，点查性能提升25.7%。Segment内数据裁剪。1).流式聚合裁剪。在CompositeAggregation场景，支持聚合翻页，每次翻页会涉及大量重复数据的查询，腾讯进行了优化，基于indexsorting，每次翻页采用起始docid跳转，加上满足size条件提前结束优化，流式聚合性能提升7倍，且支持正、逆序，已反馈给社区。2).时序裁剪。社区版本，在大的时序范围查询场景，构建实践范围postinglist的时候，涉及大量的数据文件遍历，产生大量的随机IO影响查询性能。TencentESOTeam协作进行了深度优化，基于indexsorting，利用BKD做二级索引，实现端点提取裁剪遍历，逆序采用二分查找，满足了大范围的时序查询性能需求，时序搜索性能提升40倍。5.4Segment并行化Segment并行化原生ES单个分片内部多个segment查询为串行化执行。Segment并行化的思路主要是将多个segment的文档进行统筹规划，按照多线程切分，并行化查询。对于做完forcemerge的场景也能很好的提高并行度。于此同时，我们在拉取底层共享存储时，并不会整个文件拉回来，而是结合前面描述的数据裁剪能力，按照查询需要拉取局部的数据段，大幅提升拉取效率。混合存储引擎中，开启并行化查询优化相较原生版本查询性能提升5倍。6.云原生数据平台云原生数据平台下一阶段，腾讯云ES将打造云原生数据平台，闭环PB级数据检索、分析场景，全面覆盖日志场景低成本、高性能的需求。底层基于共享存储，消除冗余副本，实现存算分离架构，中间计算层会提供多种维度的集群，实现读写分离，检索、分析场景分离等。上层提供各种免运维的数据服务，实现资源灵活调度，数据跨节点、跨逻辑集群挂载等。目前腾讯云推出的ElasticsearchServerless服务已覆盖上述大部分能力，后续会持续完善，敬请关注。