merge: from 3.0 to 3.3.6 (#30373)
* Update 09-error-code.md * Update 03-preprocess.md * Update index.md * Update index.md * Update index.md * doc: update docs. * Update index.md * Update index.md * Update index.md * Update index.md * Update 03-preprocess.md * Update index.md * Update index.md * Update index.md * Update 03-preprocess.md * Update index.md * Update index.md * doc(gpt): update the figures. * doc(gpt): update figure size * doc(gpt): add new pages. * Update 01-model.md * Update 02-insert.md * Update 01-model.md * Update 02-management.md (#30371) * fix: [TS-4897] Fix create child table after modify super virtual table failed (#30316) --------- Co-authored-by: Haojun Liao <hjxilinx@users.noreply.github.com> Co-authored-by: Haojun Liao <hjliao@taosdata.com> Co-authored-by: Linhe Huo <linhehuo@gmail.com> Co-authored-by: Jeff Tao <jhtao@taosdata.com> Co-authored-by: Jing Sima <simondominic9997@outlook.com>
|
@ -57,11 +57,11 @@ toc_max_heading_level: 4
|
|||
|
||||
### 超级表
|
||||
|
||||
采用“一个数据采集点一张表”的设计虽然有助于针对性地管理每个采集点,但随着设备数量不断增加表的数量也会急剧增加,这给数据库管理和数据分析带来了挑战。在进行跨数据采集点的聚合操作时,用户需要面对大量的表,工作变得异常繁重。
|
||||
TDengine 采用“一个数据采集点一张表”的设计虽然有利于高效地管理每个数据采集点,但随着设备数量不断增加,表的数量也会急剧增加,这给表的管理以及表之间的聚合带来了巨大的挑战。
|
||||
|
||||
为了解决这个问题,TDengine 引入超级表(Super Table,简称为 STable)的概念。超级表是一种数据结构,它能够将某一特定类型的数据采集点聚集在一起,形成一张逻辑上的统一表。这些数据采集点具有相同的表结构,但各自的静态属性(如标签)可能不同。创建超级表时,除了定义采集量以外,还需定义超级表的标签。一张超级表至少包含一个时间戳列、一个或多个采集量列以及一个或多个标签列。此外,超级表的标签可以灵活地进行增加、修改或删除操作。
|
||||
为了解决这个问题,TDengine 引入超级表(Super Table,简称为 STable)的概念。超级表是一种数据结构,它能将某一特定类型的数据采集点聚集在一起,形成一张逻辑上的统一表。这些数据采集点具有相同的表结构,但各自的静态属性(如标签)可能不同。创建超级表时,除了定义采集量的结构之外,还需定义超级表的标签。一张超级表至少包含一个时间戳列、一个或多个采集量列以及一个或多个标签列。此外,超级表的标签可以灵活地进行增加、修改或删除操作。
|
||||
|
||||
在 TDengine 中,表代表具体的数据采集点,而超级表则代表一组具有相同属性的数据采集点集合。以智能电表为例,我们可以为该类型的电表创建一张超级表,其中包含了所有智能电表的共有属性和采集量。这种设计不仅简化了表的管理,还便于进行跨数据采集点的聚合操作,从而提高数据处理的效率。
|
||||
在 TDengine 中,表代表具体的数据采集点,而超级表则代表一组具有相同属性的数据采集点集合。以智能电表为例,我们可以为该类型的电表创建一张超级表,其中包含了所有智能电表的共有属性,包括动态的时序数据以及静态的标签数据。这种设计不仅简化了表的管理,还便于进行跨数据采集点的聚合操作,从而提高数据处理的效率。
|
||||
|
||||
### 子表
|
||||
|
||||
|
@ -79,19 +79,16 @@ toc_max_heading_level: 4
|
|||
|
||||
### 虚拟表
|
||||
|
||||
“一个设备一张表”的设计解决了工业和物联网等场景下的大多数时序数据管理和分析难题,但是在遇到更复杂的场景时,这种设计受到了设备复杂性的挑战。根源在于一个设备无法简单的用一个或一组数据采集点来描述或管理,而业务分析往往需要综合多个或多组采集点的数据才能完成。以汽车或发电风机为例,整个设备(汽车或风机)中含有非常大量的传感器(数据采集点),这些传感器的输出和采集频率千差万别。一个超级表只能描述其中一种传感器,当需要综合多个传感器的数据进行分析计算时,只能通过多级关联查询的方式来进行,而这往往会导致易用性和性能方面的问题。
|
||||
“一个数据采集点一张表”以及“超级表”的设计解决了工业和物联网等场景下的大多数时序数据管理和分析难题。但是在真实的场景中,一个设备往往有多种传感器,而且他们的数据采集频次还相差很大。比如对于一台风机,有电的参数、环境参数、机械参数,各自的传感器和采集频次完全不一样。因此我们很难用一张表来描述一台设备,往往需要多张表。当需要综合多个传感器的数据进行分析计算时,只能通过多级关联查询的方式来进行,而这往往会导致易用性和性能方面的问题。而从用户的角度来看,“一个设备一张表”更为直观,容易操作。但如果我们建模之初,直接采用"一个设备一张表的“的设计,由于采集频次的不同,会导致每一个具体时间戳,大量的列是空值,从而降低存储和查询的效率。
|
||||
|
||||
为了解决这个问题,TDengine 引入虚拟表(Virtual Table,简称为 VTable)的概念。虚拟表是一种不存储实际数据而可以用于分析计算的表,它的数据来源为其它真实存储数据的子表、普通表,通过将不同列数据按照时间戳排序、对齐、合并的方式来生成虚拟表。同真实表类似,虚拟表也可以分为虚拟超级表、虚拟子表、虚拟普通表。虚拟超级表可以是一个设备或一组分析计算所需数据的完整集合,每个虚拟子表可以根据需要引用相同或不同的列,因此可以灵活地根据业务需要进行定义,最终达到千表千面的效果。虚拟表不能写入、删除数据,在查询使用上同真实表基本相同,支持虚拟超级表、虚拟子表、虚拟普通表上的任何查询。唯一的区别在于虚拟表的数据是每次查询计算时动态生成的,只有一个查询中引用的列才会被合并进虚拟表中,因此同一个虚拟表在不同的查询中所呈现的数据可能是不同的。
|
||||
为了解决这个问题,TDengine 引入虚拟表(Virtual Table,简称为 VTable)的概念。虚拟表是一种不存储实际数据而可以用于分析计算的表,它的数据来源为其它真实存储数据的子表、普通表,通过将各个原始表的不同列的数据按照时间戳排序、对齐、合并的方式来生成虚拟表。同真实表类似,虚拟表也可以分为虚拟超级表、虚拟子表、虚拟普通表。虚拟超级表可以是一个设备或一组分析计算所需数据的完整集合,每个虚拟子表可以根据需要引用相同或不同的列,因此可以灵活地根据业务需要进行定义,最终达到“千人千面”的效果。虚拟表不能写入、删除数据,在查询使用上同真实表相同。TDengine 支持虚拟超级表、虚拟子表、虚拟普通表上的任何查询。唯一的区别在于虚拟表的数据是每次查询计算时动态生成的,只有一个查询中引用的列才会被合并进虚拟表中,因此同一个虚拟表在不同的查询中所呈现以及扫描的数据可能是完全不同的。
|
||||
|
||||
虚拟超级表的主要功能特点包括:
|
||||
1. 列选择与拼接 <br />
|
||||
用户可以从多个原始表中选择指定的列,按需组合到一张虚拟表中,形成统一的数据视图。
|
||||
2. 基于时间戳对齐 <br />
|
||||
以时间戳为依据对数据进行对齐,如果多个表在相同时间戳下存在数据,则对应列的值组合成同一行;若部分表在该时间戳下无数据,则对应列填充为 NULL。
|
||||
3. 动态更新 <br />
|
||||
虚拟表根据原始表的数据变化自动更新,确保数据的实时性。虚拟表不需实际存储,计算在生成时动态完成。
|
||||
1. 列选择与拼接:用户可以从多个原始表中选择指定的列,按需组合到一张虚拟表中,形成统一的数据视图。
|
||||
2. 基于时间戳对齐:以时间戳为依据对数据进行对齐,如果多个表在相同时间戳下存在数据,则对应列的值组合成同一行;若部分表在该时间戳下无数据,则对应列填充为 NULL。
|
||||
3. 动态更新:虚拟表根据原始表的数据变化自动更新,确保数据的实时性。虚拟表不需实际存储,计算在生成时动态完成。
|
||||
|
||||
通过引入虚拟表的概念,TDengine 可以非常方便的管理更大更复杂的设备数据。无论每个采集点如何建模(单列 or 多列),无论这些采集点的数据是分布在一个或多个库中,都可以通过定义虚拟子表的方式跨库跨表任意指定数据源,通过虚拟超级表的方式进行跨设备、跨分析的聚合运算,从此“一个设备一张表”彻底成为现实。
|
||||
通过引入虚拟表的概念,TDengine 可以非常方便的管理更大更复杂的设备数据。无论每个采集点如何建模(单列 or 多列),无论这些采集点的数据是分布在一个或多个库中,都可以通过定义虚拟表的方式跨库跨表任意指定数据源,通过虚拟超级表的方式进行跨数据采集点、跨分析的聚合运算,从此“一个设备一张表”彻底成为现实。
|
||||
|
||||
### 库
|
||||
|
||||
|
|
|
@ -113,6 +113,9 @@ TDengine 还支持直接向超级表写入数据。需要注意的是,超级
|
|||
insert into meters (tbname, ts, current, voltage, phase, location, group_id)
|
||||
values("d1001", "2018-10-03 14:38:05", 10.2, 220, 0.23, "California.SanFrancisco", 2)
|
||||
```
|
||||
### 通过虚拟表写入
|
||||
|
||||
TDengine 不支持向虚拟表或虚拟超级表写入,因为虚拟表或虚拟超级表是动态生成的,本身不存储数据。
|
||||
|
||||
### 零代码写入
|
||||
|
||||
|
|
|
@ -5,14 +5,14 @@ sidebar_label: "安装部署"
|
|||
|
||||
### 环境准备
|
||||
使用 TDgpt 的高级时序数据分析功能需要在 TDengine 集群中安装部署 AI node(Anode)。Anode 运行在 Linux 平台上,并需要 3.10 或以上版本的 Python 环境支持。
|
||||
> 部署 Anode 需要 TDengine Enterprise 3.3.4.3 及以后版本,请首先确认搭配 Anode 使用的 TDengine 能够支持 Anode。
|
||||
> 部署 Anode 需要 TDengine 3.3.6.0 及以后版本,请首先确认搭配 Anode 使用的 TDengine 能够支持 Anode。
|
||||
|
||||
### 安装及卸载
|
||||
使用 Linux 环境下的安装包 TDengine-enterprise-anode-1.x.x.tar.gz 可进行 Anode 的安装部署工作,命令如下:
|
||||
使用 Linux 环境下的安装包 TDengine-anode-3.3.x.x-Linux-x64.tar.gz 可进行 Anode 的安装部署工作,命令如下:
|
||||
|
||||
```bash
|
||||
tar -xzvf TDengine-enterprise-anode-1.0.0.tar.gz
|
||||
cd TDengine-enterprise-anode-1.0.0
|
||||
tar -xzvf TDengine-anode-3.3.6.0-Linux-x64.tar.gz
|
||||
cd TDengine-anode-3.3.6.0
|
||||
sudo ./install.sh
|
||||
```
|
||||
|
||||
|
@ -80,7 +80,7 @@ app-log = /var/log/taos/taosanode/taosanode.app.log
|
|||
model-dir = /usr/local/taos/taosanode/model/
|
||||
|
||||
# default log level
|
||||
log-level = DEBUG
|
||||
log-level = INFO
|
||||
|
||||
```
|
||||
|
||||
|
|
|
@ -9,14 +9,14 @@ import wndata from './pic/white-noise-data.png'
|
|||
### 分析流程
|
||||
时序数据分析之前需要有预处理的过程,为减轻分析算法的负担,TDgpt 在将时序数据发给具体分析算法进行分析时,已经对数据做了预处理,整体的流程如下图所示。
|
||||
|
||||
<img src={activity} width="320" alt="预处理流程" />
|
||||
<img src={activity} alt="预处理流程"/>
|
||||
|
||||
TDgpt 首先对输入数据进行白噪声检查(White Noise Data check), 检查通过以后针对预测分析,还要进行输入(历史)数据的重采样和时间戳对齐处理(异常检测跳过数据重采样和时间戳对齐步骤)。
|
||||
预处理完成以后,再进行预测或异常检测操作。预处理过程不属于预测或异常检测处理逻辑的一部分。
|
||||
|
||||
### 白噪声检查
|
||||
|
||||
<img src={wndata} width="344" alt="white-noise-data"/>
|
||||
<img src={wndata} alt="white-noise-data"/>
|
||||
|
||||
白噪声时序数据可以简单地认为是随机数构成的时间数据序列(如上图所示的正态分布随机数序列),随机数构成的时间序列没有分析的价值,因此会直接返回。白噪声检查采用经典的 `Ljung-Box` 统计量检验,计算 `Ljung-Box` 统计量需遍历整个输入时间序列。如果用户能够明确输入序列一定不是白噪声序列,那么可以在参数列表中增加参数 `wncheck=0` 强制要求分析平台忽略白噪声检查,从而节省计算资源。
|
||||
TDgpt 暂不提供独立的时间序列白噪声检测功能。
|
||||
|
|
|
@ -5,7 +5,7 @@ description: 预测算法
|
|||
|
||||
import fc_result from '../pic/fc-result.png';
|
||||
|
||||
时序数据预测处理以持续一个时间段的时序数据作为输入,预测接下来一个连续时间区间内时间序列数据趋势。用户可以指定输出的(预测)时间序列数据点的数量,因此其输出的结果行数不确定。为此,TDengine 使用新 SQL 函数 `FORECAST` 提供时序数据预测服务。基础数据(用于预测的历史时间序列数据)是该函数的输入,预测结果是该函数的输出。用户可以通过 `FORECAST` 函数调用 Anode 提供的预测算法提供的服务。
|
||||
时序数据预测处理以持续一个时间段的时序数据作为输入,预测接下来一个连续时间区间内时间序列数据趋势。用户可以指定输出的(预测)时间序列数据点的数量,因此其输出的结果行数不确定。为此,TDengine 引入新 SQL 函数 `FORECAST` 提供预测分析功能。基础数据(用于预测的历史时间序列数据)是该函数的输入,预测结果是该函数的输出。用户可以通过 `FORECAST` 函数调用 Anode 提供的预测算法提供的服务。预测分析通常只能针对超级表的子表或者不同表中同一个时间序列。
|
||||
|
||||
在后续章节中,使用时序数据表 `foo` 作为示例,介绍预测和异常检测算法的使用方式,`foo` 表的模式如下:
|
||||
|
||||
|
@ -62,6 +62,9 @@ algo=expr1
|
|||
2. 更改参数 `START`:返回预测结果的起始时间,改变起始时间不会影响返回的预测数值,只影响起始时间。
|
||||
3. `EVERY`:可以与输入数据的采样频率不同。采样频率只能低于或等于输入数据采样频率,不能**高于**输入数据的采样频率。
|
||||
4. 对于某些不需要计算置信区间的算法,即使指定了置信区间,返回的结果中其上下界退化成为一个点。
|
||||
5. rows 的最大输出值是 1024,即只能预测 1024 个值。超过输出范围的参数会被自动设置为 1024。
|
||||
6. 预测分析的输入数据行数最大值是 40000 行,即用于预测分析的历史数据不能超过 40000 行。针对部分分析模型,输入限制更严格。
|
||||
|
||||
|
||||
### 示例
|
||||
|
||||
|
@ -136,6 +139,9 @@ res_start_time = 1730000000000
|
|||
gen_figure = true
|
||||
```
|
||||
|
||||
|
||||
对比程序执行完成以后,会自动生成名称为`fc_result.xlsx` 的文件,第一个卡片是算法运行结果(如下表所示),分别包含了算法名称、执行调用参数、均方误差、执行时间 4 个指标。
|
||||
|
||||
| algorithm | params | MSE | elapsed_time(ms.) |
|
||||
| ----------- | ------------------------------------------------------------------------- | ------- | ----------------- |
|
||||
| holtwinters | `{"trend":"add", "seasonal":"add"}` | 351.622 | 125.1721 |
|
||||
|
@ -143,5 +149,5 @@ gen_figure = true
|
|||
|
||||
如果设置了 `gen_figure` 为 true,分析结果中还会有绘制的分析预测结果图(如下图所示)。
|
||||
|
||||
<img src={fc_result} width="360" alt="预测对比结果" />
|
||||
<img src={fc_result} alt="预测对比结果"/>
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ ANOMALY_WINDOW(col_val, "algo=iqr");
|
|||
|
||||
如下图所示,Anode 将返回时序数据异常窗口 $[10:51:30, 10:53:40]$
|
||||
|
||||
<img src={ad} width="760" alt="异常检测" />
|
||||
<img src={ad} alt="异常检测"/>
|
||||
|
||||
在此基础上,用户可以针对异常窗口内的时序数据进行查询聚合、变换处理等操作。
|
||||
|
||||
|
@ -98,7 +98,8 @@ grubbs={}
|
|||
lof={"algorithm":"auto", "n_neighbor": 3}
|
||||
```
|
||||
|
||||
对比程序执行完成以后,会自动生成名称为`ad_result.xlsx` 的文件,第一个卡片是算法运行结果(如下图所示),分别包含了算法名称、执行调用参数、查全率、查准率、执行时间 5 个指标。
|
||||
对比程序执行完成以后,会自动生成名称为`ad_result.xlsx` 的文件,第一个卡片是算法运行结果(如下表所示),分别包含了算法名称、执行调用参数、查全率、查准率、执行时间 5 个指标。
|
||||
|
||||
|
||||
|
||||
| algorithm | params | precision(%) | recall(%) | elapsed_time(ms.) |
|
||||
|
@ -111,5 +112,6 @@ lof={"algorithm":"auto", "n_neighbor": 3}
|
|||
|
||||
如果设置了 `gen_figure` 为 `true`,比较程序会自动将每个参与比较的算法分析结果采用图片方式呈现出来(如下图所示为 ksigma 的异常检测结果标注)。
|
||||
|
||||
<img src={ad_result} width="540" alt="异常检测标注图" />
|
||||
<img src={ad_result} alt="异常检测标注图"/>
|
||||
|
||||
|
||||
|
|
|
@ -8,6 +8,7 @@ sidebar_label: "预测算法"
|
|||
|
||||
### 输出约定及父类属性说明
|
||||
`execute` 方法执行完成后的返回一个如下字典对象, 预测返回结果如下:
|
||||
|
||||
```python
|
||||
return {
|
||||
"mse": mse, # 预测算法的拟合数据最小均方误差(minimum squared error)
|
||||
|
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: "缺失数据补值"
|
||||
sidebar_label: "缺失数据补值"
|
||||
---
|
||||
|
||||
近期发布
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: "时间序列分类"
|
||||
sidebar_label: "时间序列分类"
|
||||
---
|
||||
|
||||
近期发布
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 324 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 87 KiB After Width: | Height: | Size: 76 KiB |