国产时序数据库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不仅是提速，更是赋能。