作者：大统计数据源
第一集该文出自2022年“用 TDengine，写 TDengine”征文活动征稿活动。
因为工作的关系，最近几年我接触到过各种升级换代资料库，惟独对 TDengine 耿耿于怀。在众多资料库中，TiDB 独领风骚，OceanBase 出身区锡索，openGauss 有宏碁袒护，多于 TDengine 给人有一种蔗茅出英雄的感觉；在合作开发上，TiDB 转作了 rocksDB 的操控性，openGauss 是如前所述 postgreSQL9.2.4合作开发的，即便 OceanBase 也是如前所述内部应用领域需求开始打造的，多于 TDengine 不依赖任何开放源码或服务器端软件暗鞘而成。而且它不是一款全功能型的统计数据库，剑走偏锋，它有自己独特的社会应用领域情景，主要为工业网服务项目。
如前所述对 TDengine 的定义和理解，笔者将会在第一集该文中从 TDengine 能解决什么问题、它的优势与亮点、它与其它资料库的差别等层次展开详细描述，希望能帮助到对 TDengine 钟爱的爸爸妈妈。
“差别于全功能资料库，TDengine 丢出罢了本钱”
资料库想要完成出色的的随机存取，最核心的潜能就是检索，一般资料库产品都具备萨德基检索潜能。所谓萨德基检索就是透过文件格式记录里头的URL为URL，透过关键URL不再需要进行Maubourguet扫描器。虽然 B树检索、基元检索、图形检索有差别，但是基本思路都属于萨德基检索。
除了萨德基检索，还有逆向检索【也称征迁检索】，逆向索引主要用于中文信息，例如 ElasticSearch，大多资料库都是萨德基检索。TDengine 也是使用萨德基检索，它的不同之处是URL肯定包含天数戳，再加上两个层次分项统计数据，构成两个对统计数据值明确的描述——某一天数某一分项对象的统计数据值是多少。
从统计数据组织的储存发动机来看，资料库下层可以分为 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 用上行列并存、用途分离的方式。
一般来说，资料库里头每一行的文件格式记录都是非常重要的，即便这行记录信息无关交易，只是两个用户的基本信息，那它的价值密度也十分高。但排程资料库（Time Series Database）不同，单行文件格式记录价值密度低，因为1 秒可以产生1 万条记录，必须要把统计数据聚合汇总起来才能体现统计数据的价值。快速并有效聚合普通统计数据使之变成价值密度高的统计数据，这个也是排程资料库差别于其它资料库的两个重要的特征。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 类似的语言（2.0版本不再支持）。
天数序列的业务背景，在 OLAP 情景中一般会进行预聚合来增加统计数据量，影响预聚合主要因素可以汇总如下：
层次分项的个数层次分项的基数层次分项组合程度天数层次分项的粗粒度和细粒度
为了实现高效的预聚合，TDengine 的秘诀是超级表，Druid 会提前定义预计算，InfluxDB 也有自己的连续查询方法，多于 HBase 使用时才进行拼接，所以涉及不同的层次分项查询，HBase 会慢一些。
据了解，TDengine 如前所述 TSBS 的测试报告将于近日出炉，第一期报告针对 InfluxDB 和 Tim
“放到今天，TDengine 一定是首选”
我对 TDengine 的认识和了解要从过去的项目经验说起，以2018年为背景，我给大家讲述两个工业界坏件故障件预测的故事。
某知名集团随着公司业务的快速增长、新工厂的不断增加，各种有价值的统计数据不能很好的整合、分析与挖掘出它应有的价值。此时公司发展已经进入下一轮“拼”的战略，快速响应与准确预测是业务发展的关键，大统计数据在其中起到举足轻重的作用，以科学的分析手法整合各系统统计数据、推动工厂制造智能化发展，成为一件迫在眉睫的工作。
当前工厂生产过程中出现了同一种特殊问题的 glass id，glass 的品质由于各种原因是参差不齐的，甚至会有品质异常的 glass。这些异常 glass 在检测过程中，是无法检测出异常原因的，如果无法快速定位出异常原因，就会造成更多的异常 glass，严重影响生产。应对的具体手段包括：
透过品质异常的 glass，找到产生此异常的相关性因子。如：机台、物料、载具、参数等。异常 glass 侦测预警，透过对产生品质异常的因子进行数学建模，预测出偏离正常范围的异常玻璃，提前预警。分析 glass 的特征值与特征值之间的关联关系，并建立预测模型，提前预测出 glass 的特征值。分析 glass 相关的电压、电阻、电流、温度、湿度影响。
很明显这是统计数据挖掘的项目，要分析以上 glass 在生产过程中的环境信息、检测机台资料、量测机台资料、制程参数信息，以及 FDC、OEE 系统的统计数据，才能找寻产生这种问题的原因。第一步是统计数据收集整合，第二步是统计数据探索，第三步是模型调校——找寻可能性、影响最大的因素的特征因素，第四步是投入生产验证，透过 spark ml 提供预测动力。
当时的技术栈用的是 CDH，首先要透过 Kafka 采集统计数据，Spark对接 Kafka 进行初步计算去噪并汇总到 Hadoop 里头，以 parquet 的格式保存，如果需要进一步的加工，就透过 impala 进行。这样每天挂起 N 个任务，不停的调度计算。
CDH Hadoop 虽然无法做到实时统计数据分析，但是也还能做些事，聊胜于无，就继续用着。当时这个坏件故障件预测项目有以下痛点，主要是及时性、有效性、准确性的问题：
难以满足用户需求，某些机器统计数据的聚合计算需要第二天才能出结果，甚至更多的天数才能出来。经济成本的费用较高，CPU、磁盘、网络都在两个高段的使用状态，针对越来越多的统计数据需要投入新机器。维护成本高，你需要维护 Hadoop 所有的机器，各种 HBase、Spark、Zookeeper、HDFS 之类，不但对工程师要求高，而且工作量巨大。低质量统计数据，因为统计数据流程或者错误的逻辑整合，导致机器传感器聚合后统计数据源无法正常使用。无法做到实时监测，机器统计数据作为宝贵的自变量因素无法及时传输并进行计算，自然会影响因变量。
笔者经历了这个项目，知道这个坏件故障预测与天数序列有紧密的关系。时至今日，天数序列分析也是重要的统计数据分析技术，尤其面对季节性、周期性变化统计数据时，传统的回归拟合技术难以奏效，这时就需要复杂的天数序列模型，以天数为特征作为抓手点。这样即便你不太懂业务的前提下，也可以进行统计数据挖掘的工作。
那这个项目与 TDengine 有什么关系呢？实际上，这个项目并没有用上 TDengine，后来集团搭建了两个 Hadoop集群试点，这次居然用了 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 可以有效汇集各种机器统计数据源，并且能够高质量的提炼，这个是过去的排程统计数据产品所不具备的。
“是提速，更是赋能”
年 TDengine 推出3.0版本，新版本升级成为了一款真正的云原生排程资料库，优化了流计算功能，而且还重新设计了计算发动机，优化工程师对 SQL 的使用，另外增加了 taosX，利用自己的统计数据订阅功能来解决增量备份、异地容灾，更加方便了企业应用领域。我对 TDengine 未来的期望是，希望它增加库内机器学习函数，增加 ARIMA 模型、MA 模型等天数相关功能，TDengine 的未来是两个智能学习天数序列资料库，对工业4.0 来说不仅是提速，更是赋能。
