阅读 2187

腾讯如何用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技术。

最后

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

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