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

原文：https://mp.weixin.qq.com/s/FVbjGTvZP97u5CAydDx7dw

前言

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

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

1、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集群，而且规模不断在增加。

2、遇到的挑战

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负载高，从而影响集群稳定性”。

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

3、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专门的内核团队积极相应，提供了该能力。

4、将来规划及开源贡献

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

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

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

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

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

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

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

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

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

最后

欢迎你们关注个人公众号【程序员追风】，2019年多家公司java面试题整理了1000多道400多页pdf文档，文章都会在里面更新，整理的资料也会放在里面。

喜欢文章记得关注我点个赞哟，感谢支持！