• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

Prometheus 与 国产 TDengine 的对比

开发技术 开发技术 2周前 (09-05) 23次浏览

通过对比,能加深对这两个系统的理解,方便后续架构选型时作出正确决定。他们的设计思路有很多值得借鉴的地方,虽然工作中需要用到这些知识的地方不多,但是了解他们的设计细节能极大满足我的好奇心。

1.场景和需求

Prometheus

需求

  1. 用于云原生场景下集群监控数据的收集、即席分析(Ad Hoc)和报警
  2. 处于 Kubernetes 生态,需要能很方便与之集成,被收集对象(target)的种类和数量会动态变化
  3. 可扩展:能应对集群规模逐步变大的场景:从成百到上千台机器,上万容器的规模
  4. 追求单机模式下极高的写入吞吐和查询速度,比如支持每秒百万采样数据的写入。

场景特点

  1. 因为生态中已经有服务发现组件,而且是内网环境,所以它会定期、批量拉取数据,需支持高并发写入。
  2. 需要存储的指标序列(metric series)数量级会很大。比如一个 Kuberntes 集群中500台机器,每台机器上有几十上百个目标,每个目标里20个指标。这样会有 500*100*20 = 1,000,000,一百万个序列。
  3. 数据写入和读取的形式完全不同:数据写入按照指标维度,而读取是按照时间区间。最终查询时涉及的区域以时间为横轴,指标不同维度为纵轴的矩形。
  4. 序列翻腾(Series Churn)问题:随着时间推移,一些指标序列会进入非活跃状态,即再也不会接收到新的数据,而新的序列会出现。这在云环境,尤其是 Kuberntes 这种环境下非常常见:主机粒度、服务实例粒度、容器粒度都会弹性伸缩。

TDengine

需求

  1. 想要一站式解决目前国内物联网大数据平台的问题:使用互联网的Kafka、HBase、Cassandra、MongoDB、Redis等太重了,研发、运维效率低,定位问题链条太长
  2. 希望轻松搞定私有化部署
  3. 能适用于物联网中嵌入式设备和系统

场景特点

  1. 写入的都是结构化数据,数据 Schema 是事先能确定的
  2. 写多读少,写入数据都带时间戳
  3. 写数据流量平稳且可预期。根据设备数量和采集频次,可以预测。比如有100个设备,每30s采集一次数据,那写入最高约3000次每秒。不会像互联网的To C 流量,会受营销的影响。
  4. 嵌入式设备,存储、算力资源受限,而且设备有利旧的情况

2. 需求共同点

他们的需求和场景有一些共同点:

  1. 写入数据都带时间戳,一次写入,多次读取,写入的数据不会有更新的需求。
  2. 查询都是基于连续的时间区间,聚合都是基于更小的时间窗口。比如查询某指标在最近30分钟里,5分钟为窗口的平均值
  3. 需要提供即席查询(Ad Hoc)能力,即支持用户自定义查询条件。不需要支持跨不同类型的表进行聚合查询的情况。

3. 差异

面向的场景不同

  1. Prometheus 专注于运维(operation)需要的指标数据,特点是存储的就是一个数值,数据附带了很多维度信息,作为标签(lable)。比如 cpu_total_seconds : {timestamp=2020-09-05-21-27, host="192.168.1.10", type="idle"}=3551341;而 TDengine 类似传统数据库,用于存储工业中某类传感器设备采集的指标,所以数据类型多样,如浮点,字符串等。
  2. TDengine 面向工业物联网时序场景,写入数据的设备数量比较稳定,可预测。而 Prometheus 要拉取的目标是动态变化的。
  3. TDengine 的场景之一是嵌入式,所以追求无依赖,安装包小,内存占用小。
  4. TDengine 面向工业物联网,这个领域不像互联网那样人才充沛,IT化程度低,所以 TDengine 想减少维护成本,做全栈,有一部分缓存(无需Redis)、消息队列(无需Kafka)、实时计算能力
  5. Prometheus专注于单机性能,用于存储最近一段时间数据,没有长期持久化的考虑,弱化分布式集群功能,由其他组件(如Thanos)来完成高可用。
  6. TDengine 希望通过分布式集群来提供可扩展性、高可靠和高性能,避免单点故障,收费版就是提供集群能力,有持久化多级存储在不同设备上的能力。

使用方式不同

  1. Prometheus 不需要提前建表,而 TDengine 是关系型数据库模型,需要提前定义好表结构。Promtheus 里写入的数据需要自带描述,包含很多不同维度的标签(lable),这些都是动态的。
  2. 查询语句:TDengine 使用 SQL 语句。而 Prometheus 有自己的一套 DSL:PromQL
  3. TDengine 一个采集点一张表,所以一张表不会并发写入。而 Promtheus 为了避免存储的采样数据产生很多小文件,是以块为单位存储指标的
  4. Prometheus 里 lable 会有字符串,所以查询语句支持文本检索:与、非条件组合

架构、实现方案不同之处

  1. TDengine中集群功能非常复杂,它需要考虑很多分布式系统里常见的问题:集群成员管理(membership management)、成员通信、数据分片(sharding)、数据分区(partition)、成员选主(leader election)、数据同步(replication)、负载均衡(load balance),防止数据过热或倾斜,
  2. 上文提到 Prometheus 没有聚焦在解决分布式高可用。它的核心组件是自研的时序数据库 TSDB。通过学习Facebook的开源时序数据库 Gorilla 中的采样数据压缩算法,号称能把一个16字节的采样数据压缩到约1.4字节。
  3. TDengine 使用 C 来实现,为了避免对其他库有依赖和较量高效,自己实现了定时器,RPC,内存管理等机制。

相同点

共同的设计目标

都在追求高性能、低资源占用率,都希望充分利用数据的使用特点:最近写入数据优先。

类似的架构、实现方案

  1. 写入时,数据都是先写入内存,之后批量刷到磁盘,尽量减少磁盘的写频率。为了防止在此期间的宕机,都使用了提前写(Write-ahead-log)日志
  2. 为了尽量减少数据的内存和磁盘占用,都会根据数据特点进行压缩。
  3. 数据都按照时间维度进行分块(chunks),块与块之间独立。这样查询时可以多个块并发查询,然后进行合并。而且后续数据回滚(retention),可以以块为粒度进行,简单高效。
  4. 如果查看他们的架构图,会发现都需要有存储引擎、计算引擎。

本文中还有很多方面没有涉及,比如 TDengine 集群模式及存储引擎方面的细节。由于 TDengine 存储引擎无文档,目前还不知道是如何设计的,改日读读源码,后续逐步写文章阐明。

通过学习这些系统,会发现技术领域也有经典招式,存在了很多年,威力巨大。比如 WAL,Master slave 同步机制, Raft协议、Quorum 机制,SSTable 等。

参考资料

  1. 我为何要开发一个专用的物联网大数据平台,还开源它?
  2. PromCon 2017: Storing 16 Bytes at Scale
  3. Writing a Time Series Database from Scratch

欢迎关注我的微信公众账号,会在第一时间更新,博客园上只有部分文章会发布

Prometheus 与 国产 TDengine 的对比


喜欢 (0)