Merge pull request #28768 from taosdata/doc/analysis
doc: update analytics documents.
This commit is contained in:
Shengliang Guan
GitHub
commit
df15ce8df3
|
|
@ -4,10 +4,11 @@ sidebar_label: "安装部署"
|
|||
---
|
||||
|
||||
### 环境准备
|
||||
为了使用 TDgpt 的高级时序数据分析功能功能，需要在 TDengine 集群中安装部署 AI node（Anode）。Anode 可以运行在 Linux/Windows/Mac 等操作系统之上。请确保安装部署 Anode之前，系统中已经具备 3.10 及以上版本的Python环境，以及相应的 Python 包自动安装组件 Pip，否则无法正常安装 Anode。
|
||||
使用 TDgpt 的高级时序数据分析功能需要在 TDengine 集群中安装部署 AI node（Anode）。Anode 可以运行在 Linux/Windows/MacOS 等平台上，同时需要 3.10 或以上版本的 Python 环境支持。
|
||||
|
||||
### 安装及卸载
|
||||
不同操作系统上安装及部署操作有细微的差异，主要是安装/卸载操作、安装路径、Anode服务的启停等几个方面。下面将以 Linux 系统为例，说明安装部署的整个流程。使用 Linux 环境下的安装包 TDengine-enterprise-anode-1.x.x.tar.gz 可进行 Anode 的安装部署工作，使用如下命令：
|
||||
不同操作系统上安装及部署 Anode 有一些差异，主要是卸载操作、安装路径、服务启停等方面。本文以 Linux 系统为例，说明安装部署的流程。
|
||||
使用 Linux 环境下的安装包 TDengine-enterprise-anode-1.x.x.tar.gz 可进行 Anode 的安装部署工作，命令如下：
|
||||
|
||||
```bash
|
||||
tar -xzvf TDengine-enterprise-anode-1.0.0.tar.gz
|
||||
|
|
@ -15,11 +16,11 @@ cd TDengine-enterprise-anode-1.0.0
|
|||
sudo ./install.sh
|
||||
```
|
||||
|
||||
在安装完成 Anode 之后，执行命令 `rmtaosanode` 即可已经安装的 Anode。
|
||||
Anode 使用 Python 虚拟环境运行，避免影响安装环境中现有的 Python 库。安装后的默认 Python 虚拟环境目录位于 `/var/lib/taos/taosanode/venv/`。为了避免反复安装虚拟环境带来的开销，卸载 Anode 执行的命令 `rmtaosanode` 并不会自动删除该虚拟环境，如果您确认不需要 Python 的虚拟环境，手动删除即可。
|
||||
对于已经安装的 Anode，执行命令 `rmtaosanode` 即可完成卸载。
|
||||
为了避免影响系统已有的 Python 环境，Anode 使用虚拟环境运行。安装 Anode 会在目录 `/var/lib/taos/taosanode/venv/` 中创建默认的 Python 虚拟环境，Anode 运行所需要的库均安装在该目录下。为了避免反复安装虚拟环境带来的开销，卸载命令 `rmtaosanode` 并不会自动删除该虚拟环境，如果您确认不再需要 Python 的虚拟环境，手动删除该目录即可。
|
||||
|
||||
### 启停服务
|
||||
在 Linux 系统中，安装 Anode 以后可以使用 `systemd` 来管理 Anode 服务。使用如下命令可以启动/停止/检查状态。
|
||||
在 Linux 系统中，安装 Anode 以后会自动创建 `taosadnoded` 服务。可以使用 `systemd` 来管理 Anode 服务，使用如下命令启动/停止/检查 Anode。
|
||||
|
||||
```bash
|
||||
systemctl start taosanoded
|
||||
|
|
@ -28,6 +29,8 @@ systemctl status taosanoded
|
|||
```
|
||||
|
||||
### 目录及配置说明
|
||||
安装完成后，Anode 主体目录结构如下：
|
||||
|
||||
|目录/文件|说明|
|
||||
|---------------|------|
|
||||
|/usr/local/taos/taosanode/bin|可执行文件目录|
|
||||
|
|
@ -39,7 +42,8 @@ systemctl status taosanoded
|
|||
|
||||
#### 配置说明
|
||||
|
||||
Anode 提供的服务使用 uWSGI 驱动，因此 Anode 和 uWSGI 的配置信息共同存放在相同的配置文件 `taosanode.ini`，该配置文件默认位于 `/etc/taos/`目录下，其具体内容及说明如下：
|
||||
Anode 的服务需要使用 uWSGI 驱动驱动运行，因此 Anode 和 uWSGI 的配置信息共同存放在相同的配置文件 `taosanode.ini` 中，该配置文件默认位于 `/etc/taos/` 目录下。
|
||||
具体内容及配置项说明如下：
|
||||
|
||||
```ini
|
||||
[uwsgi]
|
||||
|
|
@ -81,8 +85,8 @@ log-level = DEBUG
|
|||
```
|
||||
|
||||
**提示**
|
||||
请勿设置 `daemonize` 参数，该参数会导致 uWSGI 与 systemctl 冲突，从而无法正常启动。
|
||||
上面的示例配置文件 `taosanode.ini` 只包含了使用 Anode 提供服务的基础配置参数，对于 uWSGI 的其他配置参数设置及其含义和说明请参考 [uWSGIS官方文档](https://uwsgi-docs-zh.readthedocs.io/zh-cn/latest/Options.html)。
|
||||
请勿设置 `daemonize` 参数，该参数会导致 uWSGI 与 systemctl 冲突，从而导致 Anode 无法正常启动。
|
||||
上面的示例配置文件 `taosanode.ini` 只包含了使用 Anode 提供服务的基础配置参数，对于 uWSGI 的其他配置参数的设置及其说明请参考 [uWSGIS官方文档](https://uwsgi-docs-zh.readthedocs.io/zh-cn/latest/Options.html)。
|
||||
|
||||
Anode 运行配置主要是以下：
|
||||
- app-log: Anode 服务运行产生的日志，用户可以调整其到需要的位置
|
||||
|
|
@ -95,10 +99,10 @@ Anode 运行配置主要是以下：
|
|||
```sql
|
||||
CREATE ANODE {node_url}
|
||||
```
|
||||
node_url 是提供服务的 Anode 的 IP 和 PORT, 例如：`create anode 'http://localhost:6050'`。启动 Anode 以后如果不注册到 TDengine 集群中，则无法提供正常的服务。不建议 Anode 注册到两个或多个集群中。
|
||||
node_url 是提供服务的 Anode 的 IP 和 PORT组成的字符串, 例如：`create anode 'http://localhost:6050'`。Anode 启动后还需要注册到 TDengine 集群中才能提供服务。不建议将 Anode 同时注册到两个集群中。
|
||||
|
||||
#### 查看 Anode
|
||||
列出集群中所有的数据分析节点，包括其 `FQDN`, `PORT`, `STATUS`。
|
||||
列出集群中所有的数据分析节点，包括其 `FQDN`, `PORT`, `STATUS`等属性。
|
||||
```sql
|
||||
SHOW ANODES;
|
||||
```
|
||||
|
|
@ -119,4 +123,4 @@ UPDATE ALL ANODES
|
|||
```sql
|
||||
DROP ANODE {anode_id}
|
||||
```
|
||||
删除 Anode 只是将 Anode 从 TDengine 集群中删除，管理 Anode 的启停仍然需要使用`systemctl`命令。
|
||||
删除 Anode 只是将 Anode 从 TDengine 集群中删除，管理 Anode 的启停仍然需要使用 `systemctl` 命令。卸载 Anode 则需要使用上面提到的 `rmtaosanode` 命令。
|
||||
|
|
|
|||
|
|
@ -7,27 +7,43 @@ import activity from './pic/activity.png';
|
|||
import wndata from './pic/white-noise-data.png'
|
||||
|
||||
### 分析流程
|
||||
在针对时序数据进行高级分析之前，首先进行数据的白噪声检查（White Noise Data check, WND）。整体的流程如下图所示。
|
||||
时序数据分析之前需要有预处理的过程，整体的流程如下图所示。
|
||||
|
||||
<img src={activity} width="560" alt="预处理流程" />
|
||||
|
||||
- 对于时间序列数据预测分析，首先进行白噪声检查，不是白噪声数据，进行数据重采样和时间戳对齐的预处理，预处理完成后进行数据预测分析。
|
||||
- 对于时间序列异常检测，首先进行白噪声检查，检查通过以后无后续的处理流程，直接进行异常检测分析。
|
||||
首先对输入数据进行白噪声检查（White Noise Data check）, 检查通过以后针对预测分析，还需要进行输入（历史）数据的重采样和时间戳对齐处理操作，如果是异常检测则跳过数据重采样和时间戳对齐的预处理。
|
||||
预处理完成以后，在进行后续的预测或异常检测操作。
|
||||
|
||||
### 白噪声检查
|
||||
|
||||
<img src={wndata} width="430" alt="white-noise-data"/>
|
||||
|
||||
白噪声时序数据可以简单地认为是随机数构成的时序数据序列（如上图所示），随机数的时间序列没有分析的价值，因此会直接返回空结果。白噪声检查采用 `Ljung-Box` 检验，`Ljung-Box` 统计量的计算过程需遍历整个输入序列。如果用户能够明确输入序列一定不是白噪声序列，那么可以通过增加参数 `wncheck=0` 要求分析平台忽略白噪声输入时间序列检查，从而节省计算资源。
|
||||
白噪声时序数据可以简单地认为是随机数构成的时间数据序列（如上图所示的正态分布随机数序列），随机数构成的时间序列没有分析的价值，因此会直接返回。白噪声检查采用经典的 `Ljung-Box` 统计量检验，计算 `Ljung-Box` 统计量需遍历整个输入时间序列。如果用户能够明确输入序列一定不是白噪声序列，那么可以在参数列表中增加参数 `wncheck=0` 强制要求分析平台忽略白噪声检查，从而节省计算资源。
|
||||
TDgpt 暂不提供独立的时间序列白噪声检测功能。
|
||||
|
||||
|
||||
### 数据重采样和时间戳对齐
|
||||
### 重采样和时间戳对齐
|
||||
|
||||
对于输入的时间序列数据，在对齐进行预测分析之前需要进行必要的预处理流程。预处理解决以下两个方面的问题：
|
||||
对于进行预测分析的时间序列数据，在进行预测分析前需要进行必要的预处理。预处理主要解决以下两个问题：
|
||||
|
||||
- 真实时间序列数据时间戳未对齐。由于数据生成的原因或者网关给时间序列数据赋值时间戳并不能保证按照严格的时间间隔赋值，此时 分析平台会自动将输入数据按照用户指定的采样频率对时间戳进行对齐处理。例如输入时间序列 [11, 22, 29, 41]，用户指定时间间隔为 10，该时间序列的时间戳将被自动重整为以下时间戳序列 [10, 20, 30, 40]。
|
||||
- 数据时间重采样。用户输入时间序列的采样频率超过了输出结果的频率，例如输入时间序列的采样频率是 5，输出结果的频率是 10，输入时间序列 [0， 5， 10， 15， 20， 25， 30] 将被重采用为间隔 为 10 的序列 [0, 10, 20，30]，[5, 15, 25] 处的数据将被丢弃。
|
||||
- 真实时间序列数据时间戳未对齐。由于数据生成设备的原因或网关赋值时间戳的时候并不能保证按照严格的时间间隔赋值，时间序列数据并不能保证是严格按照采样频率对齐。例如采样频率为 1Hz 的一个时间序列数据序列，其时间戳序列如下：
|
||||
|
||||
需要注意的是，数据输入平台不支持缺失数据补齐后进行的预测分析，如果输入时间序列数据 [11, 22, 29, 49]，并且用户要求的时间间隔为 10，重整对齐后的序列是 [10, 20, 30, 50] 那么该序列进行预测分析将返回错误。
|
||||
> ['20:12:21.143', '20:12:22.187', '20:12:23.032', '20:12:24.384', '20:12:25.033']
|
||||
|
||||
预测返回的时间序列时间戳会严格对齐，例如返回后续的两个预测结果的时间戳，其时间一定如下：['20:12:26.000', '20:12:27.000']。因此上述的输入时间戳序列要进行时间戳对齐，变换成为如下时间戳序列
|
||||
|
||||
> ['20:12:21.000', '20:12:22.000', '20:12:23.000', '20:12:24.000', '20:12:25.000']
|
||||
|
||||
|
||||
- 数据时间重采样。用户输入时间序列的采样频率超过了输出结果的频率，例如输入时间序列的采样时间间隔是 5 sec，但是要求输出预测结果的采样时间间隔是 10sec
|
||||
|
||||
> ['20:12:20.000', '20:12:25.000', '20:12:30.000', '20:12:35.000', '20:12:40.000']
|
||||
|
||||
重采样为采样间隔为 10sec 的时间戳序列
|
||||
|
||||
> ['20:12:20.000', '20:12:30.000', '20:12:40.000']
|
||||
|
||||
然后将其作为预测分析的输入， ['20:12:25.000', '20:12:35.000'] 数据被丢弃。
|
||||
|
||||
需要注意的是，预处理过程不支持缺失数据补齐操作，如果输入时间序列数据 ['20:12:10.113', '20:12:21.393', '20:12:29.143', '20:12:51.330']，并且要求的采样时间间隔为 10sec，重整对齐后的时间戳序列是 ['20:12:10.000', '20:12:20.000', '20:12:30.000', '20:12:50.000'] 那么对该序列进行预测分析将返回错误。
|
||||
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@ title: "ARIMA"
|
|||
sidebar_label: "ARIMA"
|
||||
---
|
||||
|
||||
本节讲述 ARIMA 算法模型的使用方法。
|
||||
本节说明 ARIMA 算法模型的使用方法。
|
||||
|
||||
## 功能概述
|
||||
|
||||
ARIMA 即自回归移动平均模型（Autoregressive Integrated Moving Average, ARIMA），也记作 ARIMA(p,d,q)，是统计模型中最常见的一种用来进行时间序列预测的模型。
|
||||
ARIMA：Autoregressive Integrated Moving Average，即自回归移动平均模型，记作 ARIMA(p,d,q)，是统计模型中最常见的一种用来进行时间序列预测的模型。
|
||||
ARIMA 模型是一种自回归模型，只需要自变量即可预测后续的值。ARIMA 模型要求时间序列**平稳**，或经过差分处理后平稳，如果是不平稳的数据，**无法**获得正确的结果。
|
||||
|
||||
>平稳的时间序列：其性质不随观测时间的变化而变化。具有趋势或季节性的时间序列不是平稳时间序列——趋势和季节性使得时间序列在不同时段呈现不同性质。
|
||||
> 平稳的时间序列：其性质不随观测时间的变化而变化。具有趋势或季节性的时间序列不是平稳时间序列——趋势和季节性使得时间序列在不同时段呈现不同性质。
|
||||
|
||||
以下参数可以动态输入，控制预测过程中生成合适的 ARIMA 模型。
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ title: 预测算法
|
|||
description: 预测算法
|
||||
---
|
||||
|
||||
时序数据预测处理以持续一个时间段的时序数据作为输入，预测接下来一个连续时间区间内时间序列数据分布及运行的趋势。用户可以指定输出的（预测）时间序列数据点的数量，因此其输出的结果行数不确定。为此，我们引入了 `FORECAST` 函数提供预测服务。基础数据（用于预测的历史时间序列数据）是该函数的输入，预测结果是该函数的输出。用户可以通过 `FORECAST` 函数调用 Anode 提供的预测算法提供的服务。
|
||||
时序数据预测处理以持续一个时间段的时序数据作为输入，预测接下来一个连续时间区间内时间序列数据趋势。用户可以指定输出的（预测）时间序列数据点的数量，因此其输出的结果行数不确定。为此，TDengine 使用新函数 `FORECAST` 提供时序数据预测服务。基础数据（用于预测的历史时间序列数据）是该函数的输入，预测结果是该函数的输出。用户可以通过 `FORECAST` 函数调用 Anode 提供的预测算法提供的服务。
|
||||
|
||||
##### 语法
|
||||
### 语法
|
||||
```SQL
|
||||
FORECAST(column_expr, option_expr)
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ algo=expr1
|
|||
1. `column_expr`：预测的时序数据列。与异常检测相同，只支持数值类型列输入。
|
||||
2. `options`：异常检测函数的参数，使用规则与 anomaly_window 相同。预测支持 `conf`, `every`, `rows`, `start`, `rows` 几个控制参数，其含义如下：
|
||||
|
||||
**参数说明**
|
||||
### 参数说明
|
||||
|
||||
|参数|含义|默认值|
|
||||
|---|---|---|
|
||||
|
|
@ -31,7 +31,7 @@ algo=expr1
|
|||
|wncheck|白噪声（white noise data）检查|默认值为 1，0 表示不进行检查|
|
||||
|conf|预测数据的置信区间范围 ，取值范围 [0, 100]|95|
|
||||
|every|预测数据的采样间隔|输入数据的采样间隔|
|
||||
|start|预测结果的开始时间戳|输入数据最后一个时间戳加上一个采样时间段|
|
||||
|start|预测结果的开始时间戳|输入数据最后一个时间戳加上一个采样间隔时间区间|
|
||||
|rows|预测结果的记录数|10|
|
||||
|
||||
1. 预测查询结果新增三个伪列，具体如下：`_FROWTS`：预测结果的时间戳、`_FLOW`：置信区间下界、`_FHIGH`：置信区间上界, 对于没有置信区间的预测算法，其置信区间同预测结果
|
||||
|
|
@ -39,15 +39,15 @@ algo=expr1
|
|||
3. `EVERY`：可以与输入数据的采样频率不同。采样频率只能低于或等于输入数据采样频率，不能**高于**输入数据的采样频率。
|
||||
4. 对于某些不需要计算置信区间的算法，即使指定了置信区间，返回的结果中其上下界退化成为一个点。
|
||||
|
||||
**示例**
|
||||
### 示例
|
||||
|
||||
```SQL
|
||||
--- 使用 arima 算法进行预测，预测结果是 10 条记录（默认值），数据进行白噪声检查，默认置信区间 95%.
|
||||
SELECT _flow, _fhigh, _frowts, FORECAST(i32, "algo=arima")
|
||||
FROM foo;
|
||||
|
||||
--- 使用 arima 算法进行预测，输入数据的是周期数据，每 10 个采样点是一个周期。返回置信区间是 95%.
|
||||
SELECT _flow, _fhigh, _frowts, FORECAST(i32, "algo=arima,alpha=95,period=10")
|
||||
--- 使用 arima 算法进行预测，输入数据的是周期数据，每 10 个采样点是一个周期，返回置信区间是95%的上下边界，同时忽略白噪声检查
|
||||
SELECT _flow, _fhigh, _frowts, FORECAST(i32, "algo=arima,alpha=95,period=10,wncheck=0")
|
||||
FROM foo;
|
||||
```
|
||||
```
|
||||
|
|
@ -67,6 +67,6 @@ taos> select _flow, _fhigh, _frowts, forecast(i32) from foo;
|
|||
```
|
||||
|
||||
|
||||
**可用预测算法**
|
||||
## 内置预测算法
|
||||
- arima
|
||||
- holtwinters
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ title: "异常检测算法"
|
|||
sidebar_label: "异常检测算法"
|
||||
---
|
||||
|
||||
本节讲述异常检测算法模型的使用方法。
|
||||
本节介绍内置异常检测算法模型的定义和使用方法。
|
||||
|
||||
## 概述
|
||||
分析平台提供了 6 种异常检查模型，6 种异常检查模型分为 3 个类别，分别属于基于统计的异常检测模型、基于数据密度的检测模型、基于深度学习的异常检测模型。在不指定异常检测使用的方法的情况下，默认调用 iqr 的方法进行计算。
|
||||
分析平台内置了6个异常检查模型，分为3个类别，分别是基于统计学的模型、基于数据密度的模型、以及基于深度学习的模型。在不指定异常检测使用的方法的情况下，默认调用 iqr 进行异常检测。
|
||||
|
||||
|
||||
### 统计学异常检测方法
|
||||
|
|
|
|||
|
|
@ -5,12 +5,13 @@ description: 异常检测算法
|
|||
|
||||
import ad from '../pic/anomaly-detection.png';
|
||||
|
||||
时序数据异常检测，在TDengine 查询处理中以异常窗口的形式服务。因此，可以将异常检测获得的窗口视为一种特殊的**事件窗口**，区别在于异常窗口的触发条件和结束条件不是用户指定，而是检测算法自动识别。因此，可以应用在事件窗口上的函数均可应用在异常窗口中。由于异常检测结果是一个时间窗口，因此调用异常检测的方式也与使用事件窗口的方式相同，在 `WHERE` 子句中使用 `ANOMALY_WINDOW` 关键词即可调用时序数据异常检测服务，同时窗口伪列（`_WSTART`, `_WEND`, `_WDURATION`）也能够像其他窗口函数一样使用。例如：
|
||||
TDengine 中定义了异常（状态）窗口来提供异常检测服务。异常窗口可以视为一种特殊的**事件窗口（Event Window）**，即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于——时间窗口的起始时间和结束时间均是分析算法识别确定，不是用户给定的表达式进行判定。因此，在 `WHERE` 子句中使用 `ANOMALY_WINDOW` 关键词即可调用时序数据异常检测服务，同时窗口伪列（`_WSTART`, `_WEND`, `_WDURATION`）也能够像其他时间窗口一样用于描述异常窗口的起始时间(`_WSTART`)、结束时间(`_WEND`)、持续时间(`_WDURATION`)。例如：
|
||||
|
||||
```SQL
|
||||
SELECT _wstart, _wend, SUM(i32)
|
||||
--- 使用异常检测算法 IQR 对输入列 col_val 进行异常检测。同时输出异常窗口的起始时间、结束时间、以及异常窗口内 col 列的和。
|
||||
SELECT _wstart, _wend, SUM(col)
|
||||
FROM foo
|
||||
ANOMALY_WINDOW(i32, "algo=iqr");
|
||||
ANOMALY_WINDOW(col_val, "algo=iqr");
|
||||
```
|
||||
|
||||
如下图所示，Anode 将返回时序数据异常窗口 $[10:51:30, 10:53:40]$
|
||||
|
|
@ -36,18 +37,14 @@ algo=expr1
|
|||
3. 异常检测的结果可以作为外层查询的子查询输入，在 `SELECT` 子句中使用的聚合函数或标量函数与其他类型的窗口查询相同。
|
||||
4. 输入数据默认进行白噪声检查，如果输入数据是白噪声，将不会有任何（异常）窗口信息返回。
|
||||
|
||||
**参数说明**
|
||||
### 参数说明
|
||||
|参数|含义|默认值|
|
||||
|---|---|---|
|
||||
|algo|异常检测调用的算法|iqr|
|
||||
|wncheck|对输入数据列是否进行白噪声检查|取值为 0 或者 1，默认值为 1，表示进行白噪声检查|
|
||||
|wncheck|对输入数据列是否进行白噪声检查，取值为0或1|1|
|
||||
|
||||
异常检测的返回结果以窗口形式呈现，因此窗口查询相关的伪列在这种场景下仍然可用。可用的伪列如下：
|
||||
1. `_WSTART`： 异常窗口开始时间戳
|
||||
2. `_WEND`：异常窗口结束时间戳
|
||||
3. `_WDURATION`：异常窗口持续时间
|
||||
|
||||
**示例**
|
||||
### 示例
|
||||
```SQL
|
||||
--- 使用 iqr 算法进行异常检测，检测列 i32 列。
|
||||
SELECT _wstart, _wend, SUM(i32)
|
||||
|
|
@ -58,9 +55,7 @@ ANOMALY_WINDOW(i32, "algo=iqr");
|
|||
SELECT _wstart, _wend, SUM(i32)
|
||||
FROM foo
|
||||
ANOMALY_WINDOW(i32, "algo=ksigma,k=2");
|
||||
```
|
||||
|
||||
```
|
||||
taos> SELECT _wstart, _wend, count(*) FROM ai.atb ANOMAYL_WINDOW(i32);
|
||||
_wstart | _wend | count(*) |
|
||||
====================================================================
|
||||
|
|
@ -69,7 +64,7 @@ Query OK, 1 row(s) in set (0.028946s)
|
|||
```
|
||||
|
||||
|
||||
**可用异常检测算法**
|
||||
### 内置异常检测算法
|
||||
- iqr
|
||||
- ksigma
|
||||
- grubbs
|
||||
|
|
|
|||
|
|
@ -2,14 +2,20 @@
|
|||
title: "算法开发者指南"
|
||||
sidebar_label: "算法开发者指南"
|
||||
---
|
||||
TDgpt 是一个可扩展的时序数据高级分析平台，用户仅按照简易的步骤就能将新分析算法添加到分析平台中。将开发完成的算法代码文件放入对应的目录文件夹，然后重启 Anode 即可完成扩展升级。Anode 启动后会自动加载特定目录的分析算法。用户可以直接使用 SQL 语句调用添加到 TDgpt 系统中的分析算法。得益于 TDgpt 与 taosd 的松散耦合关系，分析平台升级对 taosd 完全没有影响。应用系统也不需要做任何更改就能够完成分析功能和分析算法的升级。
|
||||
TDgpt 是一个可扩展的时序数据高级分析平台，用户遵循简易的步骤就能将自己开发的分析算法添加到分析平台并通过SQL语句直接调用。目前 TDpgt 平台只支持使用 Python 语言开发的分析算法。
|
||||
Anode 采用类动态加载模式，在启动的时候扫描特定目录内满足约定条件的所有代码文件，并将其加载到系统中。因此，开发者只需要遵循以下几步就能完成新算法的添加工作：
|
||||
1. 开发完成符合要求的分析算法类
|
||||
2. 将代码文件放入对应目录，然后重启 Anode
|
||||
3. 使用SQL命令，向 Mnode 同步新的算法列表
|
||||
|
||||
这种方式能够按需扩展新分析算法，极大地拓展了 TDgpt 适应的范围，用户可以将契合业务场景开发的（预测、异常检测）分析算法嵌入到 TDgpt，并通过 SQL 语句进行调用。在不更改或更改非常少的应用系统代码的前提下，就能够快速完成分析功能的平滑升级。
|
||||
此时就完成了新算法的添加工作，之后就可以直接使用SQL语句调用新算法。得益于 TDgpt 与 TDengine主进程 `taosd` 的松散耦合，Anode算法升级对 `taosd` 完全没有影响。应用系统只需要调整对应的SQL语句调用新（升级的）算法，就能够快速完成分析功能和分析算法的升级。
|
||||
|
||||
本节说明如何将预测算法和异常检测算法添加到 TDengine 分析平台。
|
||||
这种方式能够按需扩展分析算法，极大地拓展 TDgpt 的适应范围，用户可以按需将更契合业务场景的、更准确的（预测、异常检测）分析算法动态嵌入到 TDgpt，并通过 SQL 语句进行调用。在基本不用更改应用系统代码的前提下，就能够快速完成分析功能的平滑升级。
|
||||
|
||||
以下内容将说明如何将分析算法添加到 Anode 中并能够通过SQL语句进行调用。
|
||||
|
||||
## 目录结构
|
||||
首先需要了解TDgpt的目录结构。其主体目录结构如下图：
|
||||
Anode的主要目录结构如下图所示
|
||||
|
||||
```bash
|
||||
.
|
||||
|
|
@ -42,7 +48,7 @@ TDgpt 是一个可扩展的时序数据高级分析平台，用户仅按照简
|
|||
|
||||
### 类命名规范
|
||||
|
||||
由于算法采用自动加载，因此其只识别按照特定命名方式的类。算法类的名称需要以下划线开始，以 Service 结尾。例如：`_KsigmaService` 是 KSigma 异常检测算法类。
|
||||
Anode采用算法自动加载模式，因此只识别符合命名约定的 Python 类。需要加载的算法类名称需要以下划线 `_` 开始并以 `Service` 结尾。例如：`_KsigmaService` 是 KSigma 异常检测算法类。
|
||||
|
||||
### 类继承约定
|
||||
|
||||
|
|
@ -50,21 +56,20 @@ TDgpt 是一个可扩展的时序数据高级分析平台，用户仅按照简
|
|||
- 预测算法需要从 `AbstractForecastService` 继承，同样需要实现其核心抽象方法 `execute`
|
||||
|
||||
### 类属性初始化
|
||||
每个算法实现的类需要静态初始化两个类属性，分别是：
|
||||
实现的类需要初始化以下两个类属性：
|
||||
|
||||
- `name`：触发调用的关键词，全小写英文字母。该名称也是通过 `SHOW` 命令查看可用分析算法是显示的名称。
|
||||
- `desc`：算法的描述信息
|
||||
- `name`：识别该算法的关键词，全小写英文字母。通过 `SHOW` 命令查看可用算法显示的名称即为该名称。
|
||||
- `desc`：算法的基础描述信息
|
||||
|
||||
```SQL
|
||||
--- algo 后面的参数 algo_name 即为类名称 `name`
|
||||
SELECT COUNT(*) FROM foo ANOMALY_DETECTION(col_name, 'algo=algo_name')
|
||||
--- algo 后面的参数 name 即为类属性 `name`
|
||||
SELECT COUNT(*) FROM foo ANOMALY_DETECTION(col_name, 'algo=name')
|
||||
```
|
||||
|
||||
## 添加具有训练模型的分析算法
|
||||
## 添加具有模型的分析算法
|
||||
|
||||
某些深度学习的分析算法需要使用输入时间序列数据进行训练，然后生成针对训练数据集的分析模型。这种情况下，同一个分析算法对应不同的输入数据集有不同的分析模型。
|
||||
这种类型的分析算法要添加到 TDgpt 中，首先需要在 `model` 目录中建立目录，将采用该算法针对不同的输入时间序列数据生成的训练模型均保存在该目录下。如下图所示，针对不同的数据集，采用自编码器训练的数据异常检测算法生成的模型均保存在该目录下。为了确保模型能够正常读取加载，要求存储的模型使用`joblib`库进行序列化保存。
|
||||
采用训练-保存模型的方式可以一次训练，多次调用的优势。避免动态训练调用所带来的反复训练开销。
|
||||
基于统计学的分析算法可以直接针对输入时间序列数据进行分析，整体分析流程比较快捷，但是某些深度学习算法对于输入数据的训练需要较长的时间，并且形成相应的模型。这种情况下，同一个分析算法对应不同的输入数据集有不同的分析模型。
|
||||
将具有模型的分析算法添加到 Anode 中，首先需要在 `model` 目录中建立该算法对应的目录（目录名称可自拟），将采用该算法针对不同的输入时间序列数据生成的训练模型均需要保存在该目录下，同时目录结构要在分析算法中确定，以便能够固定加载该目录下的分析模型。如下图所示，针对不同的数据集，采用自编码器（Autoencoder）训练的数据异常检测算法模型均保存在该目录下。为了确保模型能够正常读取加载，要求存储的模型使用`joblib`库进行序列化保存。
|
||||
|
||||
调用已经保存的模型，需要首先调用`set_params`方法，并在参数中指定调用模型的名称 `{"model": "ad_encoder_keras"}` 即可调用该模型进行计算。调用方式如下：
|
||||
|
||||
|
|
|
|||
|
|
@ -6,17 +6,17 @@ title: TDgpt
|
|||
import TDgpt from './pic/data-analysis.png';
|
||||
|
||||
|
||||
TDgpt 是 TDengine Enterprise 中针对时序数据提供高级分析功能的企业级组件，能够独立于 TDengine 主进程部署和运行，不消耗和占用 TDengine 主进程的资源，通过内置接口向 TDengine 提供运行时动态扩展的高级时序数据分析功能。TDgpt 具有服务无状态、功能易扩展、快速弹性部署、应用轻量化、高安全性等特点。
|
||||
TDgpt 运行在部署于 TDengine 集群中的 AI Node (Anode)中。每个 TDengine 集群中可以部署一个或若干个 Anode 节点，不同的 Anode 节点之间不相关，无同步或协同的要求。Anode 注册到 TDengine 集群以后，就可以通过内部接口提供服务。TDgpt 提供的高级时序数据分析服务可分为时序数据异常检测和时序数据预测分析两个类别。
|
||||
TDgpt 是 TDengine Enterprise 中针对时序数据提供高级分析功能的企业级组件，通过内置接口向 TDengine 提供运行时动态扩展的时序数据分析服务。TDgpt 能够独立于 TDengine 主进程部署和运行，因此可避免消耗占用 TDengine 集群的主进程资源。
|
||||
TDgpt 具有服务无状态、功能易扩展、快速弹性部署、应用轻量化、高安全性等优势。
|
||||
TDgpt 运行在集群中的 AI Node (Anode)中，集群中可以部署若干个 Anode 节点，不同的 Anode 节点之间无同步依赖或协同的要求。Anode 注册到 TDengine 集群以后，立即就可以提供服务。TDgpt 提供的高级时序数据分析服务可分为时序数据异常检测和时序数据预测分析两大类。
|
||||
|
||||
下图是部署 TDgpt 的 TDengine 集群示意图。
|
||||
<img src={TDgpt} width="560" alt="TDgpt架构图" />
|
||||
|
||||
通过注册指令将 Anode 注册到 Mnode 中以后，就加入到 TDengine 集群，并可被查询引擎动态调用执行。在查询处理过程中，查询引擎根据生成的物理执行计划，**按需**向 Anode 请求高级时序数据分析服务。用户可通过SQL语句与 Anode 节点交互，并使用其提供的全部分析服务。需要注意的是 Anode 不直接接受用户的数据分析请求。同时 Anode 提供高效的动态注册机制，其注册和卸载过程完全不影响 TDengine 集群的服务，只影响提供对应的查询服务能力。
|
||||
在查询处理过程中，Vnode中运行的查询引擎会根据查询处理物理执行计划，按需向 Anode 请求高级时序数据分析服务。因此用户可通过 SQL 语句与 Anode 节点交互并使用其提供的全部分析服务。需要注意的是 Anode 不直接接受用户的数据分析请求。同时 Anode 具备分析算法动态注册机制，其算法扩展过程完全不影响 TDengine 集群的服务，仅在非常小的（秒级）时间窗口内影响涉及高级分析的查询服务。
|
||||
|
||||
TDgpt 提供的高级数据分析功能分为时序数据异常检测和时序数据预测。
|
||||
- 时序数据异常检测的结果采用异常窗口的形式提供，即分析系统自动将算法检测到的连续异常数据以时间窗口的形式返回，其使用方式与 TDengine 中其他类型的时间窗口（例如状态窗口、事件窗口）类似。特别地，可以将异常数据窗口视作为一种特殊的**事件窗口（Event Window）**，因此状态窗口可使用的所有查询操作均可应用在异常窗口上。
|
||||
- 时序数据预测是基于输入的时间序列数据，使用指定（或默认）预测算法给出输入时序数据后续时间序列的**预测**观测值数据。因此，不同于异常检测是以窗口的形式存在，时序数据预测在 TDengine 中是一个（不确定输出）函数。
|
||||
- 时序数据异常检测。TDengine 中定义了新的时间窗口——异常（状态）窗口——来提供异常检测服务。异常窗口可以视为一种特殊的**事件窗口（Event Window）**，即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于——时间窗口的起始时间和结束时间均是分析算法确定，不是用户指定的表达式判定。异常窗口使用方式与其他类型的时间窗口（例如状态窗口、会话窗口等）类似。因此时间窗口内可使用的查询操作均可应用在异常窗口上。
|
||||
- 时序数据预测。定义了一个新函数`FORECAST`，基于输入的（历史）时间序列数据调用指定（或默认）预测算法给出输入时序数据后续时间序列的**预测**数据。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue