写点什么

国产时序数据库 TDengines 学习调研及总结

作者:李草凯
  • 2022-12-22
    广东
  • 本文字数:4569 字

    阅读完需:约 15 分钟

国产时序数据库TDengines学习调研及总结

引读

因为工作的关系,最近几年我会触到各种国产数据库,唯独对 TDengine 念念不忘。众多数据库中 TiDB 一枝独秀,OceanBase 出身名门世家,openGauss 有华为撑腰,只有 TDengine 给人感觉有一种草莽出英雄的感觉,TiDB 借用了 rocksDB 的性能,openGauss 是基于 postgreSQL9.2.4 开发,即使 OceanBase 也是基于内部应用需求开始打造的。只有 TDengine 不依赖任何开源或第三方软件,而且它不是一款通用型的数据库,剑走偏锋,它有自己独特的社会应用场景,主要为工业网服务。


笔者把对 TDengine 的定义和理解,TDengine 能做什么?它与其它数据库的区别?同类的产品有哪些?TDengine 解决了什么问题? 它的优势与亮点在哪里?下面细细道来,希望对 TDengine 有兴趣的小伙伴有所领悟。

TDengine 与其它数据库的区别

数据库完成出色的的读写,最核心的能力的是索引,一般数据库产品都具备正向索引能力。所谓正向索引就是通过文档记录里面的标识符为关键字,通过关键标识符不需要进行全盘扫描。B 树索引、哈希索引、位图索引有区别,但是大方向都属于正向索引。


除了正向索引,还有反向索引【也称倒排索引】,反向索引主要是用于全文检索的,例如 ElasticSearch,大多数据库都是正向索引。TDengines 也是使用正向索引,它的特别之处标识符肯定包含时间戳,再加上一个维度指标数据,构对一个对数据值明确的描述,某个时间某个指标对象的数据值是多少多少。


从数据组织的存储引擎来看,数据库底层可以分为 B 树机制、LSM 机制,两种机制没有谁最好,各有各的优点和缺点。


B 树最大好处,在于它对数据持续高涨读性能的处理,即使数据量级增大,它的读也没有放大。 奥秘在于对数据进行终极持久存储的时候,B 树是以有序有规律的数据结构保存在硬盘上的。这样随着数据越来越大,它依然保持有序有规律的特性,面以成千上万的读操作,都可以遵循条件运行,减少或避免读放大的行为。


与 B 树机制截然相反,LSM 机制则是减少避免了写放大。


LSM 机制充分利用了内存,在内存里面开辟了一个空间,写数据优先往内存里面放,写进去直接返回用户成功,而不是像 B 树那样写一个, 我要找出谁比我大谁比我小,只要内存有够,我就直接往内存里面填就好。 当内存达到一定的阈值,将内存中的数据以批量、顺序的方式一次写入硬盘上,内存则重置清零再服务新的写要求


传统数据库 MySQL、Oracle 使用的是 B 树机制,而 TiDB、OceanBae 使用的是优化后的 LSM 机制,而 TDengine 使用的是 B 树 + LSM 机制的方式,B 树存储的是元数据【主要是时间戳+指标数据】,LSM 机制存储的是具体的数据,元数据以有序表结构方式进行存储,而具体数据则是追加的方式 写入,这样即避免了读话大和写放大。


业界为 OLTP 产品为了提升并发控制的性能,必定会有写时复制或者 MVCC 的功能选项,写时复制与 MVCC 虽然保障了数据的一致性,但是带来更多的 IO 负担。TDengine 不需要对数据进行修改,所以不需要考虑数据一致性的问题,数据是以有序的规律并追加的形式写进去的,因为只有读和写,所以也不需要锁保护,抛掉一些无用的包袱,可以集中优化其它地方,例如列式表。


业界通用数据库针对各种业务都会有行式表、列式表甚至完全的内存库,对于具体的数据存储 TDengine 使用完全列式存储在硬盘,而维度指标则行式保存在内存中。因为 TDengine 面对的是机器的数据,机器 24 小时工作精确到每个毫秒都在产生数据,为了存储更多的数据,所以 TDengine 用上行列并存、用途分离的方式。


数据库里面的每一行的文档记录都是非常重要的,即使这行记录信息无关交易,只是一个用户基本信息,它的价值密度也十分高。时间序列数据库不同,单行文档记录价值密度低。因为 1 秒可以产生 1 万条记录,必须要把数据聚合汇总起来才能体现数据的价值。快速并有效聚合普通数据使之变成价值密度高的数据,这个也是时间序列数据库区别于其它数据库的一个重要的特征。


TDengine 目前提供了三个版本的产品:社区版,企业版以及云版本, 满足市场的需求和个人开发者的需求。

TDengine 的竞争对手

**技术上区分定位,TDengine 是专注时间序列领域的一个分布式的海量数据分析平台。**TDengine 的竞争对手可以分为直接竞争对手和间接竞争对手,间接竞争对手有 TiDB、OceanBase、GaussDB 以及国外 Oracle、MySQL 等等,虽然它们在综合技术维度上与 TDengine 没有对标,但是分析上只要是使用时间戳,与时间序列有关系,这里就有 TDengine 的用武之地。


与 TDengine 构成直接竞争对手有 Druid、opentsDB、influxDB,他们都是时间序列分析的前辈。


**Druid 是一个分布式系统,采用 Lambda 架构,充分利用内存,也会把历史数据保存到硬盘上,按一定的时间粒度对数据进行聚合。**实时处理和批处理数据解耦分开。实时处理是面向写多读少的场景,主要是以流方式处理增量数据,批处理是面向读多写少的场景,主要是以批处理方式处理离线数据。


Druid 依赖 hadoop,集群中采用 share nothing 的架构,各个节点都有自己的计算和存储能力,整个系统通过 Zookeeper 进行协调。为了提高计算性能,会采用近似计算方法包括 HyperLoglog、DataSketches 的一些基数计算。


OpenTsDB 是 一个开源的时序数据库,支持存储 数千亿的数据点,并提供精确的查询,采用 JAVA 语言编写,通过基于 Hbase 的存储实现横向扩展,OpenTsDB 广泛用于服务器的监控和度量,包括网络和服务器、传感器、IOT、金融数据的实时监控领域。OpenTsDB 的设计思路上是利用 Hbase 的 key 去存储一些 Tag 信息,将同一个小时数据放在一行存储 ,提高 了查询速度。


OpenTsDB 通过预先定义好维度 Tag 等,采用精巧的数据组织形式放在 hbase 里面,通过 HBase 的 keyRange 可以进行快速查询,但是在任意维度的组织 查询下,OpenTsDB 的效率会降低。


influxDB 是非常流行的时序数据库,采用 go 语言开发,社区非常活跃,技术特点支持任意数量的列,去模式化,使用方便、强大的查询语言,集成 了数据采集、存储和可视化存储。支持高效存储,使用高压缩比的算法等,采用 TIME SERIES MERGE TREE 的内部存储引擎,支持与 SQL 类似的语言。


时间序列的业务背景,在 OLAP 场景中一般会进行预聚合来减少数据量,影响预聚合主要因素如下,


  • 维度指标的个数

  • 维度指标的基数

  • 维度指标组合程度

  • 时间维度指标的粗粒度和细粒度


为了高效的预聚合,TDengine 的秘诀是超级表,Druid 会提前定义预计算,influxDB 也有自己的连续查询方法,只有 hbase 使用时才进行拼接,所以涉及不同的维度指标查询,hbase 会慢一些。


TDengine 的应用案例

我对 TDengines 的认识了解结合笔者的过去项目经验,以 2018 年为背景,讲述一个工业界坏件故障件预测的故事。


某知名集团,随着公司业务的快速增长、新工厂的不断增加,各种有价值的数据,没有很好的整合、分析与挖掘出它应有的价值。公司已经进入的‘拼’的战略,快速响应与准确预测是大数据所能做的事情,通过整合各系统数据以科学的分析手法,帮助驱动公司业务的发展,使得工厂的制造更能智能化。


当前工厂生产过程中有同一种特殊问题的 glass id,glass 的品质由于各种原因是参差不齐的,甚至会有品质异常的 glass。这些异常 glass 在检测过程中,是无法检测出异常原因的。如果无法快速定位出异常原因,会造成更多的异常 glass,严重影响生产。


  1. 通过品质异常的 GLASS,找到产生此异常的相关性因子。如:机台、物料、载具、参数等。

  2. 异常 GLASS 侦测预警,通过对产生品质异常的因子进行数学建模,预测出偏离正常范围的异常玻璃,提前预警。

  3. 分析 GLASS 的特征值与特征值之间的关联关系,并建立预测模型,提前预测出 GLASS 的特征值。

  4. 分析 GLASS 相关的电压、电阻、电流、温度、湿度影响。


很明显这是数据挖掘的项目,以上 glass 在生产过程中的环境信息,检测机台资料,量测机台资料,制程参数信息,以及 FDC,OEE 系统的数据找出产生这种问题的原因。第一步是数据收集整合,第二步数据探索,第三步是模型调校,找出可能性、影响最大的因素的特征因素,第四步是投入生产验证,,通过 spark ml 提供预测动力。


当时的技术栈用的是 CDH,首先通过 kafka 采集的数据, spark 对接 kafka 进行初步计算去噪并汇总到 hadoop 里面,以 parquet 的格式保存,有需要进一步的加工,通过 impala 进行一步的加工,每天挂起 N 个任务,不停的调度计算。



当时坏件故障件预测项目有以下痛点,主要是及时性、有效性、准确性的问题,无法做到实时数据分析,但是 CDH hadoop 还能做些事,继续用着。


  • 难以满足用户需求,某些机器数据的聚合计算需要第二天才能出结果,甚至更多的时间才能出来。

  • 经济成本的费用较高,CPU、磁盘、网络都在一个高段的使用状态,针对越来越多的数据需要投入新机器。

  • 维护成本高,你需要维护 hadoop 所有的机器,各种 hbase、spark、zookeeper、hdfs 之类,不但对工程师要求高,而且工作量大。

  • 低质量数据,因为数据流程或者错误的逻辑整合,导致机器传感器聚合后导致数据模型无法正常使用。

  • 无法做到实时监测,机器数据作为宝贵的自变量因素无法及时传输并进行计算,自然会影响因变量。


笔者经历了这个项目,知道这个坏件故障预测与时间序列有紧密的关系。**时至今日,时间序列分析也是重要的数据分析技术。尤其面对季节性、周期性变化数据时,传统的回归拟合技术难以奏效,这时候就需要复杂的时间序列模型,以时间为特征作为抓手点。**这样你不太懂业务的前提下,也可以进行数据挖掘的工作。


这个项目与 Tdengine 有什么关系? 这个项目没有用上 TDengine,后来集团搭建了一个 hadop 集群试点,这次居然用了 HDP,理由很简单,因为 HDP 默认搭载了时间序列数据库 Druid。


当时技术负责人认为坏件故障预测模型的 数据库基座应该是 时间序列数据库,而不是 hadoop 不停的数据采集、数据转换以及各种批计算,通过时间序列数据库可以不但可以实时计算,而且输出的数据质量高。选择哪个时间序列数据库?考虑平稳过渡替换以及学习成本综合因素他们选择了 Druid。


当时 2017 年,TDengine 还没有面世,如果放到今天 TDengine 必定是考虑首选。


TDengine 的优势相对 Druid 多了去,首先 Druid 不是一个经过开源版本 1.00 正式发布的软件,虽然发展多年,直至 HDP 与 CDH 两家公司融合,HDP 搭配的 Druid 也不是 1.00 版。其次 Druid 依赖 Hadoop,动辄就使用大量的资源以及各种复杂的 hadoop 组件,最后 Druid 只提供 json 的方式,对传统的 DBA 使用十分不友好。


TDengine 有一个我认为很秀的功能,就是它的超级表的跨指标维度建模思想,目前它仅用于 自由组合维度指标,拼接不同的时间粒度进行聚合。在我看来,将来应用于时间序列机器学习模型也是它的一个亮点。在数据建模方面,针对工厂的设施、设备、机床、机房、车间、测台等晦涩,必须要做高效准确的定义。我们进行项目规划建设的时候,都会做大量的数据治理工作,但是具体实施工作的时候,还是要使用这些传统工具和技术。TDengine 可以有效汇集各种机器数据源,并且能够高质量的提炼,这个是过去没有的。

我对 TDengien 的未来展望

一个老人和一个年青人站在一起,有句话如此说姜是老的辣,同时也有另外一句话,长江后浪推前浪,一代新人胜旧人,IT 世界千变万化, TDengine 这几年的冒起太迅速。最近 TDengine 推出 3.0 版本。新版优化了流计算功能,而且还重新设计了计算引擎,优化工程师 对 SQL 的使用,另外 增加了 taosX,利用自己的数据订阅功能来解决增量备份、异地容灾。我对 TDengine 未来的发展方向路径,希望它增加库内机器学习函数,增加 ARIMA 模型、MA 模型等时间相关功能,TDengine 的未来是一个智能学习时间序列数据库,为工业 4. 0 不仅是提速,更是赋能。

用户头像

李草凯

关注

还未添加个人签名 2018-11-15 加入

还未添加个人简介

评论

发布
暂无评论
国产时序数据库TDengines学习调研及总结_李草凯_InfoQ写作社区