es数据频繁的更新_百亿级实时计算系统性能优化–—Elasticsearch篇

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

前言

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

面对海量数据，老的实时计算系统处理压力逐渐增加，底层存储系统无论在磁盘、IO、CPU、还是索引上都面临巨大的压力，计算集群资源利用率不高，系统的调整优化迫在眉睫。

业务接入量

同比日均处理量级

一、什么是天机阁

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

而随着业务的越来越复杂，架构由单体逐渐演变为微服务架构。特别是随着容器, 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的数据实时汇聚到同一个窗口，再对数据进行统计聚合，生成拓扑图、调用链、调用树等数据模型，结果同步至Hbase与ES。

3. 数据存储层

ES主要用于用于建立热门Trace的倒排索引以及存储日志数据，Harbo/Druid系统用于存储模调数，Hbase用于存储调用链，拓扑图，关系链等数据。

三、问题回顾

在海量流量的冲击下，日志集群与Metric集群一直比较稳定，处理耗时基本在秒级。影响较大的是Trace集群，Trace集群主要通过滚动窗口接收一个Trace请求的所有RPC 的Span信息。

由于业务接入量的上涨以及不少业务的放量，Trace集群的日均处理量由3月份的40亿/day爆发式上涨到340亿/day，且集群还要经常面临业务热点push、错误埋点等场景的挑战。

这些问题直接导致数据实时性开始下降，期间经常收到用户反馈数据延时大，数据丢失的问题。而系统层面，则频繁出现集群抖动、延时飙升、Checkpoint失败等现象。同时存储也面临巨大的写入压力：Hbase与ES均出现写入延时上涨、毛刺的现象，而这些因素最终导致计算