原文:https://mp.weixin.qq.com/s/FVbjGTvZP97u5CAydDx7dw
前言
Elasticsearch(ES)是近年来炙手可热的开源分布式搜索分析引擎,通过简单部署,它可以轻松实现日志实时分析、全文检索、结构化数据分析等多重诉求,并将挖掘数据价值的成本大幅降低。
ES在腾讯内部和腾讯云用户中拥有丰富的大规模落地场景,它们持续地推动着原生ES朝着高可用、高性能、低成本的方向优化。本文即将介绍腾讯在ES的应用落地过程中,遇到的挑战、优化思路、优化成果和未来探索方向,希望能为开发者们提供参考。
一、ES的应用场景
1.腾讯内部应用场景
运营日志:如慢日志、异常日志(用来定位业务问题);
业务日志:如用户的点击、访问日志(用来分析用户行为);
审计日志:可用于安全分析。
Elastic生态完整:任何一个开发者,可通过简单部署成熟的组件,搭建起一个完整的日志实时分析系统。
时效性极高:日志从产生到可访问的耗时一般在10S级。相比于传统大数据解决方案几十分钟~几小时的耗时,时效性提高了数百倍。
灵活的搜索分析能力:由于支持倒排索引、列存储等数据结构,ES拥有非常灵活的搜索分析能力。
搜索响应时间短:ES支持交互式分析,即使有万亿级的日志,其搜索响应时间也是秒级。
2.【搜索服务场景】
典型场景如下:
商品搜索:即各大电商平台中的商品搜索;
高性能:单个服务最大达到 10w+ QPS,平均响应时长约20ms,P95延时小于100ms。
强相关:搜索体验主要取决于“搜索结果”与“用户意图”之间的匹配度,可通过正确率、召回率等指标进行评估。
高可用:搜索场景通常要求4个9的可用性,并支持单机房故障容灾。
3.【时序数据分析场景】
Metrics:即传统的服务器监控。
APM:应用性能监控。
传感器数据:由物联网数据,智能硬件、工业物联网等产生。
高并发写入:线上单集群最大规模高达 600+节点,写入吞吐量为1000w/s 。
高查询性能:要求单条曲线或者单个时间线的查询延时在10ms级。
多维分析:要求灵活、多维度的统计分析能力,如在查看监控时,可以按照地域、业务模块等不同维度进行统计分析。
2.业界应用场景
在业界,ES的主要应用场景更多见于电子商务平台上,比如对商品、标签、店铺的搜索。
年GMV达到200亿的电子商务网站M就是一个典型的例子,它在ES的应用场景也非常广泛,包括商品搜索推荐、日志分析监控、统计分析等。其业务团队运行着几十个ES集群,并且规模不断在增长。
二、遇到的挑战
1.腾讯遇到的挑战
高可用:以电商搜索、APP 搜索、站内搜索为例,它们重视可用性,服务SLA为4个9以上,需要考虑单机故障、单机房网络故障等灾备场景。
高性能:它们对性能有极高的标准,如 20w QPS、平响 20ms、P95延时100ms。
时序类场景包含日志、Metrics、APM 等。相比于搜索类业务聚焦高可用、高性能的问题,时序类业务会更注重成本、性能。
2.业界遇到的挑战
三、ES 优化实践
1系统健壮性:指 ES 内核自身的健壮性,这也是分布式系统面临的共性难题。例如:
2.容灾方案:如通过建设管控系统,保障机房网络故障时快速恢复服务、自然灾害下防止数据丢失、误操作后快速回滚等。
3.系统缺陷:这是任何系统在发展的过程中都不可避免的问题,比如Master 节点堵塞、分布式死锁、滚动重启缓慢等。
1. 系统健壮性:
服务不稳定:通过服务限流,容忍机器网络故障、异常查询等异常情况。
集群扩展性问题:通过优化集群元数据管控逻辑,提升了10倍的集群扩展能力,支持千级节点集群、百万分片;
集群均衡问题:通过优化节点、多硬盘间的分片均衡,保证大规模集群的压力均衡。
2. 容灾方案:
数据可恢复:
通过扩展 ES 的插件机制支持备份回档,把 ES 的数据备份回档到廉价存储,保证数据的可恢复;
故障容忍:
腾讯云ES支持跨可用区容灾,用户可以按需部署多个可用区,以容忍单机房故障。
此外,腾讯云ES还支持COS备份的功能,用户可以通过操作ES的api,直接备份底层的数据文件到腾讯云对象存储COS上,实现了低成本、操作简便的数据备份功能。
异常恢复:
通过垃圾桶机制,保证用户在欠费、误操作等场景下,集群可快速恢复。
3. 系统缺陷:
在服务限流部分,腾讯做了 4 个层级的限流工作:
权限层级:优化后,ES支持 XPack 和自研权限来防止攻击和误操作;
队列层级:通过优化任务执行速度、重复、优先级等细节,解决用户经常遇到的Master 任务队列堆积、任务饿死等问题;
内存层级:从ES 6.x 开始,支持在全链路上( 包括HTTP 入口、协调节点、数据节点等)进行内存限流:同时使用 JVM 内存、梯度统计等方式进行精准控制;
多租户层级:使用 CVM/Cgroups 方案保证多租户间的资源隔离。
这里展开介绍下聚合场景限流的问题,用户在使用 ES 进行聚合分析时,经常因聚合分桶过多打爆内存。官方在 ES 6.8 中提供 max_buckets 参数控制聚合的最大分桶数,但这个方式局限性非常强:内存是否会被打爆还取决于单分桶的大小(在某些场景下,用户设置 20 万个分桶可以正常工作,但在另一些场景下,可能 10 万个分桶内存就已经打爆),因此用户并不能准确把握该参数应设置为多少。此时腾讯采用梯度算法进行优化,每分配 1000 个分桶检查一次 JVM 内存,当内存不足时及时中断请求,保证了ES集群的高可用。
基于这些瓶颈分析和数据访问特性,成本优化的解决方案如下:
(1)采用冷热分离架构,使用混合存储的方案来平衡成本、性能;
(2)既然对历史数据通常都是访问统计信息,那么通过预计算来换取存储和性能;
(3)如果历史数据完全不使用,可以备份到更廉价的存储系统;
(4)基于时序数据的访问特性,内存成本方面可以利用 Cache 进行优化。
(5)其他一些优化方式:如存储裁剪、生命周期管理等。
这里展开介绍下 Rollup 部分。Rollup 类似于大数据场景下的Cube、物化视图,它的核心思想是通过预计算提前生成统计信息,释放原始粒度数据,从而降低存储成本、提高查询性能。这里举个简单的例子:在机器监控场景下,原始粒度的监控数据是10 秒级的,而一个月之前的监控数据,一般只需查看小时粒度,这即是一个 Rollup 应用场景。官方从 ES 6.x 开始推出 Rollup,实际上腾讯在 5.x 已经着手研究。
前文提及很多用户在使用大存储机型时,内存优先成为瓶颈、硬盘不能充分利用,这类问题主要瓶颈在于索引占用大量内存。考虑到时序类场景很少访问历史数据,部分场景下某些字段基本不使用,所腾讯通过引入 Cache 来提高内存利用效率。
(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号某小时的数据时,就必须扫描大量无用数据,致使性能损耗严重。
四、未来规划及开源贡献
以大数据图谱为思路,整个大数据领域按照数据量、延时要求等特点,可以分为三部分:
(1) DataEngineering,包含大家熟悉的批量计算、流式计算;
(2) DataDiscovery,包含交互式分析、搜索等;
(3) DataApps,主要用于支撑在线服务。
虽然 ES 被视为搜索领域内的技术,但是 ES 也支持在线搜索、文档服务等场景;另外,有不少成熟的 OLAP 系统,也是基于倒排索引、行列混存等技术栈。由此可以看出, ES 往这两个领域发展的可行性非常强。因此,腾讯会重点朝“在线服务”和“OLAP 分析”等方向探索ES技术。
最后
欢迎大家关注我的公众号【程序员追风】,2019年多家公司java面试题整理了1000多道400多页pdf文档,文章都会在里面更新,整理的资料也会放在里面。
喜欢文章记得关注我点个赞哟,感谢支持!
近期评论