腾讯Elasticsearch海量规模背后的内核优化剖析

最新推荐文章于 2025-01-19 18:13:28 发布

原创

最新推荐文章于 2025-01-19 18:13:28 发布 · 1.4k 阅读

作者：黄华，腾讯 TEG 云架构平台部研发工程师

背景

Elasticsearch 在腾讯内部广泛应用于日志实时分析、结构化数据分析、全文检索等场景，目前单集群规模达到千级节点、万亿级吞吐，同时腾讯联合 Elastic 公司在腾讯云上提供了内核增强版 ES 云服务。海量规模、丰富的应用场景推动着腾讯对原生 ES 进行持续的高可用、高性能、低成本等全方位优化。本次分享主要剖析腾讯对 Elasticsearch 海量规模下的内核优化与实践，希望能和广大 ES 爱好者共同探讨推动 ES 技术的发展。

一、ES 在腾讯的海量规模背景

先来看看 ES 在腾讯的主要应用场景。ES 是一个实时的分布式搜索分析引擎，目前很多用户对 ES 的印象还是准实时，实际上在 6.8 版本之后官方文档已经将 near real-time 改为了 real-time："Elasticsearch provides real-time search and analytics for all types of data."ES 在写入完毕刷新之前，是可以通过 getById 的方式实时获取文档的，只是在刷新之前 FST 还没有构建，还不能提供搜索的能力。目前 ES 在腾讯主要应用在三个方面：

搜索服务： 例如像腾讯文档基于 ES 做全文检索，我们的电商客户拼多多、蘑菇街等大量的商品搜索都是基于 ES。
日志分析： 这个是 ES 应用最广泛的领域，支持全栈的日志分析，包括各种应用日志、数据库日志、用户行为日志、网络数据、安全数据等等。ES 拥有一套完整的日志解决方案，可以秒级实现从采集到展示。
时序分析： 典型的场景是监控数据分析，比如云监控，整个腾讯云的监控都是基于 ES 的。此外还包括物联网场景，也有大量的时序数据。时序数据的特点是写入吞吐量特别高，ES 支持的同时也提供了丰富的多维统计分析算子。

当然除了上面的场景之外，ES 本身在站内搜索、安全、APM 等领域也有广泛的应用。

目前 ES 在腾讯公有云、专有云以及内部云上面均有提供服务，可以广泛的满足公司内外客户的业务需求。公有云上的使用场景非常丰富，专有云主要实现标准化交付和自动化运维，腾讯内部云上的 ES 都是 PB 级的超大规模集群。

二、痛点与挑战

在这些丰富的应用场景，以及海量的规模背景下，我们也遇到了很多的痛点与挑战。主要覆盖在可用性、性能、成本以及扩展性方面。

可用性： 最常见的问题是节点因高负载 OOM，或者整个集群因高负载而雪崩。这些痛点使我们很难保障 SLA，尤其是在搜索场景，可用性要求 4 个 9 以上。
性能： 搜索场景一般要求平响延时低于 20 毫秒，查询毛刺低于 100 毫秒。在分析场景，海量数据下，虽然实时性要求没那么高，但请求响应时间决定了用户体验，资源消耗决定了性能边界。
成本： 很多用户都比较关注 ES 的存储成本，因为 ES 确实数据类型较多，压缩比比较低，存储成本比较高，但是优化的空间还是很大的。另外还包括内存成本，ES 有大量的索引数据需要加载到内存提供高性能的搜索能力。那么对于日志、监控等海量场景，成本的挑战就更大。
扩展性： 日志、时序等场景，往往索引会按周期滚动，长周期会产生大量的索引和分片，超大规模集群甚至有几十上百万的分片、千级节点的需求。而目前原生版本 ES 只能支持到万级分片、百级节点。随着大数据领域的飞速发展，ES 最终是要突破 TB 的量级，跨越到 PB 的量级，扩展性就成为了主要的瓶颈与挑战。

三、腾讯 ES 内核优化剖析

ES 使用姿势、参数调优等在社区有很多的案例和经验可以借鉴，但很多的痛点和挑战是无法通过简单的调优来解决的，这个时候就需要从内核层面做深度的优化，来不断完善这个优秀的开源产品。接下来就是本次分享的核心部分，我们来看看腾讯是如何在内核层面对 ES 做优化的。

首先介绍可用性优化部分。总体来说，原生版本在可用性层面有三个层面的问题：

系统健壮性不足： 高压力下集群雪崩，主要原因是内存资源不足。负载不均会导致部分节点压力过载，节点 OOM。我们在这个层面的方案主要是优化服务限流和节点均衡策略。
容灾方案欠缺： ES 本身提供副本机制提升数据安全性，对于多可用区容灾还是需要云平台额外实现。即使有副本机制，甚至有跨集群复制（CCR），但还是不能阻挡用户误操作导致的数据删除，所以还需要额外提供低成本的备份回挡能力。
内核 Bug： 我们修复了 Master 任务堵塞、分布式死