TDengine(老段）专注时序数据库领域

深度解析 Group by 与 Partition by 的实现及使用

工业 4.0 的核心是 “数据驱动”，而数据驱动的前提是 “数据自由流动”。TDengine 从开源内核出发，通过标准兼容打破工具壁垒，通过 MQTT 订阅升级拓宽数据接入场景，通过多平台发布功能打通下游链路，构建起覆盖工业数据全生命周期的开放生态 —— 既解决了传统系统的 “孤岛困境”，又契合中国工业企业 “国产化、低成本、高效率” 的数字化需求。随着工业 AI、数字孪生等技术的深入应用，工业数据对 “开放流动” 的需求将进一步提升。

数据缓存设计及使用

✅基于 WAL 的高性能队列：顺序写入,零拷贝读取✅Push-Pull 混合模式：实时推送 + 批量拉取,兼顾延迟和吞吐✅查询订阅：服务端过滤,减少传输 90%+✅自动 Rebalance：消费者增删自动负载均衡✅至少一次语义：Offset 管理,保证数据不丢失✅多消费组隔离：支持不同消费场景独立消费。

TDengine 高性能的查询引擎设计

TDengine 存储引擎揭秘：如何实现 10 倍性能与 50 倍压缩？

TDengine 引擎为什么这样快

taosX Parser 插件是一个要求用 C/Rust 语言开发的 C ABI 兼容动态库，该动态库要实现约定的 API 并编译为在 taosX 所在运行环境中能够正确运行的动态库，然后复制到约定位置由 taosX 在运行时加载，并在处理数据的 Parsing 阶段调用。

BSS（Byte-Stream-Split）是 TDengine 针对 FLOAT/DOUBLE 字段推出的新一代编码方式，自 v3.3.8.0 起默认启用，旨在提高压缩效率的同时保持与旧编码相近的读写性能。

- 创建用户定义函数-- 使用UDF-- 删除UDF-- MySQL 存储过程BEGIN-- 自定义逻辑END //DELIMITER;功能类别TDengineMySQL主要差异点数据模型超级表/子表模型单表模型TDengine 支持模板化表结构时序特性内置时间窗口、插值需要复杂SQL实现TDengine 原生支持时序函数写入方式多表批量写入、自动建表标准INSERT语句TDengine 支持更灵活的批量操作连接类型ASOF、窗口连接标准连接。

TDgpt 安装过程中需要在本地编译 uWSGI，某些环境的 Python（例如：anaconda）安装 uWSGI 会出现冲突导致编译失败，安装流程因此无法继续下去。这种情况下可以尝试在安装过程中忽略 uWSGI 的安装。由于忽略了 uWSGI 安装，后续启动 taosasnode 服务的时候，需要手动输入命令进行启动。执行该命令的时候请确保使用了虚拟环境中的 Python 程序才能加载依赖库。

TDgpt 在企业版中提供预测分析模型和异常检测模型有效性评估工具，该工具能够使用 TDengine 中的时序数据作为回测依据，评估不同预测模型或训练模型的有效性。该工具在开源版本中不可用使用评估工具，需要在其相关的配置文件中设置正确的参数，包括选取评估的数据范围、结果输出时间、参与评估的模型、模型的参数、是否生成预测结果图等配置。在具备完备的 Python 库的运行环境中，通过shell调用 TDgpt 安装路径下的 misc 中的命令即可。

由众多研究机构及企业开源时序基础模型极大地简化了时序数据分析的复杂程度，在数据分析算法、机器学习和深度学习模型之外，提供了一个时间序列数据高级分析的新选择。本章介绍部署并使用开源时序基础模型（Time Series Foundation Model, TSFM）。TDgpt 在 3.3.6.4 版本原生支持五种类型的时序基础模型：涛思时序基础模型 (TDtsfm v1.0) , time-moe，chronos, moirai, timesfm。

机器/深度学习模型一般要求训练集样本量足够大，才能取得不错的预测效果。训练过程要消耗一定量的时间和计算资源，并需要根据输入的数据进行定期的训练以及更新模型。TDgpt 内置了 PyTorch 和 Keras 机器学习库。所有使用 PyTorch 或 Keras 开发的模型均可以驱动运行。本章介绍将预训练完成的机器/深度学习分析模型添加到 TDgpt 中的方法。

execute是算法处理的核心方法。框架调用该方法之前，在对象属性参数self.list中已经设置完毕用于异常检测的时间序列数据。

execute是预测分析算法的核心方法。框架调用该方法之前，在对象属性参数self.list中已经设置完毕用于预测的历史时间序列数据。

Local Outlier Factor(LOF)，局部离群因子/局部异常因子，是 Breunig 在 2000 年提出的一种基于密度的局部离群点检测算法，该方法适用于不同类簇密度分散情况迥异的数据。根据数据点周围的数据密集情况，首先计算每个数据点的局部可达密度，然后通过局部可达密度进一步计算得到每个数据点的一个离群因子。该离群因子即标识了一个数据点的离群程度，因子值越大，表示离群程度越高，因子值越小，表示离群程度越低。最后，输出离群程度最大的。后续待添加基于数据挖掘检测算法。第三方异常检测算法库。

上面是 TDgpt 的下一代重磅级新产品技术介绍发布会， 会上将有重大让你尖叫的技术革新公布，欢迎大家扫码预约直播！IQR[2]：Interquartile range(IQR)，四分位距是一种衡量变异性的方法。四分位数将一个按等级排序的数据集划分为四个相等的部分。即 Q1（第 1 个四分位数）、Q2（第 2 个四分位数）和 Q3（第 3 个四分位数）。 IQR=Q3−Q1IQR=Q3-Q1IQR=Q3−Q1，对于 vvv，Q1−(1.5×IQR)≤v≤Q3+(1.5×IQR)Q1-(1.5 \time

TDengine 中定义了异常（状态）窗口来提供异常检测服务。异常窗口可以视为一种特殊的，即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于，时间窗口的起始时间和结束时间均由分析算法识别确定，不通过用户给定的表达式进行判定。因此，在WHERE子句中使用关键词即可调用时序数据异常检测服务，同时窗口伪列（_WSTART_WEND_WDURATION）也能够像其他时间窗口一样用于描述异常窗口的起始时间 (_WSTART)、结束时间 (_WEND)、持续时间 (_WDURATION。

时序数据基础模型是专门训练用以处理时间序列数据预测和异常检测、数据补齐等高级时序数据分析功能的基础模型，时序基础模型继承了大模型的优良泛化能力，无需要设置复杂的输入参数，即可根据输入数据进行预测分析。序号参数说明1tdtsfm_1涛思时序数据基础模型 v1.02time-moeMoE 时序基础模型3moiraiSalesForce 开源的时序基础模型4chronosAmazon 开源的时序基础模型5timesfmGoogle 开源的时序基础模型。

HoltWinters 模型又称为多次指数平滑模型（EMA）。适用于含有线性趋势和周期波动的非平稳序列，利用指数平滑法让模型参数不断适应非平稳序列的变化，并对未来趋势进行短期预测。HoltWinters 有两种不同的季节性组成部分，当季节变化在该时间序列中大致保持不变时，通常选择加法模型；而当季节变化与时间序列的水平成比例变化时，通常选择乘法模型。该模型对于返回数据不提供计算的置信区间范围结果，在 95% 置信区间的上下界结果与预测结果相同。

ARIMA：Autoregressive Integrated Moving Average，即自回归移动平均模型，记作 ARIMA(p,d,q)，是统计模型中最常见的一种用来进行时间序列预测的模型。ARIMA 模型是一种自回归模型，只需要自变量即可预测后续的值。ARIMA 模型要求时间序列平稳，或经过差分处理后平稳，如果是不平稳的数据，无法获得正确的结果。平稳的时间序列：其性质不随观测时间的变化而变化。具有趋势或季节性的时间序列不是平稳时间序列——趋势和季节性使得时间序列在不同时段呈现不同性质。

上面是 TDgpt 的下一代重磅级新产品技术介绍发布会， 会上将有重大让你尖叫的技术革新公布，欢迎大家扫码预约直播！

（上图为 TDgpt 的下一代重磅级新产品技术介绍发布会， 会上将有重大让你尖叫的技术革新公布，欢迎大家扫码预约直播！

上面是 TDgpt 的下一代新产品的技术介绍发布会， 会上将有重大技术革新公布，欢迎大家扫码预约直播！

TDgpt 是一个可扩展的时序数据高级分析智能体，用户遵循算法开发者指南中的简易步骤就能将自己开发的分析算法添加到系统中。之后应用可以通过 SQL 语句直接调用，让高级分析算法的使用门槛降到几乎为零。对于新引入的算法或模型，应用不用做任何调整。TDpgt 只支持使用 Python 语言开发的分析算法。Anode 采用 Python 类动态加载模式，在启动的时候扫描特定目录内满足约定条件的所有代码文件，并将其加载到系统中。因此，开发者只需要遵循以下几步就能完成新算法的添加工作。开发完成符合要求的分析算法类。

FQDN(fully qualified domain name,完全限定域名)是internet上特定计算机或主机的完整域名。FQDN由两部分组成:主机名和域名。例如，假设邮件服务器的FQDN可能是mail.taosdata.com。主机名是mail，主机位于域名taosdata.com中。DNS(Domain Name System)，负责将FQDN翻译成IP，是互联网绝大多数应用的寻址方式。

在工业互联网和物联网等领域，数据集的价值与其规模是成正比的：应用程序和算法可以使用的数据越多，它们的输出结果就越精确。然而，由众多设备产生的海量数据需要处理，对于大型企业来说，存储成本可能会非常高昂。但有一个好消息，那就是时序数据非常易于压缩。TDengine 大幅提高了数据压缩率，甚至能将数据集压缩至原始大小的1/10，并且几乎不会影响处理性能。这一切都得益于几个关键的创新点。

对应到 TDengine 中，只有当过半数的节点把该条 SQL 的写入信息追加到文件系统上的 WAL（即图中的步骤 2），并且收到确认消息之后，这条 Log entry 才会被 Leader 认为是安全的。在持续写入数据的过程中，TDengine 会按照协议机制在每个成员节点上产生完全相同的日志记录，并且以相同的顺序执行数据变更操作，以 WAL 的形式，存储在数据文件目录中。而在 3.0 ，我们则引入了标准的 RAFT 算法，以更通用标准的实现方式，去适用更广泛的应用场景。（上图红色箭头部分）

TDengine 建模需根据设备类型、指标特性（是否固定、时间戳是否一致）选择多列或单列模型，通过超级表管理同类型设备，合理分库分表，并利用标签优化查询效率；同时可结合数据分层设计满足采集与应用需求。

长查询问题指的是在数据库写入和查询并存的日常应用场景中，存在处理数据量大且耗时很长的查询长时间占用系统资源，导致写入可能被阻塞的问题。有时，查询代码对于资源释放函数调用的遗忘也可能以长查询问题的形式表现出来。如何在数据写入不被阻塞同时，保证长查询的正确进行是一个具有挑战性的问题。在分析长查询问题之前，我们首先需要为大家普及一下 TDengine 的写入/查询并发机制。

如下图，payload 是 64bit 的 simple8B 数据，使用 AVX512 指令，通过并行同步移位和掩码的方式，一次提取出 8 个有效数据，并装载在 512bit 的寄存器里（32bit x 8），为 ZigZag 算法提供数据输入。特别是针对 Simple8B 和 ZigZag 算法的优化，让时序数据的处理得以实现更高效的并行计算，通过一次性处理多个数据，减少了指令数，显著提升了系统的性能表现。而数据平均值的查询过程则是相反的，需要对存储的数据进行解码和计算。

定义一个有效数字最多为 4 个小数点右侧 2 位DECIMAL(precision, scale) -- 完整格式DECIMAL(precision) -- scale 默认为 0-- 错误示例-- 错误：Scale 不能大于 Precision解决方案：确保。

在 4 核时 CPU 使用率降至 88%，若再增加 CPU 可能 CPU 不会再成为瓶颈，所以升级配置至 12 个 VGROUPS、12 写入线程，让 CPU 始终保持在瓶颈状态下。硬件配置：CPU 24 核， 64 GB 内存，挂三块普通 5400 转低速机械盘（选择性能普通的硬盘，有利于很快打满 IO，达到 IO 成为瓶颈的条件 ）验证在带宽、IO 及内存不是瓶颈，仅 CPU 是瓶颈的情况下，写入速度应与 CPU 核数成正比。CPU: 24 核 CPU ，大部分都为空闲，CPU 非常富余。

配置参数：作用于集群内所有 dnode 且在集群内必须保持一致的变量，也称为全局变量系统变量或全局参数。以上配置必须保持一致，不一致则程序返回结果可能会有问题。

如果有大量的删表、删数据行为，不能准确计算得到压缩率等信息，需要等到完全compact 完全结束之后，才能得到一个相对准确的压缩率，如果在compact 还没有结束时，查询得到的磁盘占用可能过大。TDengine 之前版本一直没有通过 SQL 命令查看数据库占用的磁盘空间大小，从 3.3.5.0 开始，增加了这个方便且实用的小功能，这里详细介绍下。类似， 如果 DB 上超级表或者普通表的数目为 N， 执行单个。预估出来的真实数据的大小，不含mem table。多副本情况下，只统计单副本的DB的占用大小。

内存池：本次功能实现是通过一个通用会话内存池与查询的结合来实现，受限于时间问题，暂时只能先实现最简单的内存管理策略——直接从系统分配与释放，后续再增加复用与其他策略。分配的内存大小（MS）：在通过各种内存分配接口从系统分配内存时指定的要分配的内存大小，其值由应用具体指定。实际分配的内存大小（AMS）：通过各种内存分配接口从系统分配的实际内存大小，因为内存管理器的实现原因，其值有可能会大于应用指定的分配大小。

与 InfluxDB 相比，TDengine 在流式计算的基础上，还具备强大的 ETL 能力——它不仅能处理时序数据，还能自动进行数据清洗与转换，帮助用户实现更加高效、灵活的数据处理。这一优势使得 TDengine 能在更多复杂的应用场景中提供卓越的性能，尤其是对于需要实时数据分析和高效数据处理的行业，提供了更为完善的解决方案。

TDengine OSS 之 2025 年年度路线图如下表所示。欲了解更多信息，请参见。

机器设备产生的时序数据量大，直接存储成本非常高，所以需要使用压缩技术，尽可能减小体积。 TDengine 使用了列式存储，结合二级压缩技术，压缩率通常可以达到 20%，特殊情况下更能达到 5 % 以内，超高的压缩率实实在在的为用户节约了磁盘空间。