docs: revise the document directory structure (#30472)
This commit is contained in:
Simon Guan
GitHub
parent
e7c19ca217
commit
306dbbb939
|
|
@ -79,11 +79,11 @@ TDengine 采用“一个数据采集点一张表”的设计虽然有利于高
|
|||
|
||||
### 虚拟表
|
||||
|
||||
“一个数据采集点一张表”以及“超级表”的设计解决了工业和物联网等场景下的大多数时序数据管理和分析难题。但是在真实的场景中，一个设备往往有多种传感器，而且他们的数据采集频次还相差很大。比如对于一台风机，有电的参数、环境参数、机械参数，各自的传感器和采集频次完全不一样。因此我们很难用一张表来描述一台设备，往往需要多张表。当需要综合多个传感器的数据进行分析计算时，只能通过多级关联查询的方式来进行，而这往往会导致易用性和性能方面的问题。而从用户的角度来看，“一个设备一张表”更为直观，容易操作。但如果我们建模之初，直接采用"一个设备一张表的“的设计，由于采集频次的不同，会导致每一个具体时间戳，大量的列是空值，从而降低存储和查询的效率。
|
||||
“一个数据采集点一张表”以及“超级表”的设计解决了工业和物联网等场景下的大多数时序数据管理和分析难题。但在真实的场景中，一个设备往往有多种传感器，数据采集频次还相差很大。比如对于一台风机，电气参数、环境参数、机械参数，各自的传感器和采集频次完全不一样。因此很难用一张表来描述一台设备，往往需要多张表。当需要综合多个传感器的数据进行分析计算时，只能通过多级关联查询的方式来进行，而这往往会导致易用性和性能方面的问题。从用户的角度来看，“一个设备一张表”更为直观、容易操作。但如果建模之初，直接采用“一个设备一张表的”的设计，由于采集频次的不同，会导致每一个具体时间戳，大量的列是空值，降低存储和查询的效率。
|
||||
|
||||
为了解决这个问题，TDengine 引入虚拟表（Virtual Table，简称为 VTable）的概念。虚拟表是一种不存储实际数据而可以用于分析计算的表，它的数据来源为其它真实存储数据的子表、普通表，通过将各个原始表的不同列的数据按照时间戳排序、对齐、合并的方式来生成虚拟表。同真实表类似，虚拟表也可以分为虚拟超级表、虚拟子表、虚拟普通表。虚拟超级表可以是一个设备或一组分析计算所需数据的完整集合，每个虚拟子表可以根据需要引用相同或不同的列，因此可以灵活地根据业务需要进行定义，最终达到“千人千面”的效果。虚拟表不能写入、删除数据，在查询使用上同真实表相同。TDengine 支持虚拟超级表、虚拟子表、虚拟普通表上的任何查询。唯一的区别在于虚拟表的数据是每次查询计算时动态生成的，只有一个查询中引用的列才会被合并进虚拟表中，因此同一个虚拟表在不同的查询中所呈现以及扫描的数据可能是完全不同的。
|
||||
为了解决这个问题，TDengine 引入虚拟表（Virtual Table，简称为 VTable）的概念。虚拟表是一种不存储实际数据而可以用于分析计算的表，数据来源为其它真实存储数据的子表、普通表，通过将各个原始表的不同列的数据按照时间戳排序、对齐、合并的方式来生成虚拟表。同真实表类似，虚拟表也可以分为虚拟超级表、虚拟子表、虚拟普通表。虚拟超级表可以是一个设备或一组分析计算所需数据的完整集合，每个虚拟子表可以根据需要引用相同或不同的列，因此可以灵活地根据业务需要进行定义，最终达到“千人千面”的效果。虚拟表不能写入、删除数据，在查询使用上和真实表相同。TDengine 支持虚拟超级表、虚拟子表、虚拟普通表上的任何查询。唯一的区别在于虚拟表的数据是每次查询计算时动态生成的，只有一个查询中引用的列才会被合并进虚拟表中，因此同一个虚拟表在不同的查询中所呈现以及扫描的数据可能是完全不同的。
|
||||
|
||||
虚拟超级表的主要功能特点包括：
|
||||
虚拟超级表的主要功能特点包括。
|
||||
1. 列选择与拼接：用户可以从多个原始表中选择指定的列，按需组合到一张虚拟表中，形成统一的数据视图。
|
||||
2. 基于时间戳对齐：以时间戳为依据对数据进行对齐，如果多个表在相同时间戳下存在数据，则对应列的值组合成同一行；若部分表在该时间戳下无数据，则对应列填充为 NULL。
|
||||
3. 动态更新：虚拟表根据原始表的数据变化自动更新，确保数据的实时性。虚拟表不需实际存储，计算在生成时动态完成。
|
||||
|
|
|
|||
|
|
@ -10,12 +10,10 @@ import TDgpt from './pic/data-analysis.png';
|
|||
|
||||
分析算法通常以高级编程语言（Python 语言或 R 语言）工具包的形式存在，并通过开源的方式广泛分发和使用，这种应用模式极大地便利了软件开发人员在应用系统中调用复杂的分析算法，极大地降低了使用高级算法的门槛。
|
||||
|
||||
|
||||
另一方面，数据库系统研发人员也尝试将数据分析算法模型整合到数据库系统中，通过建立 Machine Learning 库（例如 Spark 的机器学习库）充分利用成熟分析技术增强数据库或分析计算引擎的高级数据分析能力。
|
||||
另一方面，数据库系统研发人员也尝试将数据分析算法模型整合到数据库系统中，通过建立 Machine Learning 库（例如 Spark 的机器学习库），充分利用成熟分析技术增强数据库或分析计算引擎的高级数据分析能力。
|
||||
|
||||
飞速发展的人工智能（AI）为时序数据分析应用带来了新的机遇，而如何快速高效地将 AI 能力应用于时间序列数据分析，也对数据库系统提出了新的挑战。为此，涛思数据创新性地提出了时序数据分析智能体 TDgpt，使用 TDgpt，将您能够通过 SQL 语句，直接调用适配和整合驱动统计分析算法、机器学习算法模型、深度学习模型，时序数据基础模型以及大语言模型，并将这些分析能力转化为 SQL 语句的调用，通过异常检测窗口和预测函数的方式应用在时序数据上。
|
||||
|
||||
|
||||
# 技术特点
|
||||
TDgpt 是与 TDengine 主进程 taosd 适配的外置式时序数据分析智能体，能够将时序数据分析服务无缝集成在 TDengine 的查询执行流程中。
|
||||
TDgpt 是一个无状态的平台，其内置了经典的统计分析模型库 Statsmodel，内嵌了 torch/Keras 等机器/深度学习框架库，此外还通过请求转发和适配的方式直接调用涛思数据自研的时序数据基础大模型 TDtsfm (TDengine time series foundation model)。
|
||||
|
|
@ -25,51 +23,51 @@ TDgpt 是一个开放的系统，用户能够根据自己的需要，添加预
|
|||
无需应用修改一行代码。
|
||||
|
||||
# 系统架构
|
||||
TDgpt 由若干个无状态的分析节点 anode 构成，可以按需在系统集群中部署 Anode 节点，也可以根据分析模型算法的特点，将 Anode 部署在合适的硬件环境中，例如带有 GPU 的计算节点。
|
||||
TDgpt 由若干个无状态的分析节点 Anode 构成，可以按需在系统集群中部署 Anode 节点，也可以根据分析模型算法的特点，将 Anode 部署在合适的硬件环境中，例如带有 GPU 的计算节点。
|
||||
TDgpt 针对不同的分析算法，提供统一的调用接口和调用方式，根据用户请求的参数，调用高级分析算法包及其他的分析工具，并将分析获得的结果按照约定的方式返回给 TDengine 的主进程 taosd。
|
||||
TDgpt 的主要包含四个部分的内容。
|
||||
- 第一部分是内置分析库，包括 statsmodels, pyculiarity, pmdarima 等，提供可以直接调用的预测分析和异常检测算法模型。
|
||||
- 第二部分是内置的机器学习库（包括：torch,keras,scikit-learn等），用于驱动预训练完成的机器（深度）学习模型在 TDgpt 的进程空间内运行。预训练的流程可以使用 Merlion/Kats 等 开源的端到端机器学习框架进行管理，并将完成训练的模型上传到 TDgpt 指定目录即可;
|
||||
- 第三部分是通用大语言模型的请求适配模块。将时序数据预测请求转换后，基于 Prompt 向 DeepSeek、LlaMa 等通用大语言模型 MaaS 请求服务（这部分功能暂未开源）；
|
||||
- 第二部分是内置的机器学习库（包括：torch、keras、scikit-learn等），用于驱动预训练完成的机器（深度）学习模型在 TDgpt 的进程空间内运行。预训练的流程可以使用 Merlion/Kats 等 开源的端到端机器学习框架进行管理，并将完成训练的模型上传到 TDgpt 指定目录即可。
|
||||
- 第三部分是通用大语言模型的请求适配模块。将时序数据预测请求转换后，基于 Prompt 向 DeepSeek、LlaMa 等通用大语言模型 MaaS 请求服务（这部分功能暂未开源）。
|
||||
- 第四部分是通过 Adapter 直接向本地部署的 Time-MoE、TDtsfm 等时序数据模型请求服务。时序数据专用模型相对于通用语言大模型，无需 Prompt，更加便捷轻量，本地应用部署对硬件资源要求也较低；除此之外，Adapter 还可以直接请求 TimeGPT 这种类型的时序数据分析 MaaS 服务，调用云端的时序模型服务提供本地化时序数据分析能力。
|
||||
|
||||
<figure style={{textAlign: "center"}}>
|
||||
<img src={TDgpt} alt="TDgpt架构图" />
|
||||
</figure>
|
||||
|
||||
查询过程中，TDengine 中的Vnode 会将涉及时序数据高级分析的部分直接转发到 Anode，并等待分析完成后将结果组装完成，嵌入查询执行流程。
|
||||
查询过程中，TDengine 中的 Vnode 会将涉及时序数据高级分析的部分直接转发到 Anode，并等待分析完成后将结果组装完成，嵌入查询执行流程。
|
||||
|
||||
# 时序数据分析服务
|
||||
|
||||
使用TDgpt 提供的时序数据分析服务，包括：
|
||||
- 时序数据异常检测：TDengine 中定义了新的时间窗口——异常（状态）窗口——来提供异常检测服务。异常窗口可以视为一种特殊的事件窗口（Event Window），即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于——时间窗口的起始时间和结束时间均是分析算法确定，不是用户指定的表达式判定。异常窗口使用方式与其他类型的时间窗口（例如状态窗口、会话窗口等）类似。因此时间窗口内可使用的查询操作均可应用在异常窗口上。
|
||||
- 时序数据分析预测：TDengine 中提供了一个新的函数FORECAST提供时序数据预测服务，基于输入的（历史）时间序列数据调用指定（或默认）预测算法给出输入时序数据后续时间序列的预测数据。
|
||||
- 时序数据异常检测：TDengine 中定义了新的时间窗口 **异常（状态）窗口** 来提供异常检测服务。异常窗口可以视为一种特殊的事件窗口（Event Window），即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于，时间窗口的起始时间和结束时间均是分析算法确定，不是用户指定的表达式判定。异常窗口使用方式与其他类型的时间窗口（例如状态窗口、会话窗口等）类似。因此时间窗口内可使用的查询操作均可应用在异常窗口上。
|
||||
- 时序数据分析预测：TDengine 中提供了一个新的函数 FORECAST 提供时序数据预测服务，基于输入的（历史）时间序列数据调用指定（或默认）预测算法给出输入时序数据后续时间序列的预测数据。
|
||||
- 时序数据补全：研发测试中，2025 年 7 月发布
|
||||
- 时序数据分类：研发测试中，2025 年 7 月发布
|
||||
|
||||
# 自定义分析算法
|
||||
|
||||
TDgpt 是一个可扩展的时序数据高级分析智能体，用户遵循 [算法开发者指南](./dev)中的简易步骤就能将自己开发的分析算法添加到系统中。之后应用可以通过 SQL 语句直接调用, 让高级分析算法的使用门槛降到几乎为零。对于新引入的算法或模型，应用不用做任何调整。
|
||||
TDgpt 是一个可扩展的时序数据高级分析智能体，用户遵循 [算法开发者指南](./09-dev) 中的简易步骤就能将自己开发的分析算法添加到系统中。之后应用可以通过 SQL 语句直接调用, 让高级分析算法的使用门槛降到几乎为零。对于新引入的算法或模型，应用不用做任何调整。
|
||||
|
||||
TDpgt 只支持使用 Python 语言开发的分析算法。Anode 采用 Python 类动态加载模式，在启动的时候扫描特定目录内满足约定条件的所有代码文件，并将其加载到系统中。因此，开发者只需要遵循以下几步就能完成新算法的添加工作：
|
||||
1. 开发完成符合要求的分析算法类
|
||||
2. 将代码文件放入对应目录，然后重启 Anode
|
||||
3. 使用SQL命令更新算法缓存列表即可。
|
||||
TDpgt 只支持使用 Python 语言开发的分析算法。Anode 采用 Python 类动态加载模式，在启动的时候扫描特定目录内满足约定条件的所有代码文件，并将其加载到系统中。因此，开发者只需要遵循以下几步就能完成新算法的添加工作。
|
||||
1. 开发完成符合要求的分析算法类。
|
||||
2. 将代码文件放入对应目录，然后重启 Anode。
|
||||
3. 使用 SQL 命令更新算法缓存列表即可。
|
||||
添加完成的算法在刷新算法列表后，立即使用 SQL 语句进行调用。
|
||||
|
||||
# 算法评估工具
|
||||
|
||||
在 TDgpt 企业版中，还提供针对多种算法模型有效性的综合评估工具。该工具可以针对 TDgpt 可调用所有时序数据分析（预测分析与异常检测）服务，包括内置数据分析算法模型，已部署的预训练机器学习模型、第三方时序数据（大）模型服务，基于 TDengine 中的时序数据进行预测分析对比和异常检测对比评估，并给出量化指标评估不同分析模型在给定数据集上准确度及性能。
|
||||
在 TDgpt 企业版中，提供针对多种算法模型有效性的综合评估工具。该工具可以针对 TDgpt 可调用所有时序数据分析（预测分析与异常检测）服务，包括内置数据分析算法模型，已部署的预训练机器学习模型、第三方时序数据（大）模型服务，基于 TDengine 中的时序数据进行预测分析对比和异常检测对比评估，并给出量化指标评估不同分析模型在给定数据集上准确度及性能。
|
||||
|
||||
# 模型管理
|
||||
|
||||
对于 Torch/Tensorflow/Keras 等机器学习库框架驱动的预训练模型，需要首先将训练完成的数据模型添加到 Anode 的指定目录中，Anode 可以自动调用该目录内的模型，驱动其运行并提供服务。
|
||||
对于 Torch、Tensorflow、Keras 等机器学习库框架驱动的预训练模型，需要首先将训练完成的数据模型添加到 Anode 的指定目录中，Anode 可以自动调用该目录内的模型，驱动其运行并提供服务。
|
||||
企业版本的 TDgpt 具备模型的管理能力，能够与开源的端到端时序数据机器学习框架（例如：Merlion、Kats 等）无缝集成。
|
||||
|
||||
# 处理能力
|
||||
|
||||
通常意义上，时间序列数据分析主要是计算密集型任务。这种计算密集型任务，可以使用更高性能的 CPU 或 GPU 来提升处理性能。
|
||||
如果是机器/深度学习模型，依赖于 torch 库驱动其运行，可以采用标准的提升分析处理能力的方案来提升 TDgpt 的服务能力，例如将 Anode 部署在内存更大，并具有 GPU 的服务器之上，使用可调用 GPU 的 torch 库驱动模型运行，以提升分析响应能力。
|
||||
通常意义上，时间序列数据分析主要是计算密集型任务。这种计算密集型任务，可以使用更高性能的 CPU 或 GPU 来提升处理性能。
|
||||
如果是机器/深度学习模型，依赖于 torch 库驱动其运行，可以采用标准的提升分析处理能力的方案来提升 TDgpt 的服务能力，例如将 Anode 部署在内存更大并具有 GPU 的服务器之上，使用可调用 GPU 的 torch 库驱动模型运行，以提升分析响应能力。
|
||||
不同的模型、算法可以部署在不同的 Anode 上，增加并行的处理能力。
|
||||
|
||||
# 运营维护
|
||||
|
|
|
|||
|
|
@ -80,19 +80,19 @@ docker exec -it <container name> bash
|
|||
|
||||
## 注册云服务使用 TDgpt
|
||||
|
||||
TDgpt 可以在 TDengine Cloud 上进行快速体验。如果您已经有云服务账号，请在数据库集市里面找到“时序数据预测分析数据集”数据库，点击启用就可以进入这个数据库，然后按照 TDgpt 的 SQL 操作手册来执行语句，比如 `select forecast(val, 'algo=tdtsfm_1') from forecast.electricity_demand;`。
|
||||
TDgpt 可以在 TDengine Cloud 上进行快速体验。如果您已经有云服务账号，请在数据库集市里面找到 **时序数据预测分析数据集** 数据库，点击启用就可以进入这个数据库。然后按照 TDgpt 的 SQL 操作手册来执行语句，比如 `select forecast(val, 'algo=tdtsfm_1') from forecast.electricity_demand;`。
|
||||
|
||||
## 通过安装包部署 TDgpt
|
||||
|
||||
### 环境准备
|
||||
|
||||
使用 TDgpt 的高级时序数据分析功能需要在 TDengine 集群中安装部署Taos AI node（Anode）。Anode 运行在 Linux 平台上, 对部署 Anode 的有一定的环境要求：
|
||||
使用 TDgpt 的高级时序数据分析功能需要在 TDengine 集群中安装部署 Taos AI node（Anode）。Anode 运行在 Linux 平台上, 对部署 Anode 的有一定的环境要求：
|
||||
|
||||
> Python: 3.10 或以上版本
|
||||
> TDengine：需使用 3.3.6.0 或以上版本。
|
||||
> C 编译器：因依赖 uWSGI，部署环境需包含 C 编译器。
|
||||
- Python: 3.10 或以上版本。
|
||||
- TDengine：需使用 3.3.6.0 或以上版本。
|
||||
- C 编译器：因依赖 uWSGI，部署环境需包含 C 编译器。
|
||||
|
||||
可以使用以下的命令在 Ubuntu Linux 上安装 Python 3.10 环境，如果您的系统环境中已经有 Python 3.10，请跳过本节，直接查看[获取安装包](#获取安装包) 部分。
|
||||
可以使用以下的命令在 Ubuntu Linux 上安装 Python 3.10 环境，如果您的系统环境中已经有 Python 3.10，请跳过本节，直接查看 [获取安装包](#获取安装包) 部分。
|
||||
|
||||
#### 安装 Python
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ sudo apt install python3.10-dev
|
|||
curl -sS https://bootstrap.pypa.io/get-pip.py | python3.10
|
||||
```
|
||||
|
||||
将 `~/.local/bin` 路径添加到环境变量中 `~/.bashrc or ~/.bash_profile`
|
||||
将 `~/.local/bin` 路径添加到环境变量中 `~/.bashrc or ~/.bash_profile`。
|
||||
```shell
|
||||
export PATH=$PATH:~/.local/bin
|
||||
```
|
||||
|
|
@ -127,7 +127,7 @@ sudo apt install build-essential
|
|||
```
|
||||
|
||||
### 获取安装包
|
||||
1. 从列表中下载获得 tar.gz 安装包：
|
||||
1. 从列表中下载获得 tar.gz 安装包
|
||||
|
||||
<PkgListV3 type={9}/>
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ cd TDengine-TDgpt-<version>
|
|||
|
||||
### 激活虚拟环境
|
||||
|
||||
为了避免安装操作系统的Python 环境， TDgpt 安装过程中会自动创建一个虚拟环境，该虚拟环境默认创建的路径在 `/var/lib/taos/taosanode/venv/`。创建完成该虚拟环境，该虚拟环境通过 PiPy 安装了支持 TDgpt 运行所必须的 Python 依赖库。
|
||||
为了避免安装操作系统的 Python 环境， TDgpt 安装过程中会自动创建一个虚拟环境，该虚拟环境默认创建的路径在 `/var/lib/taos/taosanode/venv/`。创建完成该虚拟环境，该虚拟环境通过 PiPy 安装了支持 TDgpt 运行所必须的 Python 依赖库。
|
||||
该虚拟环境不会被卸载脚本 `rmtaosanode` 删除，当您确认不再需要该虚拟环境的时候，需要手动删除该虚拟环境。
|
||||
后续如果您需要开发自己的算法模型，并能够 TDgpt 正确调用，需要将新的依赖库通过虚拟环境的 Pip 正确地安装。
|
||||
|
||||
|
|
|
|||
|
|
@ -82,14 +82,16 @@ Anode 运行配置主要是以下：
|
|||
|
||||
### Anode 基本操作
|
||||
对于 Anode 的管理，用户需要通过 TDengine 的命令行接口 taos 进行。因此下述介绍的管理命令都需要先打开 taos, 连接到 TDengine 运行实例。
|
||||
|
||||
#### 创建 Anode
|
||||
```sql
|
||||
CREATE ANODE {node_url}
|
||||
```
|
||||
node_url 是提供服务的 Anode 的 IP 和 PORT组成的字符串, 例如：`create anode '127.0.0.1:6090'`。Anode 启动后还需要注册到 TDengine 集群中才能提供服务。不建议将 Anode 同时注册到两个集群中。
|
||||
node_url 是提供服务的 Anode 的 IP 和 PORT 组成的字符串, 例如：`create anode '127.0.0.1:6090'`。Anode 启动后还需要注册到 TDengine 集群中才能提供服务。不建议将 Anode 同时注册到两个集群中。
|
||||
|
||||
#### 查看 Anode
|
||||
列出集群中所有的数据分析节点，包括其 `FQDN`, `PORT`, `STATUS`等属性。
|
||||
|
||||
```sql
|
||||
SHOW ANODES;
|
||||
|
||||
|
|
|
|||
|
|
@ -28,26 +28,26 @@ TDgpt 暂不提供独立的时间序列白噪声检测功能。
|
|||
|
||||
### 重采样和时间戳对齐
|
||||
|
||||
对于进行预测分析的时间序列数据，在进行预测分析前需要进行必要的预处理。预处理主要解决以下两个问题：
|
||||
对于进行预测分析的时间序列数据，在进行预测分析前需要进行必要的预处理。预处理主要解决以下两个问题。
|
||||
|
||||
- 真实时间序列数据时间戳未对齐。由于数据生成设备的原因或网关赋值时间戳的时候并不能保证按照严格的时间间隔赋值，时间序列数据并不能保证是严格按照采样频率对齐。例如采样频率为 1Hz 的一个时间序列数据序列，其时间戳序列如下：
|
||||
- 真实时间序列数据时间戳未对齐。由于数据生成设备的原因或网关赋值时间戳的时候并不能保证按照严格的时间间隔赋值，时间序列数据并不能保证是严格按照采样频率对齐。例如采样频率为 1Hz 的一个时间序列数据序列，其时间戳序列如下。
|
||||
|
||||
> ['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: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
|
||||
- 数据时间重采样。用户输入时间序列的采样频率超过了输出结果的频率，例如输入时间序列的采样时间间隔是 5 sec，但是要求输出预测结果的采样时间间隔是 10sec。
|
||||
|
||||
> ['20:12:20.000', '20:12:25.000', '20:12:30.000', '20:12:35.000', '20:12:40.000']
|
||||
|
||||
重采样为采样间隔为 10sec 的时间戳序列
|
||||
重采样为采样间隔为 10sec 的时间戳序列。
|
||||
|
||||
> ['20:12:20.000', '20:12:30.000', '20:12:40.000']
|
||||
|
||||
然后将其作为预测分析的输入， ['20:12:25.000', '20:12:35.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'] 那么对该序列进行预测分析将返回错误。
|
||||
需要注意的是，预处理过程不支持缺失数据补齐操作，如果输入时间序列数据 ['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']，那么对该序列进行预测分析将返回错误。
|
||||
|
||||
|
|
|
|||
|
|
@ -14,10 +14,16 @@ TDgpt 内置了涛思数据时序基础模型和 Time-MoE 两个时序基础模
|
|||
|1| tdtsfm_1 | 涛思时序数据基础模型 v1.0|
|
||||
|2| time-moe | 亿级别参数 MoE时序基础模型|
|
||||
|
||||
调用时序基础模型，无需设置模型相关参数，使用如下的 SQL 语句即可调用涛思时序基础模型（tdtsfm）的预测能力：
|
||||
TDgpt 集成了时序基础模型的预测能力，无需设置模型相关参数，使用 SQL 语句即可轻松调用时序基础模型的进行预测。
|
||||
|
||||
- 通过以下 SQL 语句，调用涛思时序基础模型（tdtfsm）预测数据。
|
||||
|
||||
```SQL
|
||||
SELECT _frowts, FORECAST(i32, "algo=tdtsfm_1,rows=10") from foo
|
||||
```
|
||||
|
||||
如果希望调用Time-MoE的预测分析能力，将参数 `algo=tdtsfm_1` 修改为 `algo=timemoe-fc` 即可。
|
||||
- 通过以下 SQL 语句，调用 TimeMoE 时序基础模型预测数据
|
||||
|
||||
```SQL
|
||||
SELECT _frowts, FORECAST(i32, "algo=algo=timemoe-fc,rows=10") from foo
|
||||
```
|
||||
|
|
@ -33,7 +33,8 @@ ARIMA 模型是一种自回归模型，只需要自变量即可预测后续的
|
|||
`start_p`、`max_p` `start_q` `max_q` 四个参数约束了模型在多大的范围内去搜寻合适的最优解。相同输入数据的条件下，参数范围越大，消耗的资源越多，系统响应的时间越长。
|
||||
|
||||
### 示例及结果
|
||||
针对 i32 列进行数据预测，输入列 i32 每 10 个点是一个周期，start_p 起始是 1， 最大拟合是 5，start_q 是 1，最大值是 5，预测结果中返回 95% 置信区间范围边界。
|
||||
针对 i32 列进行数据预测，输入列 i32 每 10 个点是一个周期；start_p 起始是 1，最大拟合是 5；start_q 是 1，最大值是 5，预测结果中返回 95% 置信区间范围边界。
|
||||
|
||||
```
|
||||
FORECAST(i32, "algo=arima,alpha=95,period=10,start_p=1,max_p=5,start_q=1,max_q=5")
|
||||
```
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ algo=expr1
|
|||
```
|
||||
|
||||
1. `column_expr`：预测的时序数据列，只支持数值类型列输入。
|
||||
2. `options`：预测函数的参数。字符串类型，其中使用 K=V 方式调用算法及相关参数。采用逗号分隔的 K=V 字符串表示，其中的字符串不需要使用单引号、双引号、或转义号等符号，不能使用中文及其他宽字符。预测支持 `conf`, `every`, `rows`, `start`, `rows` 几个控制参数，其含义如下：
|
||||
2. `options`：预测函数的参数。字符串类型，其中使用 K=V 方式调用算法及相关参数。采用逗号分隔的 K=V 字符串表示，其中的字符串不需要使用单引号、双引号、或转义号等符号，不能使用中文及其他宽字符。预测支持 `conf`、`every`、`rows`、`start`、`rows` 几个控制参数，其含义如下。
|
||||
|
||||
### 参数说明
|
||||
|
||||
|
|
@ -58,12 +58,15 @@ algo=expr1
|
|||
| start | 预测结果的开始时间戳 | 输入数据最后一个时间戳加上一个采样间隔时间区间 |
|
||||
| rows | 预测结果的记录数 | 10 |
|
||||
|
||||
1. 预测查询结果新增三个伪列，具体如下：`_FROWTS`：预测结果的时间戳、`_FLOW`：置信区间下界、`_FHIGH`：置信区间上界, 对于没有置信区间的预测算法，其置信区间同预测结果
|
||||
2. 更改参数 `START`：返回预测结果的起始时间，改变起始时间不会影响返回的预测数值，只影响起始时间。
|
||||
3. `EVERY`：可以与输入数据的采样频率不同。采样频率只能低于或等于输入数据采样频率，不能**高于**输入数据的采样频率。
|
||||
4. 对于某些不需要计算置信区间的算法，即使指定了置信区间，返回的结果中其上下界退化成为一个点。
|
||||
5. rows 的最大输出值是 1024，即只能预测 1024 个值。超过输出范围的参数会被自动设置为 1024。
|
||||
6. 预测分析的输入数据行数最大值是 40000 行，即用于预测分析的历史数据不能超过 40000 行。针对部分分析模型，输入限制更严格。
|
||||
- 预测查询结果新增三个伪列，具体如下。
|
||||
- `_FROWTS`：预测结果的时间戳
|
||||
- `_FLOW`：置信区间下界
|
||||
- `_FHIGH`：置信区间上界，对于没有置信区间的预测算法，其置信区间同预测结果
|
||||
- 更改参数 `START`：返回预测结果的起始时间，改变起始时间不会影响返回的预测数值，只影响起始时间。
|
||||
- `EVERY`：可以与输入数据的采样频率不同。采样频率只能低于或等于输入数据采样频率，不能**高于**输入数据的采样频率。
|
||||
- 对于某些不需要计算置信区间的算法，即使指定了置信区间，返回的结果中其上下界退化成为一个点。
|
||||
- rows 的最大输出值是 1024，即只能预测 1024 个值。超过输出范围的参数会被自动设置为 1024。
|
||||
- 预测分析的输入数据行数最大值是 40000 行，即用于预测分析的历史数据不能超过 40000 行。针对部分分析模型，输入限制更严格。
|
||||
|
||||
|
||||
### 示例
|
||||
|
|
@ -96,8 +99,8 @@ taos> select _flow, _fhigh, _frowts, forecast(i32) from foo;
|
|||
|
||||
## 内置预测算法
|
||||
|
||||
- [arima](./02-arima.md)
|
||||
- [holtwinters](./03-holtwinters.md)
|
||||
- [ARIMA](./02-arima.md)
|
||||
- [HoltWinters](./03-holtwinters.md)
|
||||
- CES (Complex Exponential Smoothing)
|
||||
- Theta
|
||||
- Prophet
|
||||
|
|
@ -118,7 +121,7 @@ taos> select _flow, _fhigh, _frowts, forecast(i32) from foo;
|
|||
|
||||
TDgpt 在企业版中提供预测分析算法有效性评估工具 `analytics_compare`，调用该工具并设置合适的参数，能够使用 TDengine 中已经保存的数据作为回测依据，评估不同预测算法或训练模型的预测有效性。预测有效性的评估使用 `MSE` 指标作为依据，后续还将增加 `MAPE` 和 `MAE` 指标。
|
||||
|
||||
使用评估工具，需要在配置文件`` 中设置正确的参数，包括选取评估的数据范围，结果输出时间，参与评估的算法、算法相应的参数、是否生成预测结果图等配置信息。
|
||||
使用评估工具，需要在配置文件 `taosanode.ini` 中设置正确的参数，包括选取评估的数据范围、结果输出时间、参与评估的算法、算法相应的参数、是否生成预测结果图等配置信息。
|
||||
|
||||
```ini
|
||||
[forecast]
|
||||
|
|
|
|||
|
|
@ -10,16 +10,16 @@ sidebar_label: "统计学算法"
|
|||
|k|标准差倍数|选填|3|
|
||||
|
||||
```SQL
|
||||
--- 指定调用的算法为ksigma, 参数 k 为 2
|
||||
--- 指定调用的算法为ksigma，参数 k 为 2
|
||||
SELECT _WSTART, COUNT(*)
|
||||
FROM foo
|
||||
ANOMALY_WINDOW(foo.i32, "algo=ksigma,k=2")
|
||||
```
|
||||
|
||||
- IQR<sup>[2]</sup>：Interquartile range(IQR)，四分位距是一种衡量变异性的方法。四分位数将一个按等级排序的数据集划分为四个相等的部分。即 Q1（第 1 个四分位数）、Q2（第 2 个四分位数）和 Q3（第 3 个四分位数）。 $IQR=Q3-Q1$，对于 $v$, $Q1-(1.5 \times IQR) \le v \le Q3+(1.5 \times IQR)$ 是正常值，范围之外的是异常值。无输入参数。
|
||||
- IQR<sup>[2]</sup>：Interquartile range(IQR)，四分位距是一种衡量变异性的方法。四分位数将一个按等级排序的数据集划分为四个相等的部分。即 Q1（第 1 个四分位数）、Q2（第 2 个四分位数）和 Q3（第 3 个四分位数）。 $IQR=Q3-Q1$，对于 $v$，$Q1-(1.5 \times IQR) \le v \le Q3+(1.5 \times IQR)$ 是正常值，范围之外的是异常值。无输入参数。
|
||||
|
||||
```SQL
|
||||
--- 指定调用的算法为 iqr, 无参数
|
||||
--- 指定调用的算法为 iqr，无参数
|
||||
SELECT _WSTART, COUNT(*)
|
||||
FROM foo
|
||||
ANOMALY_WINDOW(foo.i32, "algo=iqr")
|
||||
|
|
@ -28,7 +28,7 @@ ANOMALY_WINDOW(foo.i32, "algo=iqr")
|
|||
- Grubbs<sup>[3]</sup>: Grubbs' test，即最大标准残差测试。Grubbs 通常用作检验最大值、最小值偏离均值的程度是否为异常，要求单变量数据集遵循近似标准正态分布。非正态分布数据集不能使用该方法。无输入参数。
|
||||
|
||||
```SQL
|
||||
--- 指定调用的算法为 grubbs, 无参数
|
||||
--- 指定调用的算法为 grubbs，无参数
|
||||
SELECT _WSTART, COUNT(*)
|
||||
FROM foo
|
||||
ANOMALY_WINDOW(foo.i32, "algo=grubbs")
|
||||
|
|
@ -44,7 +44,7 @@ ANOMALY_WINDOW(foo.i32, "algo=grubbs")
|
|||
|
||||
|
||||
```SQL
|
||||
--- 指定调用的算法为 shesd, 参数 direction 为 both，异常值比例 5%
|
||||
--- 指定调用的算法为 shesd，参数 direction 为 both，异常值比例 5%
|
||||
SELECT _WSTART, COUNT(*)
|
||||
FROM foo
|
||||
ANOMALY_WINDOW(foo.i32, "algo=shesd,direction=both,anoms=0.05")
|
||||
|
|
|
|||
|
|
@ -4,9 +4,7 @@ sidebar_label: "数据密度算法"
|
|||
---
|
||||
|
||||
### 基于数据密度/数据挖掘的检测算法
|
||||
LOF<sup>[1]</sup>: Local Outlier Factor(LOF)，局部离群因子/局部异常因子，
|
||||
是 Breunig 在 2000 年提出的一种基于密度的局部离群点检测算法，该方法适用于不同类簇密度分散情况迥异的数据。根据数据点周围的数据密集情况，首先计算每个数据点的一个局部可达密度，然后通过局部可达密度进一步计算得到每个数据点的一个离群因子，
|
||||
该离群因子即标识了一个数据点的离群程度，因子值越大，表示离群程度越高，因子值越小，表示离群程度越低。最后，输出离群程度最大的 $topK$ 个点。
|
||||
LOF<sup>[1]</sup>: Local Outlier Factor(LOF)，局部离群因子/局部异常因子，是 Breunig 在 2000 年提出的一种基于密度的局部离群点检测算法，该方法适用于不同类簇密度分散情况迥异的数据。根据数据点周围的数据密集情况，首先计算每个数据点的局部可达密度，然后通过局部可达密度进一步计算得到每个数据点的一个离群因子。该离群因子即标识了一个数据点的离群程度，因子值越大，表示离群程度越高，因子值越小，表示离群程度越低。最后，输出离群程度最大的 $topK$ 个点。
|
||||
|
||||
```SQL
|
||||
--- 指定调用的算法为LOF，即可调用该算法
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ description: 异常检测
|
|||
import ad from '../pic/anomaly-detection.png';
|
||||
import ad_result from '../pic/ad-result.png';
|
||||
|
||||
TDengine 中定义了异常（状态）窗口来提供异常检测服务。异常窗口可以视为一种特殊的**事件窗口（Event Window）**，即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于——时间窗口的起始时间和结束时间均是分析算法识别确定，不是用户给定的表达式进行判定。因此，在 `WHERE` 子句中使用 `ANOMALY_WINDOW` 关键词即可调用时序数据异常检测服务，同时窗口伪列（`_WSTART`, `_WEND`, `_WDURATION`）也能够像其他时间窗口一样用于描述异常窗口的起始时间(`_WSTART`)、结束时间(`_WEND`)、持续时间(`_WDURATION`)。例如：
|
||||
TDengine 中定义了异常（状态）窗口来提供异常检测服务。异常窗口可以视为一种特殊的**事件窗口（Event Window）**，即异常检测算法确定的连续异常时间序列数据所在的时间窗口。与普通事件窗口区别在于，时间窗口的起始时间和结束时间均由分析算法识别确定，不通过用户给定的表达式进行判定。因此，在 `WHERE` 子句中使用 `ANOMALY_WINDOW` 关键词即可调用时序数据异常检测服务，同时窗口伪列（`_WSTART`、`_WEND`、`_WDURATION`）也能够像其他时间窗口一样用于描述异常窗口的起始时间(`_WSTART`)、结束时间(`_WEND`)、持续时间(`_WDURATION`)。例如：
|
||||
|
||||
```SQL
|
||||
--- 使用异常检测算法 IQR 对输入列 col_val 进行异常检测。同时输出异常窗口的起始时间、结束时间、以及异常窗口内 col 列的和。
|
||||
|
|
@ -15,7 +15,7 @@ FROM foo
|
|||
ANOMALY_WINDOW(col_val, "algo=iqr");
|
||||
```
|
||||
|
||||
如下图所示，Anode 将返回时序数据异常窗口 $[10:51:30, 10:53:40]$
|
||||
如下图所示，Anode 将返回时序数据异常窗口 **[10:51:30, 10:53:40]**
|
||||
|
||||
<figure style={{textAlign: "center"}}>
|
||||
<img src={ad} alt="异常检测"/>
|
||||
|
|
@ -35,7 +35,7 @@ algo=expr1
|
|||
"}
|
||||
```
|
||||
|
||||
1. `column_name`：进行时序数据异常检测的输入数据列，当前只支持单列，且只能是数值类型，不能是字符类型（例如：`NCHAR` `VARCHAR` `VARBINARY`等类型），**不支持函数表达式**。
|
||||
1. `column_name`：进行时序数据异常检测的输入数据列，当前只支持单列，且只能是数值类型，不能是字符类型（例如：`NCHAR`、`VARCHAR`、`VARBINARY`等类型），**不支持函数表达式**。
|
||||
2. `options`：字符串。其中使用 K=V 调用异常检测算法及与算法相关的参数。采用逗号分隔的 K=V 字符串表示，其中的字符串不需要使用单引号、双引号、或转义号等符号，不能使用中文及其他宽字符。例如：`algo=ksigma,k=2` 表示进行异常检测的算法是 ksigma，该算法接受的输入参数是 2。
|
||||
3. 异常检测的结果可以作为外层查询的子查询输入，在 `SELECT` 子句中使用的聚合函数或标量函数与其他类型的窗口查询相同。
|
||||
4. 输入数据默认进行白噪声检查，如果输入数据是白噪声，将不会有任何（异常）窗口信息返回。
|
||||
|
|
@ -70,13 +70,13 @@ Query OK, 1 row(s) in set (0.028946s)
|
|||
|
||||
### 内置异常检测算法
|
||||
|
||||
分析平台内置了6个异常检查模型，分为3个类别，分别是[基于统计学的算法](./02-statistics-approach.md)、[基于数据密度的算法](./03-data-density.md)、以及[基于机器学习的算法](./04-machine-learning.md)。在不指定异常检测使用的方法的情况下，默认调用 IQR 进行异常检测。
|
||||
分析平台内置了 6 个异常检查模型，分为 3 个类别，分别是 [基于统计学的算法](./02-statistics-approach.md)、[基于数据密度的算法](./03-data-density.md)、以及[基于机器学习的算法](./04-machine-learning.md)。在不指定异常检测使用的方法的情况下，默认调用 IQR 进行异常检测。
|
||||
|
||||
### 异常检测算法有效性比较工具
|
||||
|
||||
TDgpt 提供自动化的工具对比不同数据集的不同算法监测有效性，针对异常检测算法提供查全率（recall）和查准率（precision）两个指标衡量不同算法的有效性。
|
||||
通过在配置文件中(analysis.ini)设置以下的选项可以调用需要使用的异常检测算法，异常检测算法测试用数据的时间范围、是否生成标注结果的图片、调用的异常检测算法以及相应的参数。
|
||||
调用异常检测算法比较之前，需要人工手动标注异常监测数据集的结果，即设置[anno_res]选项的数值，第几个数值是异常点，需要标注在数组中，如下测试集中，第 9 个点是异常点，我们就标注异常结果为 [9].
|
||||
调用异常检测算法比较之前，需要人工手动标注异常监测数据集的结果，即设置 [anno_res] 选项的数值，在数组中标注那几个数值是异常点。如下测试集中，第 9 个点是异常点，我们就标注异常结果为 [9].
|
||||
|
||||
```bash
|
||||
[ad]
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ SELECT _flow, _fhigh, _frowts, FORECAST(col_name, "algo=myfc")
|
|||
FROM foo;
|
||||
```
|
||||
|
||||
如果是第一次启动该 Anode, 请按照 [运维管理指南](../../management/) 里的步骤先将该 Anode 添加到 TDengine 系统中。
|
||||
如果是第一次启动该 Anode, 请按照 [运维管理指南](../../03-management) 里的步骤先将该 Anode 添加到 TDengine 系统中。
|
||||
|
||||
### 单元测试
|
||||
|
||||
|
|
@ -8,7 +8,7 @@ sidebar_label: "异常检测"
|
|||
|
||||
### 输出约定
|
||||
`execute` 方法执行完成后的返回值是长度与 `self.list` 相同的数组，数组位置 -1 的标识异常值点。
|
||||
> 例如：对于输入测量值序列 $[2, 2, 2, 2, 100]$， 假设 100 是异常点，那么方法返回的结果数组则为 $[1, 1, 1, 1, -1]$。
|
||||
> 例如：对于输入测量值序列 $[2, 2, 2, 2, 100]$，假设 100 是异常点，那么方法返回的结果数组则为 $[1, 1, 1, 1, -1]$。
|
||||
|
||||
|
||||
### 示例代码
|
||||
|
|
@ -57,7 +57,7 @@ SELECT COUNT(*) FROM foo ANOMALY_WINDOW(col, 'algo=myad')
|
|||
|
||||
### 单元测试
|
||||
|
||||
在测试目录`taosanalytics/test`中的 anomaly_test.py 中增加单元测试用例或添加新的测试文件。框架中使用了 Python Unit test 包。
|
||||
在测试目录 `taosanalytics/test` 中的 anomaly_test.py 中增加单元测试用例或添加新的测试文件。框架中使用了 Python Unit test 包。
|
||||
|
||||
```python
|
||||
def test_myad(self):
|
||||
|
|
@ -12,9 +12,9 @@ sidebar_label: "添加机器学习模型"
|
|||
推荐将模型保存在默认的保存目录（`/usr/local/taos/taosanode/model/`）中，也可以在目录中建立下一级目录，用以保存模型。下面使用 Keras 开发的基于自编码器(auto encoder) 的异常检测模型添加到 TDgpt 为例讲解整个流程。
|
||||
|
||||
该模型在 TDgpt 系统中名称为 'sample_ad_model'。
|
||||
训练该模型的代码见：[https://github.com/taosdata/TDengine/tree/main/tools/tdgpt/taosanalytics/misc/training_ad_model.py](https://github.com/taosdata/TDengine/tree/main/tools/tdgpt/taosanalytics/misc/training_ad_model.py)
|
||||
该模型训练使用了 NAB 的[art_daily_small_noise 数据集](https://raw.githubusercontent.com/numenta/NAB/master/data/artificialNoAnomaly/art_daily_small_noise.csv)。
|
||||
训练完成得到的模型保存成为了两个文件，点击[此处](https://github.com/taosdata/TDengine/blob/main/tools/tdgpt/model/sample-ad-autoencoder/)下载该模型文件，模型文件说明如下：
|
||||
训练该模型的代码见：[training_ad_model.py](https://github.com/taosdata/TDengine/tree/main/tools/tdgpt/taosanalytics/misc/training_ad_model.py)。
|
||||
该模型训练使用了 NAB 的 [art_daily_small_noise 数据集](https://raw.githubusercontent.com/numenta/NAB/master/data/artificialNoAnomaly/art_daily_small_noise.csv)。
|
||||
训练完成得到的模型保存成为了两个文件，点击 [此处](https://github.com/taosdata/TDengine/blob/main/tools/tdgpt/model/sample-ad-autoencoder/) 下载该模型文件，模型文件说明如下。
|
||||
|
||||
```bash
|
||||
sample-ad-autoencoder.keras 模型文件，默认 keras 模型文件格式
|
||||
|
|
@ -23,7 +23,7 @@ sample-ad-autoencoder.info 模型附加参数文件，采用了 joblib 格式
|
|||
|
||||
## 保存在合适位置
|
||||
|
||||
然后在 `/usr/local/taos/taosanode/model` 文件目录下建立子目录 `sample-ad-autoencoder`, 用以保存下载两个模型文件。此时 `model` 文件夹结构如下：
|
||||
然后在 `/usr/local/taos/taosanode/model` 文件目录下建立子目录 `sample-ad-autoencoder`，用以保存下载两个模型文件。此时 `model` 文件夹结构如下：
|
||||
|
||||
```bash
|
||||
.
|
||||
|
|
@ -35,7 +35,7 @@ sample-ad-autoencoder.info 模型附加参数文件，采用了 joblib 格式
|
|||
|
||||
## 添加模型适配代码
|
||||
|
||||
下面需要在 taosanalytics 目录下添加加载该模型并进行适配的 Python 代码，即可运行该模型。适配并行运行的代码见[https://github.com/taosdata/TDengine/blob/main/tools/tdgpt/taosanalytics/algo/ad/autoencoder.py](https://github.com/taosdata/TDengine/blob/main/tools/tdgpt/taosanalytics/algo/ad/autoencoder.py)。
|
||||
需要在 taosanalytics 目录下添加加载该模型并进行适配的 Python 代码。适配并行运行的代码见 [autoencoder.py](https://github.com/taosdata/TDengine/blob/main/tools/tdgpt/taosanalytics/algo/ad/autoencoder.py)。
|
||||
为了便于方便，我们已经将该文件保存在该目录，所以您在执行 `show anodes full` 命令时候，能够看见该算法模型。
|
||||
|
||||
下面详细说明该代码的逻辑。
|
||||
|
|
@ -151,9 +151,10 @@ class _AutoEncoderDetectionService(AbstractAnomalyDetectionService):
|
|||
```
|
||||
|
||||
## 使用 SQL 调用模型
|
||||
该模型由于已经预置在系统中，所以您通过 `show anodes full` 能够直接看到。一个新的算法适配完成以后，需要重新启动 taosanode， 并执行命令 `update all anodes` 更新 mnode 的。
|
||||
该模型已经预置在系统中，您可通过 `show anodes full` 直接查看。一个新的算法适配完成以后，需要重新启动 taosanode，并执行命令 `update all anodes` 更新 mnode 的算法列表。
|
||||
|
||||
通过设置参数 `algo=sample_ad_model` 告诉 TDgpt 要调用自编码器算法训练的模型（该算法模型在可用算法列表中），因此直接指定即可。此外还需要指定自编码器针对某数据集训练的确定的模型，此时我们需要使用已经保存的模型 `sample-ad-autoencoder` ，因此需要添加参数 `model=sample-ad-autoencoder` 以便能够调用该模型。
|
||||
- 通过设置参数 `algo=sample_ad_model`，告诉 TDgpt 调用自编码器算法训练的模型（该算法模型在可用算法列表中）。
|
||||
- 通过设置参数 `model=sample-ad-autoencoder`，指定自编码器针对某数据集训练的模型。
|
||||
|
||||
```SQL
|
||||
--- 在 options 中增加 model 的名称，ad_autoencoder_foo， 针对 foo 数据集（表）训练的采用自编码器的异常检测模型进行异常检测
|
||||
|
|
@ -38,14 +38,13 @@ def time_moe():
|
|||
```
|
||||
其中的 port 修改为希望开启的端口，重启脚本即可。
|
||||
|
||||
|
||||
# 启动部署 Python 脚本
|
||||
|
||||
```shell
|
||||
nohup python time-moe.py > service_output.out 2>&1 &
|
||||
```
|
||||
|
||||
第一次启动脚本会从 huggingface 自动加载[2亿参数模型](https://huggingface.co/Maple728/TimeMoE-200M)。该模型是 Time-MoE 200M参数版本，如果您需要部署参数规模更小的版本请将 `time-moe.py` 文件中 `'Maple728/TimeMoE-200M'` 修改为 `Maple728/TimeMoE-50M`，此时将加载 [0.5亿参数模型](https://huggingface.co/Maple728/TimeMoE-50M)。
|
||||
第一次启动脚本会从 huggingface 自动加载 [2 亿参数模型](https://huggingface.co/Maple728/TimeMoE-200M)。该模型是 Time-MoE 200M参数版本，如果您需要部署参数规模更小的版本请将 `time-moe.py` 文件中 `'Maple728/TimeMoE-200M'` 修改为 `Maple728/TimeMoE-50M`，此时将加载 [0.5 亿参数模型](https://huggingface.co/Maple728/TimeMoE-50M)。
|
||||
|
||||
如果加载失败，请尝试执行如下命令切换为国内镜像下载模型。
|
||||
|
||||
|
|
@ -7,7 +7,6 @@ title: 添加时序基础模型
|
|||
|
||||
本章节将详细介绍如何部署使用 Time-MoE 等的时序基础模型，并通过 SQL 语句直接调用其时序数据分析能力。
|
||||
|
||||
|
||||
```mdx-code-block
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
|
||||
|
|
@ -2,17 +2,17 @@
|
|||
title: "开发者指南"
|
||||
sidebar_label: "开发者指南"
|
||||
---
|
||||
TDgpt 是一个可扩展的时序数据高级分析智能体，用户遵循简易的步骤就能将自己开发的分析算法添加到分析平台, 各种应用就可以通过SQL语句直接调用, 让高级分析算法的使用门槛降到几乎为零。目前 TDpgt 平台只支持使用 Python 语言开发的分析算法。
|
||||
Anode 采用类动态加载模式，在启动的时候扫描特定目录内满足约定条件的所有代码文件，并将其加载到系统中。因此，开发者只需要遵循以下几步就能完成新算法的添加工作：
|
||||
TDgpt 是一个可扩展的时序数据高级分析智能体，用户遵循简易的步骤就能将自己开发的分析算法添加到分析平台，各种应用就可以通过 SQL 语句直接调用，让高级分析算法的使用门槛降到几乎为零。目前 TDpgt 平台只支持使用 Python 语言开发的分析算法。
|
||||
Anode 采用类动态加载模式，在启动的时候扫描特定目录内满足约定条件的所有代码文件，并将其加载到系统中。因此，开发者只需要遵循以下几步就能完成新算法的添加工作。
|
||||
1. 开发完成符合要求的分析算法类
|
||||
2. 将代码文件放入对应目录，然后重启 Anode
|
||||
3. 使用SQL命令"CREATE ANODE"，将 Anode 添加到 TDengine
|
||||
3. 使用 SQL 命令 `CREATE ANODE`，将 Anode 添加到 TDengine
|
||||
|
||||
此时就完成了新算法的添加工作，之后应用就可以直接使用SQL语句调用新算法。得益于 TDgpt 与 TDengine主进程 `taosd` 的松散耦合，Anode算法升级对 `taosd` 完全没有影响。应用系统只需要调整对应的SQL语句调用新（升级的）算法，就能够快速完成分析功能和分析算法的升级。
|
||||
完成新算法添加工作后，就可以直接使用 SQL 语句调用新算法。得益于 TDgpt 与 TDengine 主进程 `taosd` 的松散耦合，Anode算法升级对 `taosd` 完全没有影响。应用系统只需要调整对应的 SQL 语句调用新（升级的）算法，就能够快速完成分析功能和分析算法的升级。
|
||||
|
||||
这种方式能够按需扩展分析算法，极大地拓展 TDgpt 的适应范围，用户可以按需将更契合业务场景的、更准确的（预测、异常检测）分析算法动态嵌入到 TDgpt，并通过 SQL 语句进行调用。在基本不用更改应用系统代码的前提下，就能够快速完成分析功能的平滑升级。
|
||||
这种方式能够按需扩展分析算法，极大地拓展 TDgpt 的适应范围，用户可以按需将更契合业务场景的、更准确的（预测、异常检测）分析算法动态嵌入到 TDgpt，并通过 SQL 语句调用。在基本不用更改应用系统代码的前提下，就能够快速完成分析功能的平滑升级。
|
||||
|
||||
以下内容将说明如何将分析算法添加到 Anode 中并能够通过SQL语句进行调用。
|
||||
以下内容将说明如何将分析算法添加到 Anode 中并能够通过 SQL 语句进行调用。
|
||||
|
||||
## 目录结构
|
||||
Anode的主要目录结构如下图所示
|
||||
|
|
@ -49,7 +49,7 @@ Anode的主要目录结构如下图所示
|
|||
|
||||
### 类命名规范
|
||||
|
||||
Anode采用算法自动加载模式，因此只识别符合命名约定的 Python 类。需要加载的算法类名称需要以下划线 `_` 开始并以 `Service` 结尾。例如：`_KsigmaService` 是 KSigma 异常检测算法类。
|
||||
Anode 采用算法自动加载模式，因此只识别符合命名约定的 Python 类。需要加载的算法类名称需要以下划线 `_` 开始并以 `Service` 结尾。例如：`_KsigmaService` 是 KSigma 异常检测算法类。
|
||||
|
||||
### 类继承约定
|
||||
|
||||
|
|
@ -5,10 +5,9 @@ sidebar_label: "常见问题"
|
|||
|
||||
### 1. 安装过程中编译 uWSGI 失败，如何处理
|
||||
TDgpt 安装过程中需要在本地编译 uWSGI，某些环境的 Python（例如：anaconda）安装 uWSGI 会出现冲突导致编译失败，安装流程因此无法继续下去。这种情况下可以尝试在安装过程中忽略 uWSGI的安装。
|
||||
由于忽略了 uWSGI 安装，后续启动 taosasnode 服务的时候，需要手动输入命令进行启动 `python3.10 /usr/local/taos/taosanode/lib/taosanalytics/app.py` 。 执行该命令的时候请确保使用了虚拟环境中的 Python 程序才能加载依赖库。
|
||||
由于忽略了 uWSGI 安装，后续启动 taosasnode 服务的时候，需要手动输入命令进行启动 `python3.10 /usr/local/taos/taosanode/lib/taosanalytics/app.py`。 执行该命令的时候请确保使用了虚拟环境中的 Python 程序才能加载依赖库。
|
||||
|
||||
|
||||
### 2. 创建 anode 失败，返回指定服务无法访问
|
||||
### 2. 创建 Anode 失败，返回指定服务无法访问
|
||||
|
||||
```bash
|
||||
taos> create anode '127.0.0.1:6090';
|
||||
|
|
@ -16,18 +15,18 @@ taos> create anode '127.0.0.1:6090';
|
|||
DB error: Analysis service can't access[0x80000441] (0.117446s)
|
||||
```
|
||||
|
||||
请务必使用 `curl` 命令检查 anode 服务是否正常。`curl '127.0.0.1:6090'` 正常的 anode 服务会返回以下结果。
|
||||
请务必使用 `curl` 命令检查 Anode 服务是否正常。执行 `curl '127.0.0.1:6090'` 后，正常的 Anode 服务会返回以下结果。
|
||||
|
||||
```bash
|
||||
TDengine© Time Series Data Analytics Platform (ver 1.0.x)
|
||||
```
|
||||
|
||||
如果出现下面的结果，表示 anode 服务不正常。
|
||||
如果出现下面的结果，表示 Anode 服务不正常。
|
||||
```bash
|
||||
curl: (7) Failed to connect to 127.0.0.1 port 6090: Connection refused
|
||||
```
|
||||
|
||||
如果 anode 服务启动/运行不正常，请检查 uWSGI 的运行日志 `/var/log/taos/taosanode/taosanode.log`，检查其中的错误信息，根据错误信息解决响应的问题。
|
||||
如果 Anode 服务启动/运行不正常，请检查 uWSGI 的运行日志 `/var/log/taos/taosanode/taosanode.log`，检查其中的错误信息，根据错误信息解决响应的问题。
|
||||
|
||||
>请勿使用 systemctl status taosanode 检查 taosanode 是否正常
|
||||
|
||||
|
|
@ -37,9 +36,10 @@ taos> select _frowts,forecast(current, 'algo=arima, alpha=95, wncheck=0, rows=20
|
|||
|
||||
DB error: Analysis service can't access[0x80000441] (60.195613s)
|
||||
```
|
||||
|
||||
数据分析默认超时时间是 60s，出现这个问题的原因是输入数据分析过程超过默认的最长等待时间，请尝试采用限制数据输入范围的方式将输入数据规模减小或者更换分析算法再次尝试。
|
||||
|
||||
### 4. 返回结果出现非法 JSON 格式错误 (Invalid json format)
|
||||
|
||||
从 anode 返回到 TDengine 的分析结果有误，请检查 anode 运行日志 `/var/log/taos/taosanode/taosanode.app.log`，以便于获得具体的错误信息。
|
||||
从 Anode 返回到 TDengine 的分析结果有误，请检查 Anode 运行日志 `/var/log/taos/taosanode/taosanode.app.log`，以便于获得具体的错误信息。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue