基于Elasticsearch的指标可观测实践

本文涉及的产品
性能测试 PTS,5000VUM额度
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
可观测监控 Prometheus 版,每月50GB免费额度
简介: 主要介绍Elasticsearch为什么做时序引擎、Elasticsearch做时序引擎的挑战、Elasticsearch 时序引擎特性介绍、阿里云基于Elasticsearch TimeStream介绍。文章结尾更有关于《阿里云Elasticsearch在时序场景下的深入探索》的demo演示视频。


 

Elasticsearch为什么做时序引擎


首先看一下Elasticsearch为什么要做时序引擎


幻灯片4.jpg

 

故事要从阿里云和ES(后面文章Elasticsearch统一简称ES)社区的一次沟通会议说起,当时我们在沟通一些ES内核方面的问题,共同说到了ES做指标存储的痛点, ES社区当时已经开始设计时序引擎的文档,我们也在阿里云内部监控发现了很多ES做存储指标的问题。于是双方一拍即合,开始共同建设时序引擎这个项目。时序引擎相关的Issue( https://github.com/elastic/elasticsearch/issues/74660)记录了所有时序引擎相关的TODO list。


幻灯片5.jpg


说到ES做时序引擎,用户们通常会有下面两种对立的声音:


 一种是怎么能用ES做时序引擎呢?肯定要用专业的时序引擎,他们可能不知道ES为什么不能做时序引擎,只是觉得专业的事情要交给专业的人去做。

 另外一种是ES本来就可以做时序引擎,为什么还要开发呢?这些用户可能已经把ES用作了时序引擎的场景。

那么用ES做时序引擎到底会有什么问题呢?本文就为大家解开谜题。

 

幻灯片7.jpg


时序引擎有两大主流的场景:


 一类是用作监控,这也是可观察性的一个方向,所以这也是ES的核心战场。

 另一类是用作IOT场景,IOT场景有大量的设备会产生大量的指标,所以需要一个时序数据库来存储这些数据。

 幻灯片8.jpg


下面简单介绍一下时序引擎。时序引擎应对的是一种特点非常鲜明的场景。


首先,它存储的是采样数据,采样数据是基于稳定频率持续产生的一系列数据,相对应的是基于事件产生的数据,事件型数据是离散、随机产生的,而采样型数据是稳定的,持续产生的。

第二个特点是时序引擎的数据模型是非常固定的,一般都由时间、维度、指标三类字段组成。

第三个特点是时间线的概念,图中的纵坐标是时间线id,他是由维度组成的,一般是保持不变的。横坐标是指标数据,会随着时间不停的变化,这就组成了时间线的概念。

第四个特点,时序引擎存储的数据没有波峰波谷,7*24小时都在稳定的产生数据,跟他相对应的事件型数据一般根据业务的高峰低峰会有起伏。

第五个特点是时序引擎是垂直写,水平查,始终都在写最新的数据,查询会基于一个时间段去做一些聚合型的分析。

 幻灯片9.jpg


基于时序引擎鲜明的特点,时序引擎主要有下面几个需求:


在写入方面时序引擎需要支持高TPS写入,因为他面对的场景无论是监控还是IOT都有大量的设备在持续不断的产生数据;

 第二点是查询方面,时序引擎一般都是针对大量的数据去做多维度聚合,而不是单纯去查某一些点的数据;

 第三是成本方面,由于时序引擎写入量非常大,所以存储在时序引擎上的数据量是非常大的,一般来说数据重复度非常高,而且特点也很鲜明,所以针对性做一些压缩可以极大的降低这部分数据的存储成本。

 幻灯片10.jpg


针对上面的需求,时序引擎需要三大关键能力:


 首先是列式存储,跟他相对的是行式存储,由于时序引擎一般都是分析型需求,而且都是对单个指标的查询,所以如果用行式存储的话会有大量的无效IO,所以一般都得使用列式存储,而且列式存储对压缩也非常友好,这就是为什么很多早期时序引擎都是基于HBase构建的。

 第二个关键能力是类LSM数据结构,这类数据结构可以很好地支持高吞吐量的写入。

 第三个是聚合分析,对时序引擎的查询都是一些分析型的需求,所以需要时序引擎支持很好的分析能力,早期的HBase不支持分析,所以都是时序引擎在HBase之上做了支持分析的能力。

这三类能力ES都是具备的,所以说ES没有道理不去做时序引擎。

 

 

Elasticsearch做时序引擎的挑战

 

接下来介绍一下用ES做时序引擎的挑战。

 幻灯片12.jpg


目前用ES做时序引擎会面临三类痛点:使用门槛过高,查询慢且复杂,以及成本过大。


幻灯片13.jpg


由于ES的定位还是一个通用的搜索引擎,所以用户如果想把ES用作时序引擎的最佳实践,需要对ES有深入了解,做很多定制化的优化和在业务侧做很多开发才能使用,图中列出来的这些内容就是ES做时序引擎的最佳实践。


幻灯片14.jpg


第二个是查询方面的问题,下面用两个例子来看这个问题,这是一个查看指标up监控曲线的需求,PromQL只需要一个“up”关键字就可以完成这个需求,对ES来说他的DSL需要写quary aggs等复杂的语法才能够完成。


幻灯片15.jpg


第二个例子,按集群维度查看index_qps监控曲线,对 PromQL来说,先对指标做一次rate,再对cluster做一次sum by就可以完成这个需求,而对ES来说,需要写query和很复杂的aggs,甚至还用到了ES最复杂的pipeline aggs,功能虽然OK,但性能非常低下。


幻灯片16.jpg


再看成本过大的问题,InfluxDB官方给出了ES 做时序引擎的benchmark的对比,这里贴出来了一个存储容量对比的结果,可以看到存同样的数据存储ES 容量是InfluxDB的12倍。


幻灯片17.jpg 

我们也用阿里云监控存储ES的数据来进行了对比,可以看到更夸张的结果, ES是InfluxDB存储容量的74倍,即使ES做了在时序场景的最佳实践,容量减半,也还是InfluxDB的30多倍。

所以可以看到包括使用门槛,查询、容量的问题,这些虽然都不影响功能,但是相比其他的时序引擎,他的缺点就非常明显,这也回答了前面的问题,ES也能做时序引擎,但是效率非常的低下。

 


Elasticsearch 时序引擎特性介绍

 

接下来看ES 时序引擎项目,以及阿里云ES TimeStream怎么解决这些问题。先来看下社区的优化。


幻灯片19.jpg


关于Index Level的优化,这里列出了ES 做时序引擎的几个优化的关键点:


 Setting中增加了一个index.mode=time_series的设置,这个设置告诉ES在内部去实现时序场景的最佳实践。这个配置要结合一些其他配置一起生效。

 Mapping 字段配置增加了2个关键字:time_series_dimensiontime_series_metric,这两个设置是为了告诉ES哪些字段用作维度字段,哪些字段用作指标字段,有这两个配置再结合index.mode=time_series,ES会把所有的维度字段生成一个_tsid(时间线ID)内部字段,用_tsidtimestamp去做 index sorting。

 最下面可以看到一个@timestamp的字段,如果设置了index.mode=time_series时,这个字段是无需设置的,索引会自动生成一个@timestamp的时间字段。

 中间Mapping里面还有一个 {"_source":{"syntheic":true}}”的设置,这个设置可以告诉ES可以无需存原始数据_source。需要看明细数据时,ES内部使用列式存储的docvalues数据生成原始的_source,这样就可以极大地节省了ES的存储空间。


幻灯片20.jpg


ES的另一个优化,是使用TSDS作为时序场景的使用方式,TSDS全称是Time Series DataStream。DataStream是对index做的一层封装,主要解决的是ES索引无限膨胀,以及无法过期历史数据等问题。TSDS相比普通的DataStream主要区别是时间分区的优化,普通的DataStream索引在写入数据的时候,无论是新数据还是老数据,写入的时候始终都是写入最新的是索引。这样在时序引擎场景中就会带来一个问题,当要对数据按时间分桶的时候,桶内的数据可能会出现在所有的索引中。这里ES对时间分区做了优化,效果是写入的数据按照时间字段进行索引分区。实现方法如下:


 索引Settings增加了index.time_series.start_time, index.time_series.end_time两个配置。start_time用来标识索引的起始时间,end_time标识结束时间,索引只允许在时间范围内的数据写入,其中start_time是final类型不能修改,end_time可以动态修改,但是只能修改为比当前值大的value。

 DataStream发现索引模板中配置的是time_series索引,则会自动生成索引的start_time和end_time。DataStream做rollover的时候,上一个索引的end_time,设置为下一个索引的start_time,这样索引不断增加时,索引之间在时间上是无缝衔接的。

TSDS有了时间分区,在做时间范围查询时,只要查询对应时间范围的索引即可,而且TSDS的时间分区,相比普通按天、月、年等固定分区,它是一个弹性分区,可以更好的控制索引元数据数量。

 


▌阿里云Elasticsearch TimeStream介绍

 

下面介绍一下阿里云ES TimeStream如何解决ES做时序引擎的问题。


幻灯片22.jpg


阿里云ES TimeStream,是阿里云基于ES自研的时序引擎,其核心目标主要有下面三个:


 进一步降低了ES用做时序引擎的使用门槛

 TimeStream结合阿里云ES内核来进一步的降本增效

 TimeStream能够和更多的系统直接集成。


幻灯片23.jpg


TimeStream内部定义了时序模型,包括:labels,metricstimestamp三种类型的字段,在创建TimeStream索引的时候直接使用命令“PUT _time_stream/{name}“即可,如果想做更复杂的配置可以使用ES template的语法。如果想自定义时序模型,那么在创建TimeStream索引时也可以自定义labelsmetrics

TimeStream索引读写数据的方式跟正常索引一样,直接使用ES原生API即可。

 幻灯片24.jpg


再来看一下TimeStream如何降本增效。前文提到ES存储空间是InfluxDB的74倍,我们进一步分析ES数据存储的占比是怎么样的,发现了两大可以优化的点:


 首先是在ES做时序场景的数据压缩方面有所欠缺,所以TimeStream在数据压缩上可以极大地降低占用空间。

 另一点我们发现ES存储时序数据时,存储空间主要来自于元数据字段,如_id, _source等,把这些字段去掉,再通过一些自动生成的方式满足查询需求。

通过数据压缩和减少元数据存储可以极大的降低存储空间。

 幻灯片25.jpg


来看一下做了这两部分优化的效果,存储空间在使用了压缩之后直接从1900MB降到了1100MB多兆,这降低的800MB的空间,基本上都是元数据的开销了。我们再将_id和_source去掉之后,又进一步降低到了200MB,可以看到ES经过优化以后存储空间已经和InfluxDB接近了,在某些场景上会表现的比InfluxDB更好。

 幻灯片26.jpg


降本增效另一大关键特性是支持DownSample(降采样),DownSample功能通过降低数据的精度,达到降低存储容量,提升查询性能的目的。TimeStream内部直接集成了DownSample功能,在创建索引的时候直接指定DownSample精度,图上示例中给出的精度包括1分钟,10分钟,60分钟,用户在写入原始数据的时候,TimeStream内部还会生成相应的三种精度索引。

用户在查询原始数据的时候,TimeStream内部会根据interval(DSL中date_histogram的interval参数)决定到底该使用什么索引,这时候用户查到的并不是原始索引,而是interval能满足的最粗精度的索引。由于数据量比原始精度小了很多,查询速度也快了很多。

DownSample能降低存储空间,原因是使用DownSample后,原始索引就不需要保存那么长时间了,这样整体存储空间就能得到极大的下降。幻灯片27.jpg


下面我们来看一下DownSample的查询效果,图中有4个查询Case,可以看到,如果查询到了DownSample的索引,性能相比原始索引有了质的提升。图中也对比了CK和InfluxDB的查询性能,可以看到ES的查询性能是比InfluxDB好的,跟CK相比,部分查询性能优于CK。


幻灯片28.jpg


TimeStream的第三大特性是集成方面,目前TimeStream支持了跟PrometheusGrafana的集成,TimeStream支持了Prometheusremote write接口,这样可以直接将Prometheus数据同步到ES,作为Prometheus的一个分布式、高可用的远端存储来使用。然后在Grafana直接使用Prometheus的数据源来访问ES。


幻灯片29.jpg


下面看一些示例,用户在选择DataSource的时候,需要选择的是PrometheusDataSource,地址填写的是ES对应的集群地址。这样可以直接像访问Prometheus一样访问ES。

如果用户用了一些开源的Exporter导入数据,在Grafana直接导入开源Exporter对应的Dashboard即可访问这些数据,与访问原生Prometheus的体验是一模一样的。下面的截图也可以看到ES TimeStream可以支持非常复杂的PromQL,目前时序场景绝大部分的PromQL,常用的function,aggregation都支持。

以上就是阿里云ES TimeStream的介绍,目前ES TimeStream已经在官网上线,更多详细的功能大家可以在阿里云ES官方文档(https://help.aliyun.com/document_detail/436120.html)中看到。


幻灯片30.jpg


最后总结一下用ES做时序引擎。ES 时序引擎项目补齐了ES存储和查询时序数据的短板,让ES可以作为专业的时序引擎使用。

ES还不止于时序引擎,其优势主要在以下三个方面:


 系统方面:它是分布式、高可用、高可靠、弹性、分层存储、数据备份等功能非常健全的系统;

 产品方面:整个Elastic Stack技术栈是一个非常完善、丰富的产品;

 领域方面:支持搜索、可观察性和安全三大领域。


阿里云Elasticsearch在时序场景下的深入探索 视频详点>>



联系我们(钉群二维码)

更多可观测场景架构及使用最佳实践交流,欢迎扫描二维码加入钉群>>

image.png

阿里云Elasticsearch 1元包月试用链接>>





相关实践学习
使用阿里云Elasticsearch体验信息检索加速
通过创建登录阿里云Elasticsearch集群,使用DataWorks将MySQL数据同步至Elasticsearch,体验多条件检索效果,简单展示数据同步和信息检索加速的过程和操作。
ElasticSearch 入门精讲
ElasticSearch是一个开源的、基于Lucene的、分布式、高扩展、高实时的搜索与数据分析引擎。根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr(也是基于Lucene)。 ElasticSearch的实现原理主要分为以下几个步骤: 用户将数据提交到Elastic Search 数据库中 通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据 当用户搜索数据时候,再根据权重将结果排名、打分 将返回结果呈现给用户 Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索,具有接近实时的搜索,并支持多租户。
相关文章
|
4月前
|
运维 监控 Java
探索Elasticsearch在Java环境下的全文检索应用实践
【6月更文挑战第30天】在大数据背景下,Elasticsearch作为分布式搜索分析引擎,因其扩展性和易用性备受青睐。本文指导在Java环境中集成Elasticsearch,涉及安装配置、使用RestHighLevelClient连接、索引与文档操作,如创建索引、插入文档及全文检索查询。此外,还讨论了高级查询、性能优化和故障排查,帮助开发者高效处理非结构化数据全文检索。
127 0
电子书阅读分享《Elasticsearch全观测技术解析与应用(构建日志、指标、APM统一观测平台)》
电子书阅读分享《Elasticsearch全观测技术解析与应用(构建日志、指标、APM统一观测平台)》
|
5月前
Elasticsearch采坑实践总结
Elasticsearch采坑实践总结
126 0
|
29天前
|
存储 关系型数据库 MySQL
浅谈Elasticsearch的入门与实践
本文主要围绕ES核心特性:分布式存储特性和分析检索能力,介绍了概念、原理与实践案例,希望让读者快速理解ES的核心特性与应用场景。
|
2月前
|
人工智能 自然语言处理 搜索推荐
阿里云Elasticsearch AI搜索实践
本文介绍了阿里云 Elasticsearch 在AI 搜索方面的技术实践与探索。
18852 21
|
2月前
|
运维 监控 数据可视化
Elasticsearch全观测技术解析问题之面对客户不同的场景化如何解决
Elasticsearch全观测技术解析问题之面对客户不同的场景化如何解决
|
4月前
|
存储 监控 固态存储
elasticsearch索引生命周期管理(ILM):原理和实践
elasticsearch索引生命周期管理(ILM):原理和实践
|
4月前
|
存储 JSON API
Elasticsearch中的模板:定义、作用与实践
Elasticsearch中的模板:定义、作用与实践
|
4月前
|
存储 缓存 自然语言处理
elasticsearch 聚合 : 指标聚合、桶聚合、管道聚合解析使用总结
elasticsearch 聚合 : 指标聚合、桶聚合、管道聚合解析使用总结
|
4月前
|
搜索推荐 Java 数据库
Java中的ElasticSearch集成与实践
Java中的ElasticSearch集成与实践
下一篇
无影云桌面