传闻，一卡通科技考虑今年在香港上市，融资6亿美元
06-18
1.背景 日志领域是ES最重要、最大的应用场景之一。这得益于ES的高性能倒排索引、灵活的schema以及易于使用的分布式架构，支持高吞吐量的写入和高性能的查询。
它还拥有强大的数据治理生态系统和完整的端到端解决方案。不过原生ES在高吞吐量写入、低成本存储、高性能查询等方面还有很大的优化空间。
本文重点分析腾讯云大数据ES团队在这三个方面的核心增强优化。 2. 伐木领域的挑战我们首先看一下伐木领域的挑战。
首先，从日志本身的数据特征来看，以半结构化和非结构化为主。传统的数据库解决方案无法很好地解决解析、存储等问题。
ES支持JSON和动态映射。高版本还支持Runtime Feilds，可以在查询时动态提取字段，天然支持日志场景下复杂灵活的数据结构。
当日志数据进入ES时，面临高并发、高吞吐量的写入性能挑战。在内核层面，我们进行了定向路由、物理复制等重大优化，有效解决日志项吞吐量瓶颈，写入性能提升一倍以上。
日志数据的存储是另一大挑战。日志通常很大且价值较低。
存储成本成为用户最关心的痛点之一。一方面，腾讯云ES通过压缩和编码优化，降低单位文档存储成本。
另一方面，我们通过自研的基于云原生环境的混合存储解决方案，实现存储与计算的分离，存储成本降低50%以上。导出日志数据时，查询性能也是一个很大的挑战。
在海量数据场景下，大查询的资源开销非常高，导致的查询延迟也非常明显。 ES原生支持倒排索引，点击式过滤的性能非常好，但是无法满足日志场景下的大规模查询和聚合分析的性能需求。
对此，腾讯云ES进行了查询裁剪、查询并行化等一系列系统性优化，查询性能提升数十倍。下面总结一下日志领域的挑战。
后面我们会针对高吞吐量写入、低成本存储、高性能查询层面的优化进行详细分析。日志领域的挑战 3. 高吞吐量写入 3.1 定向路由 ES的Bulk写入首先发送到协调节点（任意数据节点），然后会被分割成若干个分片粒度的子写请求，分发到对应的节点数据节点。
当集群规模较大、索引分片数量较多时，分布式写的扇出放大非常严重，容易受到个别长尾节点的GC、慢盘、网络抖动等影响，导致写累积。 ，资源利用率低，废品率高。
腾讯云ES内核引入了写导向路由优化，将用户的Bulk请求路由到分片数量可控的分片组，减少写请求的扇出影响，容忍慢节点，在不可靠的环境下提供服务。可靠的服务。
基于定向路由优化，在某日志业务场景下，写入吞吐量提升一倍以上，CPU资源利用率提升58%，拒绝率从3%下降到0。定向路由解决了慢节点对写入的影响。
接下来我们看看如何在写入层面优化冗余计算开销来提升性能。 3.2 物理副本物理副本ES单机引擎写入，底层数据接收分三步，如上图所示。
数据在内存中以各种数据类型构建，包括行存储、列存储和各种索引。写入Translog相当于WAL，保证数据可靠性，机器故障时可以重放数据。
周期性的刷新将内存中的数据结构缓冲区构建成一个完整的段，并开放给读者查询。当写入ES分布式层时，数据首先从协调节点转发到Primary。
Primary shard写入Lucene和Translog后，并行转发到多个Replica。副本分片完成Lucene和Translog的写入。
在这个过程中，Lucene对副本分片的写入是多余的，因为写入堆栈在Primary上完成一次，然后在Replica上再次完整完成，这是非常昂贵的。物理复制解决了从分片冗余写入堆栈的开销。
物理复制方案如上图所示。第一步，Primary生成新的Segment后，会及时通过物理副本同步到Replica，使得该Segment在Replica上可见，同时消除Segment在Replica上的内存构建过程的计算开销。
当Primary上产生新的Commit文件时，会及时同步到Replica。同步Commit文件的目的主要是清理Replica端过期的Translog和合并的Segments。
例如，上面的第三步和第四步中，描述了合并后将Primary侧Segment同步到Replica侧清理的过程。通过Segment物理复制的能力，有效削减Replica写入的计算开销，主从副本场景下写入性能提升近一倍。
4.低成本存储前面我们关注的是海量日志数据高吞吐量写入级别的性能优化。海量数据流入ES之后，存储是另一大挑战。
接下来我们讨论一下海量存储场景下如何优化成本。我们先来看看背景。
低成本存储 存储成本的影响主要分为三个层面：云原生环境下的分布式架构层。 ES的主从副本乘以底层云盘和对象存储的三份副本（1.33左右可能会推出EC编码优化）。
独立存储引擎层。由于ES是行列混合存储且拥有丰富的索引结构，不仅应用场景丰富，同时也导致单位文档存储成本大幅增加。
底层基础设施。为了应对高吞吐量写入，往往需要引入SSD硬盘，但价格昂贵且寿命短。
如果采用冷热架构，通常会在暖层挂载多个HDD磁盘来扩展容量。这种情况下，单个磁盘损坏就会导致整个节点更换，需要大量的数据恢复和搬迁，成本太高。
此外，机器操作和维护的人工成本也不低。从以上维度的成本影响来看，我们的优化重点一方面是降低单位文档的存储成本，另一方面是降低冗余副本和存储介质的成本。
4.1 压缩编码优化 压缩编码优化 压缩编码优化是在保持原始数据结构不变的情况下降低单位文档存储成本的非常有效的方法。上图描述了ES底层Lucene的存储格式以及这些格式所使用的压缩算法。
其中列存储压缩是腾讯贡献给社区的。 4.1.1 列式存储压缩 列式存储压缩 Lucene列式存储的存储分为两部分，术语字典和术语排序。
每个字段值的原始内容存储在术语词典中。为了避免实际编码和计算过程中出现冗余，术语使用了ords，它随着新数据的不断写入而动态更新。
优化的主要内容是对术语词典中的原始字段文字内容进行压缩存储。从优化后的压缩效果对比来看，在写入和合并时间基本不变的情况下，列存存储下降了40%+。
4.1.2 扩展基本压缩算法 除了优化列存储之外，我们还引入了新的通用压缩算法。扩展的基本压缩算法Zstandard算法在压缩比上优于LZ4，在性能上优于Deflate，并且可以兼容两者的优点。
我们将这种通用的压缩算法引入到行存储、列存储和索引文件压缩中。实际业务开启Zstandard算法后，整体存储成本下降30%+。
4.2 混合存储引擎上一篇文章主要介绍了如何通过压缩和编码优化来降低单元文档的存储成本，但是单元文档的存储优化是有限制的。另一个方向是从存储架构层面进行优化。
在云原生的背景下，我们推出了自研的混合存储引擎解决方案。混合存储引擎混合存储引擎的整体设计思想是基于典型的Delta + Base架构。
其中，delta部分我们使用SSD，主要目的是支持高并发写入，以及小段的存储和合并；而基础部分则使用对象存储来存储大量不可变的大段。一方面，高可用（4 9 A 5）、高可靠（12个9）、按需付费、免运维架构，降低了大量运维成本。
更重要的是，它提供了标准、低频、归档等灵活的低成本存储方案，可以大幅降低海量日志的存储成本。接下来我们看一下基于索引数据生命周期的混合存储引擎的整体设计。
总体设计混合存储引擎分为两层。上层存储介质为SSD，提供高并发写入能力。
准实时生成的段通过物理复制功能从主库复制到副本。同时主从副本均写入translog，保证主从切换数据无缝衔接，重启数据不丢失。
更重要的是，主从副本之间的数据和段完全一致，这方便我们将Primary上的数据下沉到底层共享存储后，Replica可以无缝挂载查询。每个分片都会有一个本地RemoteDirectoryWrapper，它封装对远程共享存储数据的访问并包含数据缓存逻辑。
底层共享存储使用对象存储。数据根据索引和分片粒度存储在目录中。
段数据文件一对一映射，以便于访问。我们来分解一下流程，看看整体方案的设计细节。
设计流程1如上图所示。前五个阶段主要是我们之前描述的物理复制过程。
主要目的是提高写入性能，保证主副本数据保持完全一致，为后续数据共享提供基础。详细过程前面已经介绍过，这里不再分析。
在设计过程2的第六阶段，本地Segment通过合并生成更大的Segment，该Segment将被冻结，不再参与合并，并下沉至底层共享存储。请注意，此阶段从热数据开始，在数据冷却后不会开始下沉。
这样可以避免数据冷却后整体下沉造成的排队拥塞。当然，也可以根据用户需求灵活配置。
这时日志场景中的大量查询会集中在本地，本地的主副本也能很好的承受读写压力。第七阶段，降低数据查询频率。
一般来说，本地主可以满足大多数查询性能要求。此时副本会从本地卸载，读取会到远程共享存储。
同时，会有本地缓存??机制来保存用户常用的查询数据，以提高性能。此时，查询将首先发送到主数据库。
通过卸载本地副本，我们可以减少大约 50% 的 SSD 容量。在设计过程3的第八阶段中，查询频率显着降低。
只需要查询主节点上的部分数据或段。此时，主服务器上的一些文件或段将首先被卸载。
同时构建了本地缓存系统来加速查询。现阶段SSD的减少量已经达到70%左右，但仍然可以满足业务的查询需求。
第九阶段，几乎没有查询，数据处于归档状态。本地主完全卸载，依靠本地缓存加速来满足极少量的查询需求。
现阶段SSD的缩减量达到90%左右。分段的三种形式 在整个数据生命周期中，分段呈现三种形式： 本地分段。
行列、索引文件等均存储在本地，以承受热数据的高并发读写请求。混合段。
行、列存储等数据文件可能会被卸载，只有部分索引文件是本地的，以满足少量的查询请求。远程段。
行列存储、索引文件等都是远程的，本地元数据文件很少，可以满足冷数据低成本归档的需求。上述索引生命周期就是完整索引生命周期中数据的演化过程。
随着数据逐渐降温，存储重心逐渐从SSD迁移到对象存储，用户并无明显感知。最终，整体存储成本降低50%~80%。
与现有方案的区别传统的日志场景降本方案一般采用冷热分层。混合存储引擎和冷热分层之间的主要区别包括： 存储架构差异。
1）。传统的冷热分层索引级别存储介质是固定的。
2）。混合存储SSD和对象存储是一个整体，数据可以部分双向流通。
复制差异。 1）。
传统的热分层和冷分层存在冗余副本。 2）。
混合存储底层采用共享存储，上层分片的最终形式是逻辑分片，消除了云原生环境中的冗余副本。数据迁移差异。
1）。传统的冷热分层数据冷却后，索引需要整体搬迁。
2）。混合存储支持热数据阶段的段级数据下沉。
配置策略差异。 1）。
传统的冷热分层依赖于用户的静态配置策略，灵活性低，运维成本高。2）。
混合存储除了支持用户配置外，还可以根据用户访问统计自动确定数据下沉和卸载的时机，实现数据智能分层。至此，日志场景下海量数据的低成本存储优化就介绍完了。
查询性能优化稍后会介绍。 5. 高性能查询 5.1 对查询性能的影响 前面我们分析了日志场景下海量存储成本的优化。
降低数据存储成本后，接下来要考虑的是数据流出以及如何解决用户查询性能问题。因为混合存储底层采用的是对象存储，所以它和SSD的性能差异肯定是一个数量级的不同。
我们需要系统性地做一些查询优化和缓存优化，以弥补这种存储介质变化带来的性能损失。高性能查询背景我们首先看一下混合存储引擎背景下查询性能的瓶颈。
5.1.1 大量查询空闲扫描 ES拥有高效的倒排索引，点查询性能非常强大。通过别名进行多索引或者关联索引查询也是相对于传统数据库的一个优势特性，但是这个特性也会带来一些性能瓶颈。
如上图所示，当我们查询的索引是星号，或者是索引前缀匹配，或者是别名时，底层可能会关联多个物理索引，而我们的查询可能只有部分索引有数据命中。 ES实际执行查询时，会一一遍历查询底部所有匹配的索引，包括每个索引底部的各个分片。
这样就会出现大量无用的索引、分片、段查询空闲扫描。 5.1.2 Segment串行执行 ES底层分片可以并行化，但是单个分片内的多个Segment是串行化的。
混合存储引擎的底层是对象存储。多个Segment的序列化导致IO排队严重，查询效率低下，尤其是在大查询拉取大量数据的场景下。
5.2 索引分片级时序剪枝优化 基于以上两大影响分析，我们针对性的优化思路是查询剪枝和查询并行化。下面我们开始分析。
索引分片级时序微调 在日志场景中，索引一般会按照一定的时间段进行滚动。腾讯开发了自己的自治索引来帮助用户管理托管的索引分片。
用户无需关心底层分片的数量、大小、分布配置。 。
简化数据访问阈值。在此基础上，我们维护指数级别的Min/Max。
当查询请求进来时，可以根据用户的查询范围进行精确的物理索引过滤和修剪，大大减少无用索引的空闲扫描过程。通过索引分片维度的定时微调，查询性能大幅提升，内部视频日志业务实测查询性能提升8倍。
5.3 段级查询剪枝 单个分片包含多个段。在查询过程中，会依次遍历各个段进行查询。
但往往只有部分Segment或Segment内的部分数据段有有效数据，因此Segment维度的查询剪裁也是优化的重点。段查询裁剪 段级查询裁剪分为两个维度： 段整体裁剪。
社区版本已经支持列存储、数值索引等维度进行裁剪。然而，Terms 维度仍然缺乏整体裁剪。
腾讯已经优化并提交给社区。枚举性能提升了25.7%。
段内的数据剪辑。 1）。
流媒体聚合和定制。复合聚合场景下，支持聚合翻页。
每次翻页都会涉及大量重复的数据查询。腾讯已经优化了。
基于索引排序，每次翻页均以起始doc id进行跳转，满足大小条件则提前结束。优化，流媒体聚合性能提升7倍，支持正序和倒序。
已向社区反馈。 2）。
时间剪裁。在社区版本中，在大时间序列范围查询场景下，在构建实用范围倒排列表时，会遍历大量的数据文件，导致大量的随机IO，影响查询性能。
与TencentES OTeam合作进行深度优化。在索引排序的基础上，采用BKD作为二级索引，实现端点提取和裁剪遍历，并采用倒序二分查找，满足大范围的时序查询性能需求，时序搜索性能提升40倍次。
5.4 段并行化 原生ES的段并行化。单个分片内的多个段查询是串行执行的。
Segment并行化的思想主要是规划多个Segment的文档，按照多线程进行切分，并行化查询。在forcemerge完成的场景下还可以提高并行度。
同时，当我们拉取底层共享存储时，我们并不会拉取整个文件。相反，我们结合上面描述的数据裁剪能力，根据查询需求拉取本地数据段，这大大提高了拉取效率。
在混合存储引擎中，启用并行查询优化，查询性能相比原生版本提升5倍。 6、云原生数据平台 下一阶段的云原生数据平台，腾讯云ES将打造闭环PB级数据检索和分析场景的云原生数据平台，全面覆盖低成本高性能日志场景的需求。
底层基于共享存储，消除冗余副本，实现存储计算分离架构。中间计算层将提供多维度的集群，实现读写分离、检索与分析场景分离等。
上层提供各类免运维的数据服务，实现灵活的资源调度、跨节点的数据挂载和目前腾讯云推出的Elasticsearch Serverless服务已经覆盖了上述大部分能力，未来还将持续完善，敬请期待。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-18
06-18
06-18
06-21
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用