百亿级实时计算系统性能优化??Elasticsearch篇

发布于:2021-12-02 22:46:59


导语 | 随着业务的发展,系统日益复杂,功能愈发强大,用户数量级不断增多,设备cpu、io、带宽、成本逐渐增加,当发展到某个量级时,这些因素会导致系统变得臃肿不堪,服务质量难以保障,系统稳定性变差,耗费相当的人力成本和服务器资源。这就要求我们:要有勇气和自信重构服务,提供更先进更优秀的系统。文章作者:刘敏,腾讯基础架构研发工程师。


前言


自今年三月份以来天机阁用户数快速上涨,业务总体接入数达到1000+,数据进入量更是迎来了爆发式上涨,日均处理量上涨了一个数量级:Trace数据峰值处理量达到340亿/日条,Log日志数据峰值处理量级达到140亿/日条。
? ? ? ? ? ?


同比日均处理量级?


一、什么是天机阁


在传统单机系统的使用过程中,如果某个请求响应过慢或是出错,开发人员可以通过查看日志快速定位到具体服务。


而随着业务的越来越复杂,架构由单体逐渐演变为微服务架构。特别是随着容器, Serverless等技术的广泛应用,它将庞大的单体应用拆分成多个子系统和公共的组件单元。


这一理念带来了许多好处:复杂系统的拆分简化与隔离、公共模块的重用性提升与更合理的资源分配、大大提升了系统变更迭代的速度以及可扩展性。


但反之,业务架构也随之变的越来越复杂,一个看似简单的业务后台可能有几百甚至几千个服务在支撑,当接口出现问题时,开发人员很难及时从错综复杂的服务调用中找到问题的根源,从而错失了止损的*鹗被挪槲侍獾墓桃残枰姆汛罅康氖奔浜腿肆Τ杀尽


为了应对这一问题,业界诞生了许多优秀的面向Devops的诊断分析系统,包括Logging、Metric、Tracing。三者关系如图所示:



Tracing:一系列span组成的树状结构。每个span包含一次rpc请求的所有信息。从用户发出请求到收到回包,就是通过trace来串联整条链路。

Metric:指标数据。是对可观测性指标的一种度量,例如请求数、qps峰值、函数调用次数、成功率、异常率、接口返回码分布等信息,可用作统计聚合。

Logging:业务日志。? ?


? ? ??


三者互相重叠,又各自专注于自己的领域,将三者结合起来就可以快速定位问题。而已知的业界优秀开源组件有诸如:


Metric: Zabbix、Nagios、Prometheus、InfluxDB、OpenCenus;

Logging: ELK、Splunk、Loki、Loggly;

Treace: jeager、Zipkin、SkyWalking、OpenTracing。


? ??


随着时间的推移可能会集成更多的功能,但同时也不断地集成其他领域的特性到系统中来。而天机阁正是腾讯研发的集三位于一体的分布式链路追踪系统,提供了海量服务下的链路追踪、故障定位、架构梳理、容量评估等能力


? ? ?


最*第二代天机阁系统已经建设完成,新天机阁采用opentelemetry标准,可以支持更多场景的数据接入,同时在系统稳定性,数据实时性方面都有很大提升。



? ? ? ? ? ?


数据生产链路架构图


1. 数据接入层


主要负责数据采集工作,天机阁支持http+json、http+proto、grpc等多种数据上报方式,业务可以采用对应语言的SDK进行数据上报。根据业务上报环境,可选择Kafka、虫洞等多种数据接入方式,为减少数据传输耗时,提升系统的容错能力,天机阁提供了上海、广州、深圳等多个不同区域的接入通道,数据接入时会根据Idc机器所在区域自动进行“就*接入”。


2. 数据处理层


基于Flink构建的天机阁流式计算*台。主要处理三部分数据:第一部分是Metric模调数据的计算工作,结果同步至Druid。第二部分是日志数据,基于DataStream模式对数据进行实时消费,同步至ES日志集群。第三部分是Trace数据,基于KeyedStream的分组转换模式,根据业务Traceid进行Keyby,将一条Stream流划分为逻辑上不相交的分组,把相同Traceid的数据实时汇聚到同一个窗口,再对数据进行统计聚合,生成*送肌⒌饔昧础⒌饔檬鞯仁菽P停峁街罤base与ES。


3. 数据存储层



? ? ? ? ? ?


Hbase写入延时



ES写入延时



计算集群宕机


4. 系统异常


某些时间点出现系统异常,同时集群处理延时飙升。


? ? ?


本着先抗住再优化的思想,当出现上述问题时,为保证系统的可用性,我们会采取各种快速恢复策略,诸如计算资源扩容、数据降级、关闭数据可靠性等策略来提升集群的处理性能,达到快速恢复的目的。


但这些策略都治标不治本,性能问题周而复始的出现。这不但浪费了大量计算集群资源,集群处理性能,吞吐,稳定性都没有实质上的提升。



? ? ? ? ? ? ?


Trace系统架构图


? ? ??


如上图所示,一次RPC的请求和回包最终会合并成一个Span,而每个Span包含Traceid、Spanid,以及本次RPC调用涉及的主被调服务信息。


在接入层进行数据采样上报时,会将相同Traceid的Span集合路由到同一个数据通道中,而计算层会对不同通道的数据做隔离,不同通道采用不同的计算任务对数据进行处理。


大致流程如下:首先根据Traceid高位字节进行Reducekeby,确保同一个RPC请求的数据能路由到同一个窗口,再通过窗口函数对同一个请求的数据集合进行聚合计算,实时生成*送迹饔昧吹仁菽P停啃慈隕S和Hbase等列式存储。


在业务量少,集群相对稳定的情况下,Trace集群*均处理时长在20-40s左右,即从一次Trace数据的上报到可展示的过程大概要经过半分钟。


当系统不稳定或者处理性能下降时,数据延时会上涨至小时甚至天级别,而主要导致系统不稳定的因素有两种:


数据量的上涨给存储系统带来了较大的摄入压力,底层数据的刷盘时间越来越长;

系统经常要面临业务方错误埋点或热点Push产生的热key、脏数据等场景的考验。


具体表现为:


1. 底层存储数据摄入能力下降


Hbase写入耗时达到1300ms ?ES写入耗时达到2000ms。


? ? ? ? ? ? ? ? ? ? ? ?存储抖动,集群处理耗时上涨


2.?热key造成集群资源倾斜


导致集群产生毛刺、吞吐量下降等问题 。


? ? ? ? ? ?


热key写入量1000万/min


3. 脏数据、代码bug造成服务异常,导致集群毛刺增多



集群毛刺增多


4. 集群缺乏容错能力,过载保护能力 。


? ? ??


天机阁既是一个写密集型系统,也是一个时延敏感型系统,对数据的实时性有比较高的要求。系统的不稳定会导致消息通道大量数据堆积,数据实时性下降,最终影响用户体验,这是不能被容忍的。所以针对上述问题,我们需要对原系统进行全面的优化升级。



? ? ? ? ? ?



天机阁调用链


2. 存在的问题

??


随着进入量的上涨,ES集群内部写入峰值达到80w/s,日均文档总量达到280亿,索引占用总量达到 67T,每天新增索引量达到1000+,而每日文档新增存储总量达到10T。


机器配置采用为:64个4C 16g的数据节点,*均CPU使用率在45-50%之间;最大CPU使用率在80%左右;内存使用率60%左右,而磁盘*均使用率达到了53%,整体流程为。


? ? ? ? ? ?


天机阁是基于业务Appid维度按天索引的策略,而伴随业务量的极速上涨主要暴露出来的问题为:


(1)集群内部分片过多



ES分片过多


? ?


分片过多的缺点主要有以下三个方面:


ES每个索引的分片都是一个Lucene索引,它会占用消耗CPU、内存、文件句柄;

分片过多,可能导致一个节点聚集大量分片,产生资源竞争;

ES在计算相关度词频统计信息的时候也是基于分片维度的,如果分片过多,也会导致数据过少相关度计算过低。


(2)分片大小不均匀


部分索引的分片容量超过50G,侧面反应了这些索引分片策略的不合理,最终会导致索引的查询性能变慢。


? ? ? ? ? ? ?


?ES分片过大


(3)写入耗时过大,部分索引查询性能慢


ES写入耗时达到(1500ms-2000ms),此外分片过大也直接影响到索引的查询性能。




大索引查询超时(4800ms)


? ? ? ??


(4)索引创建过慢(1分钟),大量写入被拒绝


集群没有设置主节点,导致创建索引时,数据节点要充当临时主节点的角色,写入量较小的时候,影响不大,当写入压力过大时,会加剧数据节点的负载,影响索引的创建速度。


当出现密集型索引创建时,这个问题被无限放大,索引创建同时也会伴随大量的元数据移动,更加剧了节点负载,从而导致大量数据写入被拒绝现象。


而写入被拒绝最终会导致上游Flink集群剧烈抖动(写入失败抛出大量异常),以致于索引创建高峰期经常出现2-3小时的集群不可用状态。




?ES写入被拒绝



导致上游节点宕机


(5)系统出现大量异常日志


ES服务器异常,主要分为两类,一类是:数据解析异常,另一类是:Fields_limit异常。



? ? ? ? ? ?


查询耗时:大索引跨天级别查询在500ms左右。


? ? ? ? ? ? ? ? ? ? ? ?


分片数量:7万 => 3万,减少了50%,同时索引存储量优化了20%。


? ? ? ? ? ?


写入耗时:从2000ms => 900ms左右。


? ? ? ? ? ?



经过一期的优化ES写入性能有了明显提升,但还存在一些痛点,包括:


写入延时还是过大,没有达到预期效果。

分片数3万+ 还是过多,同时索引创建时间仍然过长(1分钟)。

索引容量管理以及生命周期管理困难。



? ? ? ? ? ?



ILM策略主要有四个阶段:


Hot阶段:可读,可写,索引会被频繁查询。

Warm:可读,不可写,此时可对数据进行归档,采用Shrink与Forcemerge,减少索引副本与主分片数,并强*蠸egment合并,能够减少数据内存与磁盘的使用。

Cold:不可写入,很久没被更新,查询慢。可对索引进行冻结操作,此时集群将对索引进行落盘操作,业务需要指定特定的参数才能查询到数据。

Delete:删除操作。将触发索引删除事件。



? ? ? ? ? ?




七、优化后整体架构图


? ? ? ? ? ?
Flink实时计算系统是天机阁链路追踪*台的重要组成部分,数据经过Flink窗口进行实时计算聚合最终sink到ES与Hbase等底层存储,而日益增长的数据量给计算集群带来了很大的挑战。


面对这些问题,我们重新梳理了整个链路架构,找到系统的瓶颈所在,并展开了一系列有效的优化措施。而在未来,我们会继续在大数据领域的探索研究工作,更进一步的打磨系统数据处理能力,提供更好的服务。


整体从计算层、存储层、架构、服务质量等几个维度对系统进行了优化,同时也加强了系统的容灾能力


自定义计数器实现热Key自动发现与降级。

存储过载保护,当QPS超过压测阈值时,触发降级逻辑。

通过druid 预聚合方式完善对业务的多维监控。


结语


性能是用户体验的基石,而性能优化的最终目标是优化用户体验,俗话说:“天下武功,唯快不破”,这句话放到性能优化上也是适用的。


我们优化ES, Habse存储摄入速度,优化Flink的处理速度以及接入层的数据采集能力,都是为了保证数据的“快”。而优化的过程则需要我们做好打持久战的准备,既不能过早优化,也不能过度优化。


最好的方式是深入理解业务,了解系统瓶颈所在,建立精细化的的监*教ǎ毕低吵鱿治侍馐保颐蔷涂梢宰龅接刑醪晃桑佑τ茫芄梗宋炔忝娼杏呕治觯瓒ㄒ恍┢谕男阅苤副辏⒍悦看斡呕胧┖托Ч鲎芙崴伎迹佣纬勺约旱姆椒邸


文章推荐



腾讯看点视频推荐索引构建方案

相关推荐

最新更新

猜你喜欢