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

小提示：您能找到这篇{腾讯如何用Elasticsearch挖掘万亿数据价值？}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯如何用Elasticsearch挖掘万亿数据价值？内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

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

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

< ">< font-size: 18px;">一、ES的应用场景

< ">< font-size: 16px;">1.腾讯内部应用场景

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

< ">< font-size: 16px;">1.【日志实时分析场景】

< ">< font-size: 16px;">

典型场景如下：

< ">< font-size: 16px;">运营日志：< font-size: 16px;">如慢日志、异常日志（用来定位业务问题）；

< ">< font-size: 16px;">业务日志：< font-size: 16px;">如用户的点击、访问日志（用来分析用户行为）；

< ">< font-size: 16px;">审计日志：< font-size: 16px;">可用于安全分析。

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

< ">< font-size: 16px;">Elastic生态完整：< font-size: 16px;">任何一个开发者，可通过简单部署成熟的组件，搭建起一个完整的日志实时分析系统。

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

< ">< font-size: 16px;">灵活的搜索分析能力：< font-size: 16px;">由于支持倒排索引、列存储等数据结构，ES拥有非常灵活的搜索分析能力。

< ">< font-size: 16px;">搜索响应时间短：< font-size: 16px;">ES支持交互式分析，即使有万亿级的日志，其搜索响应时间也是秒级。

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

< ">< font-size: 16px;">2.【搜索服务场景】

< ">< font-size: 16px;">

典型场景如下：

< ">< font-size: 16px;">商品搜索：< font-size: 16px;">即各大电商平台中的商品搜索；

< ">< font-size: 16px;">APP搜索：< font-size: 16px;">即应用商店里的应用搜索；

站内搜索：即论坛、在线文档等搜索功能。

腾讯使用ES支持了大量的搜索服务，它们主要有以下特点：

< ">< font-size: 16px;">高性能：< font-size: 16px;">单个服务最大达到10w+QPS，平均响应时长约20ms，P95延时小于100ms。

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

< ">< font-size: 16px;">高可用：< font-size: 16px;">搜索场景通常要求4个9的可用性，并支持单机房故障容灾。

< ">< font-size: 16px;">3.【时序数据分析场景】

< ">< font-size: 16px;">

典型的时序数据包含：

< ">< font-size: 16px;">Metrics：< font-size: 16px;">即传统的服务器监控。

< ">< font-size: 16px;">APM：< font-size: 16px;">应用性能监控。

< ">< font-size: 16px;">传感器数据：< font-size: 16px;">由物联网数据，智能硬件、工业物联网等产生。

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

< ">< font-size: 16px;">高并发写入：< font-size: 16px;">线上单集群最大规模高达600+节点，写入吞吐量为1000w/s。

< ">< font-size: 16px;">高查询性能：< font-size: 16px;">要求单条曲线或者单个时间线的查询延时在10ms级。

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

< ">< font-size: 16px;">2.业界应用场景

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

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

< ">< font-size: 18px;">二、遇到的挑战

< ">< font-size: 16px;">1.腾讯遇到的挑战

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

< ">< font-size: 16px;">1.【搜索类】

< ">< font-size: 16px;">

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

< ">< font-size: 16px;">高性能：< font-size: 16px;">它们对性能有极高的标准，如20w QPS、平响20ms、P95延时100ms。

总之，在搜索类业务场景下，核心挑战点在于高可信息流广告深圳用、高性能。

< ">< font-size: 16px;">2.【时序类】

< ">< font-size: 16px;">

时序类场景包含日志、Metrics、APM等。相比于搜索类业务聚焦高可用、高性能的问题，时序类业务会更注重成本、性能。举个例子，时序场景用户通常要求高写入吞吐，部分场景可达1000w/s；在这样写入吞吐下，保留30天的数据，存储量可达PB级。如果用户用于线上实际业务的机器数量是100台，而监控、日志等需要50台，我想做公关这对多数用户来说基本是不可接受的（因为监控、日志的收益相对较低）。所以在时序类业务中，主要的挑战在于存储成本、计算成本等方面。

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

< ">< font-size: 16px;">2.业界遇到的挑战

业界也经历着与腾讯类似的挑战。还是以电子商务网站M为例，电商经常性的大促，他们不得不关注ES集群的稳定性和集群的容灾备份。

在集群稳定性方面，他们经常碰到的问题是“范围较大的查询，会导致ES节点的JVM OOM（内存溢出），影响集群稳定性”，以及“索引数或分片数过多时，集群元数组变更慢且CPU负载高，从而影响集群稳定性”。

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

< ">< font-size: 18px;">三、ES优化实践

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

< ">< font-size: 16px;">1.系统健壮性：< font-size: 16px;">指ES内核自身的健壮性，这也是分布式系统面临的共性难题。例如：

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

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

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

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

< ">< font-size: 16px;">1.系统健壮性：

< ">< font-size: 16px;">服务不稳定：< font-size: 16px;">通过服务限流，容忍机器网络故障、异常查询等异常情况。

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

< ">< font-size: 16px;">集群均衡问题：< font-size: 16px;">通过优化节点、多硬盘间的分片均衡，保证大规模集群的压力均衡。

< ">< font-size: 16px;">2.容灾方案：

< ">< font-size: 16px;">数据可恢复：< font-size: 16px;">通过扩展ES的插件机制支持备份回档，把ES的数据备份回档到廉价存储，保证数据的可恢复；

< ">< font-size: 16px;">故障容忍：< font-size: 16px;">腾讯云ES支持跨可用区容灾，用户可以按需部署多个可用区，以容忍单机房故障。

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

< ">< font-size: 16px;">异常恢复：< font-size: 16px;">通过垃圾桶机制，保证用户在欠费、误操作等场景下，集群可快速恢复。

< ">< font-size: 16px;">3.系统缺陷：

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

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

< ">< font-size: 16px;">权限层级：< font-size: 16px;">优化后，ES支持XPack和自研权限来防止攻击和误操作；

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

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

< ">< font-size: 16px;">多租户层级：< font-size: 16px;">使用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、执行计划不优等原因造成的查询毛刺。

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

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

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

< ">< font-size: 16px;">（3）查询优化：< font-size: 16px;">通过优化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基础能力和开发运维效率都得到了显著的提升：

< ">< font-size: 16px;">可靠性：< font-size: 16px;">基于腾讯对ES内核优化后的能力，电子商务网站M的ES集群可靠性有着明显的提升，扛起了多重流量洪峰，收获了明显的经济效益。

< ">< font-size: 16px;">安全容灾：< font-size: 16px;">多可用区提供了容灾保障、X-Pack权限管理提供了安全保障；

< ">< font-size: 16px;">运维效率：< font-size: 16px;">云上提供了高效部署和稳定的弹性伸缩能力，X-Pack提供的SQL能力提升了操作便捷性；运维效率的提高极大地解放了人力。

特别值得一提的是，整个项目在迁移过程中非常平滑稳定：

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

迁移后仍保持了M自建ES时自研开发的运维系统的对接；

迁移过程中，M对内核的特殊需求，ES社区版本并不支持，腾讯云ES专门的内核团队积极相应，提供了该能力。

< ">< font-size: 18px;">四、未来规划及开源贡献

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

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

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

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

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

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

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

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

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