Elasticsearch作为首选的开源分布式搜索分析引擎，可以通过一套系统轻松满足用户实时日志分析、全文搜索、结构化数据分析等多种需求，大大降低成本大数据时代挖掘数据价值。图片来自Pexels。腾讯在公司丰富的场景中大规模使用ES。同时与Elastic合作，在腾讯云上提供内核增强的ES云服务。规模化、丰富多样的使用场景，驱动着腾讯对原生ES的持续研发。高可用、高性能、低成本的优化。今天给大家分享一下我最近在Elastic中国开发者大会上的演讲内容：腾讯的万亿级Elasticsearch技术解密。ES在腾讯的应用场景本次分享的主要内容包括：首先介绍了ES在腾讯丰富的应用场景以及各个场景的典型特征；挑战。针对这些挑战，我们聚焦腾讯在ES内核的高可用、低成本、高性能等优化实践；最后简单分享一下我们对ES开源贡献和未来规划的想法。我们先来看看ES在腾讯的应用场景。最初，我们使用ES进行实时日志分析。典型日志如下：运行日志，如慢日志、异常日志等，用于定位业务问题。业务日志，例如用户点击和访问日志，可以用来分析用户行为。审计日志，可用于安全分析。ES完美解决了实时日志分析的需求。它具有以下特点：Elastic生态系统提供完整的日志解决方案。任何开发者、运维同学都可以使用成熟的组件，通过简单的部署来构建完整的日志。实时分析服务。在Elastic生态中，日志从生成到访问一般在10s级别。与传统大数据方案几十分钟、几小时相比，时效性非常高。由于支持倒排索引、列存等数据结构，ES提供了非常灵活的搜索和分析能力。支持交互式分析，即使万亿级日志，ES搜索响应时间秒级。日志是互联网行业最基础、最广泛的数据形态。ES完美解决了实时日志分析场景，这也是近几年ES发展迅速的重要原因。第二类使用场景是搜索服务。典型场景包括：商品搜索，类似于京东、淘宝、拼多多的商品搜索。APP搜索，支持在应用商店中搜索应用。站内搜索，支持论坛、在线文档等搜索功能。我们支持海量搜索服务，主要有以下特点：高性能：单个服务最高可达10w+QPS，平音20ms~，P95延迟小于100ms。强相关性：搜索体验主要取决于搜索结果是否与用户意图高度匹配，需要通过准确率、召回率等指标进行评估。高可用：搜索场景通常需要4个9的可用性，支持单机房故障容灾。任何电商，淘宝、京东、拼多多，只要失败一个小时，就能上头条。第三类使用场景是时序数据分析。典型的时序数据包括：Metrics，即传统的服务器监控。APM，应用程序性能监控。物联网数据、智能硬件产生的传感器数据、工业物联网等。腾讯很早就开始探索此类场景，并在这方面积累了丰富的经验。此类场景具有以下特点：高并发写入：单个在线集群最大规模达到600+节点，写入吞吐量1000w/s。查询性能高：要求单条曲线或单条时间线的查询延迟在10ms~以内。多维分析：需要灵活多维的统计分析能力。比如我们在查看和监控的时候，可以灵活的按照地域和业务模块进行统计分析。遇到的挑战前面我们介绍了ES在腾讯内部的广泛应用。在如此大规模、高压、丰富的使用场景背景下，我们遇到了很多挑战。总体来说可以分为两大类：搜索类时间序列类首先我们来看一下搜索服务面临的挑战。以电商搜索、APP搜索、站内搜索为代表，该类业务非常重视可用性，服务SLA达到4个9以上，需要容忍单机故障和单机房网络故障.同时要求高性能和低毛刺，比如20w的QPS，20ms的平坦声音，100ms的P95延迟。总之，在搜索业务场景中，核心挑战在于高可用和高性能。另一类业务挑战我们称之为时间序列，包括日志、指标、APM等场景。与关注高可用和高性能的搜索服务相比，计时服务会更加关注成本和性能。比如时序场景的用户，通常需要高写入吞吐量，部分场景可以达到1000w/sWPS；在这样的写入吞吐量下，可以保留30天的数据，通常达到PB级存储。现实是日志、监控等场景的收益比较低。用户实际在线业务使用的机器很可能只有100台，而监控和日志需要50台机器。这对于大多数用户来说基本上是不能接受的。的。因此，在时序服务中，主要的挑战在于存储成本、计算成本等方面。前面我们介绍了在搜索和计时业务场景中遇到的高可用、低成本、高性能的挑战。针对这些挑战，我们将重点分享腾讯在ES内核方面的深度实践。ES优化实践首先我们来看一下高可用优化。我们将高可用性分为三个维度：系统健壮性：指的是ES内核本身的健壮性，也是分布式系统普遍面临的问题。比如集群在异常查询、压力过载情况下的容错能力；集群在高压场景下的可扩展性；集群扩容和节点异常场景下节点和多硬盘之间的数据均衡能力。容灾方案：通过管控系统建设，保证机房网络故障时服务的快速恢复，防止自然灾害下数据丢失，误操作后快速恢复等系统缺陷：这将继续任何系统开发过程中都会出现，例如master节点拥塞，分布式死锁，缓慢滚动重启等。针对以上问题，我们介绍一下我们的高可用解决方案：在系统健壮性方面，我们限制服务流量来容忍服务机器网络故障和查询异常导致的不稳定，后面会介绍。通过优化集群元数据管控逻辑，集群扩展能力提升一个数量级，支持千级节点集群和百万分片，解决集群扩展性问题；在集群平衡方面，通过优化节点和多个硬盘之间的分片平衡，保证了大集群的均压。在容灾方案方面，我们通过扩展ES的插件机制来支持备份和回滚，将ES的数据备份和回滚到廉价存储上，保证数据恢复。支持跨可用区容灾，用户可以按需部署多个可用区，容忍单个机房故障。垃圾桶机制保证集群在欠费、误操作等场景下可以快速恢复。在系统缺陷方面，我们修复了滚动重启、Master阻塞、分布式死锁等一系列bug。其中，滚动重启优化可以将节点重启速度提升5+倍。详情请参考PRES-46520；大师卡顿问题，我们在ES6.x版本和官方一起优化了。这里介绍一下服务限流部分。我们做了4个级别的限流工作：权限级别，我们支持XPack和自研权限，防止攻击和滥用。队列级别，通过优化任务执行速度、重复次数、优先级等，解决用户经常遇到的Master任务队列堆积、任务饥饿等问题。在内存层面，从ES6.x开始，我们支持HTTP入口、协调节点、数据节点等全链路内存限流，利用JVM内存、梯度统计等进行精准控制。在多租户层面，我们使用CVM/Cgroups方案来保证多租户之间的资源隔离。这里详细介绍一下聚合场景下的限流问题。用户在使用ES进行聚合分析时，经常会遇到聚合桶过多导致内存爆炸的问题。官方在ES6.8中提供了max_buckets参数来控制聚合的最大桶数，但是这种方式有很强的局限性。在某些场景下，用户可以设置20万个桶正常工作，但在其他场景下，10万个桶的内存可能会被耗尽，这主要取决于单个桶的大小，用户无法准确把握是比较合适的这个参数设置多少。在聚合分析过程中，我们使用梯度算法进行优化，每分配1000个bucket就检查JVM内存，当内存不足时及时中断请求，保证ES集群的高可用。详情请参阅PRES-46751/47806。我们目前的限流方案可以大大提高ES服务在异常查询、压力过载、单节点故障、网络分区等场景下的稳定性。但是还有少量的场景没有被完全覆盖，所以我们目前正在引入混沌测试，依靠混沌测试来覆盖更多的异常场景。前面我们介绍了高可用方案，现在介绍成本优化实践。成本挑战主要体现在以日志、监控为代表的时序场景对机器资源的消耗。我们分析典型的在线日志和时间序列服务。总体来看，硬盘、内存、计算资源的成本比接近8:4:1。硬盘和内存是主要矛盾，其次是计算成本。分析时序场景可以看出，时序数据具有明显的访问特性。一是冷热特性。时序数据访问具有多近多远的特点，最近7天的数据访问比例可达95%以上；历史数据访问较少，通常访问统计信息。基于这些瓶颈分析和数据访问特点，我们将引入成本优化方案：在硬盘成本方面，由于数据冷热特征明显，我们首先采用冷热分离架构，采用混合平衡成本和性能的存储解决方案。其次，由于历史数据通常是访问统计，用存储和性能换取预计算，后面会介绍。如果历史数据根本不用，也可以备份到更便宜的存储系统；其他优化方法包括存储修剪、生命周期管理等。在内存成本上，很多用户会发现在使用大存储模型时，只使用了20%的存储资源，内存不够用。其实根据时序数据的访问特点，我们可以使用Cache来进行优化，后面会介绍。让我们扩展并介绍Rollup部分。Rollup从ES6.x开始正式上线。事实上，腾讯在ES5.x中就已经开始了这部分实践。Rollup类似于大数据场景中的Cube和物化视图。其核心思想是通过预计算提前生成统计信息，释放原始粒度数据，从而降低存储成本，提高查询性能，通常具有数据级的收益。这是一个简单的例子。比如机器监控场景，原来监控数据的粒度是10秒，而一个月前的监控数据一般只需要按小时粒度查看即可。这是一个rollup应用场景。在大数据领域，传统的解决方案是依赖外部离线计算系统，周期性读取全量数据进行计算。这种方法具有较高的计算和维护成本。Google的广告指标系统Mesa采用了连续生成的方案。当写入数据时，系统会为每个Rollup生成一个输入数据，并对数据进行排序。底层在Compact/Merge过程中通过多路合并完成Rollup。这种方法的计算和维护成本都比较低。ES从6.x开始支持数据排序。我们使用流式查询进行多路合并生成Rollup。最终计算开销不到写入全量数据时CPU开销的10%，内存占用小于10MB。我们已经将内核优化反馈给开源社区，解决开源Rollup的计算和内存瓶颈。有关详细信息，请参阅PRES-48399。接下来，我们展开内存优化部分。前面提到，当很多用户使用大存储机型时，内存优先级成为瓶颈，硬盘无法得到充分利用。主要瓶颈是索引占用内存大。但是我们知道时序场景很少访问历史数据，有些字段在某些场景下基本不会用到，所以我们可以通过引入Cache来提高内存利用效率。在内存优化方面，业界的解决方案是什么？从7.x开始，ES社区支持索引放置在堆外，和DocValue一样按需加载。但是这种方法的缺点是索引和数据的重要性完全不同。大查询很容易导致索引被淘汰，后续查询的性能会成倍衰减。Hbase通过缓存Cache来缓存索引和数据块，提高热数据访问性能。从HBase2.0开始，着重于其OffHeap技术，着重于堆外内存的访问性能可以接近堆内。我们根据社区经验进行迭代，在ES中引入了LFUCache来提高内存利用效率，将Cache放在堆外来降低堆内存压力，通过WeakReference、减少堆内外副本等技术减少丢失。最终效果是内存利用率提升80%，大存储模型可以得到充分利用，查询性能损失不超过2%，GC开销降低30%。前面我们介绍了可用性和成本优化方案，最后我们介绍了性能优化实践。以日志、监控为代表的时序场景对写入性能要求非常高，写入并发可达1000w/s。但是，我们发现在使用主键写入时，ES性能衰减了1+倍，并且在一些压测场景下，CPU无法得到充分利用。以搜索服务为代表的场景，对查询性能的要求非常高，要求20wQPS，20ms平率，尽量避免GC和执行计划不佳导致的查询毛刺。针对以上问题，我们介绍一下腾讯的性能优化实践：写作方面，针对主键去重场景，通过使用索引来加速主键去重过程，从而加速主键去重过程，写入性能提升45%。详情请参考PRLucene-8980。针对部分压测场景下CPU不能被充分利用的问题，通过优化ES刷新Translog时的资源抢占，可以提升20%的性能。有关详细信息，请参阅PRES-45765/47790。我们正在尝试通过向量化执行来优化写入性能。通过减少分支跳转和指令未命中，可以将预期的写入性能提高一倍。在查询方面，我们优化了Merge策略来提升查询性能，后面会介绍。基于每段记录的min/max索引，进行查询剪枝，查询性能提升30%。使用CBO策略可以避免由于查询缓存操作而导致查询时间超过10倍的故障。详情请参考Lucene-9002。另外，我们也在尝试通过一些新的硬件来优化性能，比如Intel的AEP、Optane、QAT等。接下来介绍一下Merge策略优化部分。ES原生的Merge策略主要关注大小相似度和最大上限。Sizesimilarity是指在Merge的时候，尽可能选择大小相似的Segments进行Merge。最大上限是考虑尝试拼凑Segments到5GB。那么有可能某个段包含了1月1日和3月1日整月的数据，当用户查询3月1日某个时辰的数据时，必须扫描大量无用的数据，这会导致严重的性能问题损失。我们在ES中引入了时间序列Merge。在选择SegmentsforMerge时，我们应该关注时间因素，将时间相近的Segments合并在一起。当我们查询3月1日的数据时，我们只需要扫描单个较小的片段，其他片段可以快速裁剪。另外，ES官方建议搜索用户在写入完成后进行一次ForceMerge，目的是将所有Segment合并为一个，提高搜索性能。但是这样增加了用户的使用成本，而且在时序场景下不利于裁剪，需要扫描所有数据。我们在ES中引入了自动冷数据合并。对于不活跃的索引，底层段会自动合并到接近5GB，减少文件数量，方便定时场景裁剪。对于搜索场景，用户可以增加目标段的大小，以便最终将所有段合并为一个。我们对Merge策略的优化可以使搜索场景的性能翻倍。介绍完我们在ES内核的优化实践后，我们会简单分享一下我们对开源贡献和未来规划的思考。开源贡献和未来规划在过去的六个月里，我们向开源社区提交了10+个PR，涉及编写、查询、集群管理等各个模块。部分优化是和官方开发的同学一起完成的。对应的PR链接供大家参考。我们还在公司内部组建了开源协作组，共同打造Elastic生态。一般来说，开源利大于弊。我们报告相应的收益，希望更多的同学参与到Elastic生态的开源贡献中来。首先，开源可以降低分支维护成本。随着自研功能越来越多，维护独立分支的成本越来越高，主要体现在与开源版本的同步以及开源新特性的快速引入。其次，开源可以帮助研发同学更深入地掌握内核，了解最新的技术动态，因为开源反馈的过程会涉及到与官方开发者的持续互动。另外，开源有利于建立大家在社区的技术影响力，获得开源社区的认可。最后，Elastic生态系统的快速发展有利于商业服务和个人技术的发展。希望大家共同参与，助力Elastic生态的持续快速发展。在未来的规划上，本次分享重点介绍了腾讯在ES内核的优化实践，包括高可用、低成本、高性能。此外，我们还提供一套管控平台，支持在线集群的自动化管控、运维，为腾讯云客户提供ES服务。但从大量线上运营经验分析中，我们发现还有非常丰富和高价值的方向需要跟进，我们会继续加强产品和核心的建设。在长期探索方面，我们会结合大数据地图进行介绍。整个大数据领域可以根据数据量的特点和时延要求分为三个部分：数据工程，包括我们熟悉的批计算和流计算；数据发现，包括交互式分析、搜索等；DataApps，主要用于支持在线服务。虽然我们把ES放在了搜索领域，但是很多用户也用ES来支持在线搜索、文档服务等。另外，我们了解到很多成熟的OLAP系统也是基于倒排索引、行列混合存储等技术栈的.因此，我们认为未来ES在这两个领域发展的可行性是非常强的，未来我们会重点在OLAP分析和在线服务的方向进行探索。
