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

本文转载自：https://mp.weixin.qq.com/s/FVbjGTvZP97u5CAydDx7dw

Elasticsearch（ES）是近年来炙手可热的开源分布式搜索分析引擎，通过简单部署，它可以轻松实现日志实时分析、全文检索、结构化数据分析等多重诉求，并将挖掘数据价值的成本大幅降低。

ES在腾讯内部和腾讯云用户中拥有丰富的大规模落地场景，它们持续地推动着原生ES朝着高可用、高性能、低成本的方向优化。本文即将介绍腾讯在ES的应用落地过程中，遇到的挑战、优化思路、优化成果和未来探索方向，希望能为开发者们提供参考。

 

一、ES的应用场景

 

 1.腾讯内部应用场景
在腾讯内部，ES的应用场景主要有“日志实时分析、搜索服务、时序数据分析等。

1.【日志实时分析场景】

 

典型场景如下：

 

运营日志：如慢日志、异常日志（用来定位业务问题）；

 

业务日志：如用户的点击、访问日志（用来分析用户行为）；

 

审计日志：可用于安全分析。

ES 完美解决了日志实时分析的需求，它具有如下特点：

 

Elastic生态完整：任何一个开发者，可通过简单部署成熟的组件，搭建起一个完整的日志实时分析系统。

 

时效性极高：日志从产生到可访问的耗时一般在10S级。相比于传统大数据解决方案几十分钟~几小时的耗时，时效性提高了数百倍。

 

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

 

搜索响应时间短：ES支持交互式分析，即使有万亿级的日志，其搜索响应时间也是秒级。

 

ES在这几年的蓬勃发展，离不开它完美地支持“日志实时分析场景”这一能力。

 

 2.【搜索服务场景】

 

典型场景如下：

 

商品搜索：即各大电商平台中的商品搜索；

APP 搜索：即应用商店里的应用搜索；站内搜索：即论坛、在线文档等搜索功能。
腾讯使用ES支持了大量的搜索服务，它们主要有以下特点：

 

高性能：单个服务最大达到 10w+ QPS，平均响应时长约20ms，P95延时小于100ms。

 

强相关：搜索体验主要取决于“搜索结果”与“用户意图”之间的匹配度，可通过正确率、召回率等指标进行评估。

 

高可用：搜索场景通常要求4个9的可用性，并支持单机房故障容灾。

 3.【时序数据分析场景】

 

典型的时序数据包含：

Metrics：即传统的服务器监控。

APM：应用性能监控。

传感器数据：由物联网数据，智能硬件、工业物联网等产生。

腾讯很早就涉足了这类场景，并积累了深厚的经验。这类场景具有以下特点：

 

高并发写入：线上单集群最大规模高达 600+节点，写入吞吐量为1000w/s 。

 

高查询性能：要求单条曲线或者单个时间线的查询延时在10ms级。

 

多维分析：要求灵活、多维度的统计分析能力，如在查看监控时，可以按照地域、业务模块等不同维度进行统计分析。 

 

 2.业界应用场景

 

在业界，ES的主要应用场景更多见于电子商务平台上，比如对商品、标签、店铺的搜索。

 

年GMV达到200亿的电子商务网站M就是一个典型的例子，它在ES的应用场景也非常广泛，包括商品搜索推荐、日志分析监控、统计分析等。其业务团队运行着几十个ES集群，并且规模不断在增长。

 

二、遇到的挑战

  1.腾讯遇到的挑战
在腾讯内部如此大规模、高压力、多场景的业务背景下，ES的应用着实遭到了不少挑战，这些挑战基本可以划分为两类：搜索类和时序类。

 

 1.【搜索类】

 

 

高可用：以电商搜索、APP 搜索、站内搜索为例，它们重视可用性，服务SLA为4个9以上，需要考虑单机故障、单机房网络故障等灾备场景。

 

高性能：它们对性能有极高的标准，如 20w QPS、平响 20ms、P95延时100ms。

总之，在搜索类业务场景下，核心挑战点在于高可用、高性能。

 

 2.【时序类】

 

 

时序类场景包含日志、Metrics、APM 等。相比于搜索类业务聚焦高可用、高性能的问题，时序类业务会更注重成本、性能。 

举个例子，时序场景用户通常要求高写入吞吐，部分场景可达 1000w/s；在这样写入吞吐下，保留30天的数据，存储量可达PB级。如果用户用于线上实际业务的机器数量是 100 台，而监控、日志等需要 50 台，这对多数用户来说基本是不可接受的（因为监控、日志的收益相对较低）。

所以在时序类业务中，主要的挑战在于存储成本、计算成本等方面。

面对如此艰巨的挑战，腾讯在ES内核方面进行了深入的优化实践（这种优化后的成果也通过腾讯云开放给了外界的用户，其中就有电子商务网站M）。

 2.业界遇到的挑战 

业界也经历着与腾讯类似的挑战。还是以电子商务网站M为例，电商经常性的大促，他们不得不关注ES集群的稳定性和集群的容灾备份。
在集群稳定性方面，他们经常碰到的问题是“范围较大的查询，会导致ES节点的JVM OOM（内存溢出），影响集群稳定性”，以及“索引数或分片数过多时，集群元数组变更慢且CPU负载高，从而影响集群稳定性”。

在容灾备份方面，他们经常碰到的问题是“单机房故障时，如何保证服务不中断”，以及“故障发生后，数据如何恢复”。

 

三、ES 优化实践

首先，针对“高可用”的需求，腾讯的开发者们化整为零，各个突破，把高可用划分为三个维度：

 

1系统健壮性：指 ES 内核自身的健壮性，这也是分布式系统面临的共性难题。例如：

 

在异常查询、压力过载下集群的容错能力；在高压力场景下，集群的可扩展性；在集群扩容、节点异常场景下，节点、多硬盘之间的数据均衡能力。

 

2.容灾方案：如通过建设管控系统，保障机房网络故障时快速恢复服务、自然灾害下防止数据丢失、误操作后快速回滚等。

 

3.系统缺陷：这是任何系统在发展的过程中都不可避免的问题，比如Master 节点堵塞、分布式死锁、滚动重启缓慢等。

 

针对上述问题，腾讯的ES解决方案如下：

 

 

 

1.  系统健壮性：

 

服务不稳定：通过服务限流，容忍机器网络故障、异常查询等异常情况。

 

集群扩展性问题：通过优化集群元数据管控逻辑，提升了10倍的集群扩展能力，支持千级节点集群、百万分片；

 

集群均衡问题：通过优化节点、多硬盘间的分片均衡，保证大规模集群的压力均衡。

 

2.  容灾方案：

 

数据可恢复：

通过扩展 ES 的插件机制支持备份回档，把 ES 的数据备份回档到廉价存储，保证数据的可恢复；

 

故障容忍：

腾讯云ES支持跨可用区容灾，用户可以按需部署多个可用区，以容忍单机房故障。

 

此外，腾讯云ES还支持COS备份的功能，用户可以通过操作ES的api，直接备份底层的数据文件到腾讯云对象存储COS上，实现了低成本、操作简便的数据备份功能。

 

异常恢复：

通过垃圾桶机制，保证用户在欠费、误操作等场景下，集群可快速恢复。

 

3.  系统缺陷：

 

腾讯修复了原生ES在滚动重启、Master 阻塞、分布式死锁等方面的Bug。其中滚动重启优化，可加速节点重启速度5倍以上；Master 堵塞问题，腾讯在ES6.x版本和Elastic官方一起做了优化。

 

 

在服务限流部分，腾讯做了 4 个层级的限流工作：

 

权限层级：优化后，ES支持 XPack 和自研权限来防止攻击和误操作；

 

队列层级：通过优化任务执行速度、重复、优先级等细节，解决用户经常遇到的Master 任务队列堆积、任务饿死等问题；

 

内存层级：从ES 6.x 开始，支持在全链路上（ 包括HTTP 入口、协调节点、数据节点等）进行内存限流：同时使用 JVM 内存、梯度统计等方式进行精准控制；

 

多租户层级：使用 CVM/Cgroups 方案保证多租户间的资源隔离。

 

这里展开介绍下聚合场景限流的问题，用户在使用 ES 进行聚合分析时，经常因聚合分桶过多打爆内存。官方在 ES 6.8 中提供 max_buckets 参数控制聚合的最大分桶数，但这个方式局限性非常强：内存是否会被打爆还取决于单分桶的大小（在某些场景下，用户设置 20 万个分桶可以正常工作，但在另一些场景下，可能 10 万个分桶内存就已经打爆），因此用户并不能准确把握该参数应设置为多少。

此时腾讯采用梯度算法进行优化，每分配 1000 个分桶检查一次 JVM 内存，当内存不足时及时中断请求，保证了ES集群的高可用。 这些限流方案，能够解决在异常查询、压力过载、单节点故障、网络分区等场景下，ES 服务的稳定性问题。但还有少量场景没有触达，因此腾讯目前正在探索，通过依赖混沌测试覆盖更多异常场景。

针对“索引数或分片数过多，导致的集群元数据变更慢且CPU负载高，从而影响集群稳定性”的问题，在内核上，腾讯优化了shard分配的算法，利用缓存节点routing表和元数据增量更新的方法，加快集群元数据的变更速度。 

解决了高可用和高性能的问题，下面该谈谈成本优化方面的实践了。

 

 

 

成本方面的挑战，主要体现在时序场景（如日志、监控）对机器资源的消耗，通过对线上典型的日志、时序业务分析可得，硬盘、内存、计算资源的成本比例接近 8:4:1。也就是说，硬盘、内存是主要矛盾，其次是计算成本。 时序数据有很明显的访问特性：”近多远少”。最近七天数据的访问量占比大于95%；历史数据访问较少，且通常都是访问统计类信息。

 

 

基于这些瓶颈分析和数据访问特性，成本优化的解决方案如下：

 

（1）采用冷热分离架构，使用混合存储的方案来平衡成本、性能；

 

（2）既然对历史数据通常都是访问统计信息，那么通过预计算来换取存储和性能；

 

（3）如果历史数据完全不使用，可以备份到更廉价的存储系统；

 

（4）基于时序数据的访问特性，内存成本方面可以利用 Cache 进行优化。

 

（5）其他一些优化方式：如存储裁剪、生命周期管理等。

 

这里展开介绍下 Rollup 部分。Rollup 类似于大数据场景下的Cube、物化视图，它的核心思想是通过预计算提前生成统计信息，释放原始粒度数据，从而降低存储成本、提高查询性能。这里举个简单的例子：在机器监控场景下，原始粒度的监控数据是10 秒级的，而一个月之前的监控数据，一般只需查看小时粒度，这即是一个 Rollup 应用场景。官方从 ES 6.x 开始推出 Rollup，实际上腾讯在 5.x 已经着手研究。 在大数据领域，传统的方案是依赖外部离线计算系统，周期性地读取全量数据进行计算，这种方式计算开销、维护成本高。

谷歌的广告指标系统 Mesa 采用持续生成方案，数据写入时系统给每个 Rollup 产生一份输入数据，并对数据进行排序，底层在 Compact/Merge 过程中通过多路归并完成 Rollup，这种方式的计算、维护成本相对较低。

ES 从 6.x 开始支持数据排序，腾讯通过流式查询进行多路归并生成 Rollup，最终计算开销小于全量数据写入时 CPU 开销的 10%，内存使用小于10MB。这种内核优化方式已被腾讯贡献给开源社区，以解决开源 Rollup 的计算、内存瓶颈。

 

 

前文提及很多用户在使用大存储机型时，内存优先成为瓶颈、硬盘不能充分利用，这类问题主要瓶颈在于索引占用大量内存。考虑到时序类场景很少访问历史数据，部分场景下某些字段基本不使用，所腾讯通过引入 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、执行计划不优等原因造成的查询毛刺。

 

针对上述问题，腾讯亦有对策：

 

（1）写入优化：针对主键去重场景，利用索引进行裁剪，加速主键去重的过程，使写入性能提升 45%。此外，通过向量化执行优化写入性能，通过减少分支跳转、指令 Miss，也是腾讯探索中的方向之一，预计性能可提升1倍。

 

（2）CPU利用率优化：针对部分压测场景下 CPU 不能充分利用的问题，通过优化 ES 刷新 Translog 时的资源抢占，使性能提升 20%。

 

（3）查询优化：通过优化 Merge 策略提升查询性能。基于每个 Segment 记录的 min/max 索引进行查询剪枝，提升了30%的查询性能 。通过CBO策略，避免查询 Cache 操作导致查询耗时10+倍的毛刺。此外，通过一些新硬件（如英特尔的 AEP、Optane、QAT 等）来优化性能也是不错的探索方向。

 

 

下面，详细谈谈Merge 策略优化部分：ES 原生的 Merge 策略主要关注大小相似性（Merge 时尽量选择大小相似的 Segments）和最大上限（考虑尽量把 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后，电子商务网站M的ES基础能力和开发运维效率都得到了显著的提升：

可靠性：基于腾讯对ES内核优化后的能力，电子商务网站M的ES集群可靠性有着明显的提升，扛起了多重流量洪峰，收获了明显的经济效益。
安全容灾：多可用区提供了容灾保障、X-Pack权限管理提供了安全保障；
运维效率：云上提供了高效部署和稳定的弹性伸缩能力，X-Pack提供的SQL能力提升了操作便捷性；运维效率的提高极大地解放了人力。
特别值得一提的是，整个项目在迁移过程中非常平滑稳定：

M原有ES集群实现了完全不停服迁移；

迁移后仍保持了M自建ES时自研开发的运维系统的对接；
迁移过程中，M对内核的特殊需求，ES社区版本并不支持，腾讯云ES专门的内核团队积极相应，提供了该能力。

 

四、未来规划及开源贡献

目前，国内有很多ES在“查询范围较大”和“索引或分片数较多”的应用场景，因此国内社区开发者也格外关注于此。在这两个领域，腾讯云ES的优化方案，因其全面性和代码整洁性，已被Elastic官方所采纳。

近半年腾讯向开源社区提交了 10+PR，涉及写入、查询、集群管理等各个模块（部分优化功能是与Elastic官方开发一同完成）。腾讯内部组建了Elasticsearch开源协同的小组，让来自腾讯的所有开发者，都能参与到 Elastic 的生态建设中。

 

 

目前，腾讯联合 Elastic 公司，已在腾讯云上推出了内核增强版的 ES 云服务，将万亿级搜索的能力对外输出。不过，ES的发展仍有非常多有价值的方向可以深入研究，这也是腾讯云在上线产品后迭代优化产品、持续内核建设的原因。

 

未来，腾讯还将进行长期探索：

 

以大数据图谱为思路，整个大数据领域按照数据量、延时要求等特点，可以分为三部分：

 

(1) DataEngineering，包含大家熟悉的批量计算、流式计算；

 

(2) DataDiscovery，包含交互式分析、搜索等；

 

(3) DataApps，主要用于支撑在线服务。

 

虽然 ES 被视为搜索领域内的技术，但是 ES 也支持在线搜索、文档服务等场景；另外，有不少成熟的 OLAP 系统，也是基于倒排索引、行列混存等技术栈。由此可以看出， ES 往这两个领域发展的可行性非常强。因此，腾讯会重点朝“在线服务”和“OLAP 分析”等方向探索ES技术。

 

关注「腾讯开发者」专业的开发者都关注了