可观测领域系列之存储分析鉴赏Talk(Part 1)
前面有文章也提到过,可观测领域目前尚存的一些短板,其中存储分析就是其一,只能根据过往的一些经验,
以及调研分析来尝试帮大家鉴赏下当前这个领域的一些技术和竞品分析。
在分析这个问题之前,我们先从场景出发,以及行业对于可观测数据存储分析要求,以及当前的局面分析。
1,日志查询分析场景,没错,如果单论日志查询,特别是全文检索能力,elasticsearch是此领域的第一,
特别是功能的丰富度以及可定制化,以及性能等综合能力。
2,链路点查场景,这个场景下,最频繁的场景就是根据traceId查询一段时间内产生的链路数据,
其实相对来说,和日志查询场景类似。
3,多维时序指标分析计算场景,这里行业比较有共识的问题,就是高基数下数据查询对系统的稳定性和性能压力。
4,在时序指标数据查询分析场景之上再泛化下,就是针对常规的结构化数据进行更加通用的关联统计查询,
而不是仅仅针对时序数据的单表单库查询。
以上是基于数据类型和场景,做了一个简单分析,除此之外,可观测领域的数据以及要求,还具备以下几个特征:
1,数据量大,尽管当前大数据的概念早已深入人心,并体现在了一众企业强调的数字化转型的潮流中,
但可观测领域才是大数据的修罗场,数据量少则百亿级,
是真正的TB/PB级数据,这远远不是业务领域的数据所能比拟的。
2,时序属性,按照常规的时间戳,指标键,指标值,标签组。
3,非结构化,可观测领域的数据还有一个显著特征,就是非结构化,或者半结构化,其中日志数据,尤为明显,
这就引出了一个需求,数据的清洗(ETL),否则这种非结构化数据很难被使用,这个在大数据领域,
已经有一套非常成熟的操作流程和体系了(SOP)。
4,实时性,如果说大数据领域是T+1的实时性要求,已经司空见惯 ,那可观测领域对于数据的实时性,则可能是近实时的,
毕竟监控告警才是可观测的内核,除此之外就是各种看板,仪表盘,对数据存储分析引擎要求具备高并发的在线查询的能力。
5,事务性要求低,可观测类数据,是典型的查多,改少,甚至不用修改,价值密度相对小,对于联机事务要求低。
基于上面的分析,我们不难得出可观测领域的存储分析引擎的画像如下:
1,分布式,高可用,海量数据存储,基本不可能单机,而是一个分布式协作的高可用系统
(高可用和事务性不是一个概念,请注意区分理解)。
2,支持多并发的在线实时查询能力,以及快速响应的数据查询分析能力。
3,高并发的数据写入吞吐能力,比如百万每分钟的数据写入能力。
4,存储压缩率高,因为数据量大,价值密度低,考虑到存储成本问题,具备高存储压缩率,对于企业使用成本也是一个重要的考量因素。
5,丰富的数据处理能力,特别是数据查询和分析的函数支持丰富度,这里主要考虑到可观测领域各种看板,
报表分析能力,而且又是非结构化数据。
6,易运维,其实这是一个衍生的需求,毕竟这从某种程度上,也属于大数据系统,而数据系统,特别是以hadoop为主流的数据系统,
运维管理的难度不小,易运维,或者说稳定性,对于可观测的存储分析系统也是一个要求。
7,生态兼容,这个也是从行业和用户提出的衍生需求,这里不得不提到SQL/DSL之争了,尽管SQL从某种意义上,也是一种DSL,
但架不住SQL的历史和使用群体,至于DSL的代表,比如promql,spl,谁叫prometheus是当前云原生领域监控的事实标准呢,
另造轮子,不是不可以,但既有用户是否买单呢?
上面花了不少笔墨分析了可观测领域存储分析的使用场景,要求,以及行业画像,那么业界是否有可以满足的竞品呢?
根据笔者的一些行业经验,列出一些行业开源或者非开源的头部产品来做一些分析:
提供一个表格多维度对比分析 :
产品 | elasticsearch | clickhouse | prometheus |
分布式 | 支持,elasticsearch的分布式能力支持相对全面成熟,支持副本,分片,冷热备份,整体能力出众。 | 支持,无中心的分布式架构,支持副本,分片 | 支持,但底层分布式存储能力,方案众多,不稳定,这恰恰证明没有一个能抗事的。 |
通用性 | 高,特别是全文检索能力优越 | 高,可用于日志,链路,事件,指标等不同数据模型 | 低,支持数据结构单一,在时序指标数据能力优越 |
读写性能 | 高,json类查询语法,使用相对复杂 | 高,高并发读有瓶颈 | 高 |
压缩率 | 低 | 超高,相较elasticsearch有5倍以上的优势,甚至更高。 | 高 |
聚合分析能力和函数丰富度 | 一般 | 高,丰富的表引擎,以及函数,以及聚合分析能力是其立身之本 | promql,相较sql有难度,可配合grafana可视化使用 |
可运维性 | 高,从接触信息以及自身的使用经验来看,elasticsearch的运维成本相对较高 | 一般,尽管分布式能力有些半手动,但相对稳定,整体运维难度可控。 | 一般,分布式存储以及稳定性依旧是短板 |
生态 | 丰富,和kibana结合,形成了以ELK为主的全套技术栈 | 一般,但提供的SQL读写能力,非常方便第三方系统以及用户快速集成和使用 | 丰富,和grafana/kubernetes深度结合,提供了方便用户使用的全套技术方案 |
同类产品分析 | 翻翻cncf全景,可以看到一些竞品,quickwit.io,parseable.io等用rust编写的日志类数据存储分析类开源产品,这些开源产品,相较于elasticsearch的优势也比较明显,毕竟elasticsearch不仅仅为日志观测所设计,有很多冗余设计,而新型的开源产品轻装上阵,更加专注 | doris : 一个国内发起的olap数据仓库,其发行商也出品了一些用doris来做日志中心的生产实践,从基本能力上来看,和clickhouse很接近,但个人并没有生产环境的实践经验,但从对外的资料来看,可以作为替代品 | victoriametrics,一个借鉴prometheus的超集,从集群,到性能相较prometheus有不少优势,可生产使用 greptimedb,一个国内技术爱好者发起的基于rust编写的分布式时序数据库,从官方写的一系列技术文章来看,值得尝试。 |