腾讯如何用Elasticsearch挖掘万亿数据价值？

Elasticsearch（ES）分布式搜索分析引擎作为开源的首选，很容易满足用户日志实时分析、全文检索、结构化数据分析等需求，大大降低了大数据时代挖掘数据价值的成本。

腾讯在公司内部丰富的场景中大规模使用ES，同时联合Elastic 公司在腾讯云上提供核心增强版ES 云服务、大规模、丰富多样的使用场景推动了腾讯对本土的利用ES 持续高可用性、高性能、低成本优化。

一、ES 在腾讯的应用场景

【ES 腾讯应用场景】

我们最初使用它ES 典型的日志如下：

用于定位业务问题的操作日志，如慢日志和异常日志；

业务日志，如用户点击、访问日志，可用于分析用户行为；

可用于安全分析的审计日志。ES 它完美地解决了日志实时分析的需要，具有以下特点：

Elastic 生态系统提供完整的日志解决方案，任何开发、操作和维护学生都可以通过简单的部署建立完整的日志实时分析服务。

在Elastic 在生态学中，日志从产生到可访问通常是10s 等级。与传统的大数据解决方案相比，时效性很高。

支持倒排索引、列存储等数据结构，ES 提供非常灵活的搜索分析能力。

即使在万亿级日志的情况下，支持交互式分析，ES 搜索响应时间也是秒级。

日志是互联网行业最基本、最广泛的数据形式，ES 这也是近年来日志实时分析场景的完美解决方案ES 快速发展的一个重要原因。

第二种使用场景是搜索服务，典型场景包括:商品搜索，类似JD.COM、淘宝、拼多多；APP 搜索，支持应用商店的应用搜索；站点搜索，支持论坛、在线文档和其他搜索功能。我们支持大量的搜索服务，主要具有以下特点：

高性能：单项服务最大可达10项w QPS，平响20ms~，P95 延时小于100ms。

强相关性：搜索体验主要取决于搜索结果是否与用户意图高度匹配，需要通过正确率、召回率等指标进行评估。

高可用性：搜索场景通常要求4 个9 支持单机房故障容灾的可用性。淘宝、JD.COM、拼多多等任何电商服务，只要故障一小时就可以上头条。

第三种使用场景是时序数据分析，典型的时序数据包括：Metrics，即传统的服务器监控；APM，应用性能监控；物联网数据、智能硬件、工业物联网等传感器数据。腾讯很早就开始探索这种场景，并在这方面积累了丰富的经验。这种场景具有以下特点：

高并发写入:线上单集群最大规模达到600 节点、1000w/s 的写入吞吐。

高查询性能：单曲线或单时间线的查询延迟为10ms~。

多维分析：需要灵活、多维的统计分析能力。例如，当我们检查监控时，我们可以根据区域和业务模块进行灵活的统计分析。

二、遇到挑战

我们前面介绍过ES 在腾讯的广泛应用中，在如此大规模、高压、丰富的使用场景的背景下，我们遇到了许多挑战，可分为搜索和时间顺序两类。

首先，让我们来看看搜索业务的挑战。电子商务搜索，APP 以搜索和站内搜索为代表，非常重视可用性和服务SLA 达到4 个9 以上，需要容忍单机故障、单机房网络故障等；同时要求高性能、低毛刺，例如20w QPS、平响20ms、P95 延时100ms。总之，在搜索业务场景中，核心挑战是高可用性和高性能。

另一种我们称之为时序业务挑战，包括日志，Metrics、APM 等场景。与关注高可用性和高性能的搜索业务相比，时序业务将更加关注成本和性能。例如，时序场景用户通常需要高写入吞吐量，有些场景可以达到1万w/s WPS；这样写下吞吐，保留30 天数据通常可以实现PB 等级存储量。现实是日志、监控等场景的收入相对较低，用户在线实际业务中使用的机器数量很可能为100台 台湾需要50个监控和日志 对对大多数用户来说基本上是不可接受的。因此，在时序业务中，主要挑战是存储成本、计算成本等。

在此之前，我们介绍了高可用性、低成本、高性能等在搜索和时序业务场景中遇到的挑战。针对这些挑战，我们将重点分享腾讯在ES 深入实践核心。

三、ES 优化实践

首先，让我们来看看高可用性优化。我们将高可用性分为三个维度：

系统健壮：指ES 核心本身的强度也是分布式系统面临的一个常见问题。例如，集群在异常查询和压力过载下的容错能力；集群在高压场景下的可扩展性；节点和多硬盘之间的数据平衡能力。

灾害容忍方案：如果通过控制系统建设，确保机房网络故障快速恢复服务，防止自然灾害下数据丢失，误操作后快速恢复。

系统缺陷：这将在任何系统开发过程中继续产生，例如Master 节点堵塞、分布式死锁、滚动重启缓慢等。

针对上述问题，以下是我们在高可用性方面的解决方案：

在系统强度方面，我们通过服务流量限制来容忍机器网络故障和异常查询造成的服务不稳定。通过优化集群元数据控制逻辑，提高集群扩展能力，支持1000级节点集群和100万片，解决集群可扩展性问题；在集群平衡方面，通过优化节点和多硬盘之间的平衡，确保大规模集群的压力平衡。

在容灾方案方面，我们通过扩大ES 支持备份归档的插件机制ES 数据备份归档到廉价存储，以确保数据的可恢复；支持跨可用区域的灾难，用户可以根据需要部署多个可用区域，以容忍单机房的故障。垃圾桶机制确保用户能够在拖欠和误操作的情况下快速恢复集群。

在系统缺陷方面，我们修复了滚动重启，Master 阻塞、分布式死锁等一系列Bug。滚动重启优化可加速节点重启速度5 倍，Master 堵塞问题，我们在ES 6.x 版本和官方一起优化。

在这里，我们将介绍服务限流部分。我们做了4 各级限流工作：权限级，我们支持XPack 通过优化任务执行速度、重复、优先级等问题，解决用户经常遇到的问题Master 任务队列积累、任务饥饿等问题；内存水平，我们从ES 6.x 开始，支持在HTTP 内存限流在入口、协调节点、数据节点等全链路上，同时使用二手手机靓号拍卖JVM 精确控制内存和梯度统计；我们使用多租户级别CVM/Cgroups 该计划确保多租户之间的资源隔离。

这里详细介绍聚合场景的流量限制。用户正在使用它ES 在进行聚合分析时，由于聚合分桶过多，经常会出现内存爆炸的问题。官方在ES 6.8 中提供max_buckets 参数控制聚合的最大分桶数，但这种方法非常有限。在某些情况下，用户设置20 一万桶可以正常工作，但在其他情况下，可能是10 一万桶内存已经爆炸，这主要取决于单桶的大小，用户无法准确掌握参数设置的数量。在聚合分析过程中，采用梯度算法进行优化，每分配1万 检查一次个分桶JVM 内存，当内存不足时及时中断请求，确保ES 高可用集群。

在异常查询、压力过载、单节点故障、网络分区等场景下，我们目前的限流方案，ES 服务的稳定性。但是还是有少数场景没有完全覆盖，所以我们也在引入混沌测试，依靠混沌测试来覆盖更多的异常场景。

我们之前介绍了高可用性解决方案，下面介绍了成本优化实践。成本挑战主要体现在以日志和监控为代表的时间场景对机器资源的消耗上。我们分析了典型的在线日志和时间业务。一般来说，硬盘、内存和计算资源的成本比接近8:4:1。硬盘和内存是主要矛盾，其次是计算成本。

通过分析时序场景，可以发现时序数据具有明显的访问特性。一是冷热特性，时序数据访问近多少，近7 访问天数据的比例可达95%以上；历史数据访问较少，通常是访问统计信息。

基于这些瓶颈分析和数据访问特性，我们将介绍成本优化的解决方案。

在硬盘成本方面，由于数据具有明显的冷热特性，首先采用冷热分离架构，采用混合存储方案来平衡成本和性能；其次，由于历史数据通常访问统计信息，以交换存储和性能；如果不使用历史数据，也可以备份到更便宜的存储系统；其他优化方法包括存储切割、生命周期管理等。

在内存成本方面，许多用户在使用大型存储模型时会发现，存储资源只使用了20%，内存不足。事实上，我们可以根据时间序列数据的访问特性来使用它Cache 优化，稍后介绍。

让我们介绍一下Rollup 部分。官方从ES 6.x 开始推出Rollup，其实腾讯在5.x 这部分实践已经开始。Rollup 类似于大数据场景Cube、物化视图的核心思想是通过预计算提前生成统计信息，释放原始粒度数据，从而降低存储成本，提高查询性能，通常有数据收入。例如，在机器监控场景中，原始粒度监控数据为10 秒级，一个月前的监控数据，一般只需要查看小时粒度，这是一个Rollup 应用场景。

在大数据领域，传统的方案是依赖外部离线计算系统，周期性的读取全量数据进行计算，这种方式计算开销、维护成本高。谷歌的广告指标系统Mesa 采用连续生成方案，系统将数据写入每个方案Rollup 产生输入数据并对数据进行排序Compact/Merge 多路归并完成过程Rollup，这种方法的计算和维护成本相对较低。ES 从6.x 开始支持数据排序，我们通过流式查询进行多路归并生成Rollup，最终计算费用小于全数据CPU 10%的费用，少于10%的内存使用MB。

接下来，我们展开介绍内存优化部分。前面提到很多用户在使用大存储机型时，内存优先成为瓶颈、硬盘不能充分利用的问题，主要瓶颈在于索引占用大量内存。但是我们知道时序类场景对历史数据访问很少，部分场景下某些字段基本不使用，所我们可以通过引入Cache 来提高内存利用效率。

在内存优化方面，业界的方案是什么样的呢？ES 社区从7.x 后支持索引放于堆外，和DocValue 一样按需加载。但这种方式不好的地方在于索引和数据的重要性完全不同，一个大查询很容易导致索引被淘汰，后续查询性能倍数级的衰减。Hbase 通过缓存Cache 缓存索引、数据块，提升热数据访问性能，并且从HBase 2.0 开始，重点介绍其Off Heap 技术，重点在于堆外内存的访问性能可接近堆内。

我们基于社区经验进行迭代，在ES 中引入LFU Cache 以提高内存的利用效率，把Cache 放置在堆外以降低堆内存压力，同时通过Weak Reference、减少堆内外拷贝等技术降低损耗。最终效果是内存利用率提升80%，可以充分利用大存储机型，查询性能损耗不超过2%，GC 开销降低30%。

前面我们介绍了可用性、成本优化的解决方案，最后我们来介绍性能方面的优化实践。以日志、监控为代表的时序场景，对写入性能要求非常高，写入并发可达1000w/s。然而我们发现在带主键写入时，ES 性能衰减1+倍，部分压测场景下，CPU 无法充分利用。以搜索服务为代表的场景，对查询性的要求非常高，要求20w QPS, 平响20ms，而且尽量避免GC、执行计划不优等造成的查询毛刺。

针对上述问题，我们介绍下腾讯在性能方面的优化实践：

写入方面，针对主键去重场景，通过利用索引进行裁剪，加速主键去重的过程，写入性能提升45%。对于部分压测场景下CPU 不能充分利用的问题，通过优化ES 刷新Translog 时的资源抢占，提升性能提升20%。我们正在尝试通过向量化执行优化写入性能，通过减少分支跳转、指令Miss，预期写入性能可提升1 倍。

查询方面，我们通过优化Merge 策略，提升查询性能，这部分稍后展开介绍。基于每个Segment 记录的min/max 索引，进行查询剪枝，提升查询性能30%。通过CBO 策略，避免查询Cache 操作导致查询耗时10+倍的毛刺。此外，我们也在尝试通过一些新硬件来优化性能，比如说英特尔的AEP、Optane、QAT 等。

接下来我们展开介绍下Merge 策略优化部分。ES 原生的Merge 策略主要关注大小相似性和最大上限，大小相似性是指Merge 时尽量选择大小相似的Segments 进行Merge，最大上限则考虑尽量把Segment 拼凑到5GB。那么有可能出现某个Segment 中包含了1 月整月、3 月1 号的数据，当用户查询3 月1 号某小时的数据时，就必须扫描大量无用数据，性能损耗严重。

我们在ES 中引入了时序Merge，在选择Segments 进行Merge 时，重点考虑时间因素，这样时间相近的Segments 被Merge 到一起。当我们查询3 月1 号的数据时，只需要扫描个别较小的Segments 就好，其他的Segments 可以快速裁剪掉。

另外，ES 官方推荐搜索类用户在写入完成之后，进行一次Force Merge，用意是把所有Segments 合并为一个，以提高搜索性能。但这增加了用户的使用成本，且在时序场景下，不利于裁剪，需要扫描全部数据。我们在ES 中引入了冷数据自动Merge，对于非活跃的索引，底层Segments 会自动Merge 到接近5GB，降低文件数量的同时，方便时序场景裁剪。对于搜索场景，用户可以调大目标Segment 的大小，使得所有Segments 最终Merge 为一个。我们对Merge 策略的优化，可以使得搜索场景性能提升1 倍。

前面介绍完毕我们再ES 内核方面的优化实践，最后我们来简单分享下我们在开源贡献及未来规划方面的思考。

四、未来规划及开源贡献

近半年我们向开源社区提交了10+PR，涉及到写入、查询、集群管理等各个模块，部分优化是和官方开发同学一起来完成的，前面介绍过程中，已经给出相应的PR 链接，方便大家参考。我们在公司内部也组建了开源协同的小组，来共建Elastic 生态。

总体来说，开源的收益利大于弊，我们把相应收益反馈出来，希望更多同学参与到Elastic 生态的开源贡献中：首先，开源可以降低分支维护成本，随着自研的功能越来越多，维护独立分支的成本越来越高，主要体现在与开源版本同步、快速引入开源新特性方面；其次，开源可以帮助研发同学更深入的把控内核，了解最新技术动态，因为在开源反馈的过程中，会涉及与官方开发人员持续的交互。

此外，开源有利于建立大家在社区的技术影响力，获得开源社区的认可。最后Elastic 生态的快速发展，有利于业务服务、个人技术的发展，希望大家一起参与进来，助力Elastic 生态持续、快速的发展。

未来规划方面，这次分享我们重点介绍了腾讯在ES 内核方面的优化实践，包含高可用、低成本、高性能等方面。此外，我们也提供了一套管控平台，支持线上集群自动化管控、运维，为腾讯云客户提供ES 服务。但是从线上大量的运营经验分析，我们发现仍然有非常丰富、高价值的方向需要继续跟进，我们会持续继续加强对产品、内核的建设。

长期探索方面，我们结合大数据图谱来介绍。整个大数据领域，按照数据量、延时要求等特点，可以划分为三部分：第一部分是Data Engineering，包含我们熟悉的批量计算、流式计算；第二部分是Data Discovery，包含交互式分析、搜索等；第三个部分是Data Apps，主要用于支撑在线服务。

虽然我们把ES 放到搜索领域内，但是也有很多用户使用ES 支持在线搜索、文档服务等；另外，我们了解到有不少成熟的OLAP 系统，也是基于倒排索引、行列混存等技术栈，所以我们认为ES 未来往这两个领域发展的可行性非常强，我们未来会在OLAP 分析和在线服务等方向进行重点探索。