iotdb数据库指令（数据库odb是什么意思）

AINode 是 IoTDB 在ConfigNode、DataNode后提供的第三种内生节点，该节点通过与 IoTDB 集群的 DataNode、ConfigNode 的交互，扩展了对时间序列进行机器学习分析的能力，支持从外部引入已有机器学习模型进行注册，并使用注册的模型在指定时序数据上通过简单 SQL 语句完成时序分析任务的过程，将模型的创建、管理及推理融合在数据库引擎中。目前已提供常见时序分析场景（例如预测与异常检测）的机器学习算法或自研模型。

系统架构如下图所示：

三种节点的职责如下：

ConfigNode：负责保存和管理模型的元信息；负责分布式节点管理。
DataNode：负责接收并解析用户的 SQL请求；负责存储时间序列数据；负责数据的预处理计算。
AINode：负责模型文件的导入创建以及模型推理。

与单独构建机器学习服务相比，具有以下优势：

简单易用：无需使用 Python 或 Java 编程，使用 SQL 语句即可完成机器学习模型管理与推理的完整流程。如创建模型可使用CREATE MODEL语句、使用模型进行推理可使用CALL INFERENCE(...)语句等，使用更加简单便捷。
避免数据迁移：使用 IoTDB 原生机器学习可以将存储在 IoTDB 中的数据直接应用于机器学习模型的推理，无需将数据移动到单独的机器学习服务平台，从而加速数据处理、提高安全性并降低成本。

内置先进算法：支持业内领先机器学习分析算法，覆盖典型时序分析任务，为时序数据库赋能原生数据分析能力。如：
- 时间序列预测（Time Series Forecasting）：从过去时间序列中学习变化模式；从而根据给定过去时间的观测值，输出未来序列最可能的预测。
- 时序异常检测（Anomaly Detection for Time Series）：在给定的时间序列数据中检测和识别异常值，帮助发现时间序列中的异常行为。
- 时间序列标注（Time Series Annotation）：为每个数据点或特定时间段添加额外的信息或标记，例如事件发生、异常点、趋势变化等，以便更好地理解和分析数据。

模型（Model）：机器学习模型，以时序数据作为输入，输出分析任务的结果或决策。模型是AINode 的基本管理单元，支持模型的增（注册）、删、查、用（推理）。
创建（Create）: 将外部设计或训练好的模型文件或算法加载到MLNode中，由IoTDB统一管理与使用。
推理（Inference）：使用创建的模型在指定时序数据上完成该模型适用的时序分析任务的过程。
内置能力（Built-in）：AINode 自带常见时序分析场景（例如预测与异常检测）的机器学习算法或自研模型。

AINode 的部署可参考文档章节。

AINode 对时序数据相关的深度学习模型提供了模型创建及删除的流程，内置模型无需创建及删除，可直接使用，并且在完成推理后创建的内置模型实例将自动销毁。

通过指定模型输入输出的向量维度，可以注册训练好的深度学习模型，从而用于模型推理。

符合以下内容的模型可以注册到AINode中：

AINode 支持的PyTorch 2.1.0、 2.2.0版本训练的模型，需避免使用2.2.0版本以上的特性。
AINode支持使用PyTorch JIT存储的模型，模型文件需要包含模型的参数和结构。
模型输入序列可以包含一列或多列，若有多列，需要和模型能力、模型配置文件对应。
模型的输入输出维度必须在配置文件中明确定义。使用模型时，必须严格按照配置文件中定义的输入输出维度。如果输入输出列数不匹配配置文件，将会导致错误。

下方为模型注册的SQL语法定义。

SQL中参数的具体含义如下：

model_name：模型的全局唯一标识，不可重复。模型名称具备以下约束：
- 允许出现标识符 [ 0-9 a-z A-Z _ ] （字母，数字，下划线）
- 长度限制为2-64字符
- 大小写敏感
uri：模型注册文件的资源路径，路径下应包含模型权重model.pt文件和模型的元数据描述文件config.yaml
- 模型权重文件：深度学习模型训练完成后得到的权重文件，目前支持pytorch训练得到的.pt文件
- yaml元数据描述文件：模型注册时需要提供的与模型结构有关的参数，其中必须包含模型的输入输出维度用于模型推理：
  - 参数名参数描述示例input_shape模型输入的行列，用于模型推理[96,2]output_shape模型输出的行列，用于模型推理[48,2]
  - 除了模型推理外，还可以指定模型输入输出的数据类型：
  - 参数名参数描述示例input_type模型输入的数据类型['float32','float32']output_type模型输出的数据类型['float32','float32']
  - 除此之外，可以额外指定备注信息用于在模型管理时进行展示
  - 参数名参数描述示例attributes可选，用户自行设定的模型备注信息，用于模型展示'model_type': 'dlinear','kernel_size': '25'

除了本地模型文件的注册，还可以通过URI来指定远程资源路径来进行注册，使用开源的模型仓库（例如HuggingFace）。

在当前的example文件夹下，包含model.pt和config.yaml文件，model.pt为训练得到，config.yaml的内容如下：

指定该文件夹作为加载路径就可以注册该模型

也可以从huggingFace上下载对应的模型文件进行注册

SQL执行后会异步进行注册的流程，可以通过模型展示查看模型的注册状态（见模型展示章节），注册成功的耗时主要受到模型文件大小的影响。

模型注册完成后，就可以通过使用正常查询的方式调用具体函数，进行模型推理。

注册成功的模型可以通过show models指令查询模型的具体信息。其SQL定义如下：

除了直接展示所有模型的信息外，可以指定model id来查看某一具体模型的信息。模型展示的结果中包含如下信息：

ModelIdStateConfigsAttributes模型唯一标识模型注册状态(LOADING,ACTIVE,DROPPING)InputShape, outputShapeInputTypes, outputTypes模型备注信息

其中，State用于展示当前模型注册的状态，包含以下三个阶段

LOADING：已经在configNode中添加对应的模型元信息，正将模型文件传输到AINode节点上
ACTIVE: 模型已经设置完成，模型处于可用状态
DROPPING：模型删除中，正在从configNode以及AINode处删除模型相关信息
UNAVAILABLE: 模型创建失败，可以通过drop model删除创建失败的model_name。

我们前面已经注册了对应的模型，可以通过对应的指定查看模型状态，active表明模型注册成功，可用于推理。

对于注册成功的模型，用户可以通过SQL进行删除。该操作除了删除configNode上的元信息外，还会删除所有AINode下的相关模型文件。其SQL如下：

需要指定已经成功注册的模型model_name来删除对应的模型。由于模型删除涉及多个节点上的数据删除，操作不会立即完成，此时模型的状态为DROPPING，该状态的模型不能用于模型推理。

SQL语法如下：

内置模型推理无需注册流程，通过call关键字，调用inference函数就可以使用模型的推理功能，其对应的参数介绍如下：

built_in_model_name: 内置模型名称
parameterName：参数名
parameterValue：参数值

目前已内置如下机器学习模型，具体参数说明请参考以下链接。

模型built_in_model_name任务类型参数说明Arima_Arima预测Arima参数说明STLForecaster_STLForecaster预测STLForecaster参数说明NaiveForecaster_NaiveForecaster预测NaiveForecaster参数说明ExponentialSmoothing_ExponentialSmoothing预测ExponentialSmoothing参数说明GaussianHMM_GaussianHMM标注GaussianHMM参数说明GMMHMM_GMMHMM标注GMMHMM参数说明Stray_Stray异常检测Stray参数说明

下面是使用内置模型推理的一个操作示例，使用内置的Stray模型进行异常检测算法，输入为，输出为，我们通过SQL使用其进行推理。

SQL语法如下：

在完成模型的注册后，通过call关键字，调用inference函数就可以使用模型的推理功能，其对应的参数介绍如下：

model_name: 对应一个已经注册的模型
sql：sql查询语句，查询的结果作为模型的输入进行模型推理。查询的结果中行列的维度需要与具体模型config中指定的大小相匹配。(这里的sql不建议使用子句，因为在IoTDB中，并不会对列进行排序，因此列的顺序是未定义的，可以使用的方式确保列的顺序符合模型输入的预期)
window_function: 推理过程中可以使用的窗口函数，目前提供三种类型的窗口函数用于辅助模型推理：
- head(window_size): 获取数据中最前的window_size个点用于模型推理，该窗口可用于数据裁剪
- tail(window_size)：获取数据中最后的window_size个点用于模型推，该窗口可用于数据裁剪
- count(window_size, sliding_step)：基于点数的滑动窗口，每个窗口的数据会分别通过模型进行推理，如下图示例所示，window_size为2的窗口函数将输入数据集分为三个窗口，每个窗口分别进行推理运算生成结果。该窗口可用于连续推理

说明1: window可以用来解决sql查询结果和模型的输入行数要求不一致时的问题，对行进行裁剪。需要注意的是，当列数不匹配或是行数直接少于模型需求时，推理无法进行，会返回错误信息。

说明2: 在深度学习应用中，经常将时间戳衍生特征（数据中的时间列）作为生成式任务的协变量，一同输入到模型中以提升模型的效果，但是在模型的输出结果中一般不包含时间列。为了保证实现的通用性，模型推理结果只对应模型的真实输出，如果模型不输出时间列，则结果中不会包含。

下面是使用深度学习模型推理的一个操作示例，针对上面提到的输入为，输出为的预测模型，我们通过SQL使用其进行推理。

当数据量不定且想要取96行最新数据用于推理时，可以使用对应的窗口函数tail。head函数的用法与其类似，不同点在于其取的是最早的96个点。

该窗口主要用于计算式任务，当任务对应的模型一次只能处理固定行数据而最终想要的确实多组预测结果时，使用该窗口函数可以使用点数滑动窗口进行连续推理。假设我们现在有一个异常检测模型anomaly_example(input: [24,2], output[1,1])，对每24行数据会生成一个0/1的标签，其使用示例如下：

其中结果集中每行的标签对应每24行数据为一组，输入该异常检测模型后的输出。

使用AINode相关的功能时，可以使用IoTDB本身的鉴权去做一个权限管理，用户只有在具备 USE_MODEL 权限时，才可以使用模型管理的相关功能。当使用推理功能时，用户需要有访问输入模型的SQL对应的源序列的权限。

权限名称权限范围管理员用户（默认ROOT）普通用户路径相关USE_MODELcreate model / show models / drop model√√xREAD_DATAcall inference√√√

在部分工业场景下，会存在预测电力负载的需求，预测结果可用于优化电力供应、节约能源和资源、支持规划和扩展以及增强电力系统的可靠性。

我们所使用的 ETTh1 的测试集的数据为ETTh1。

包含间隔1h采集一次的电力数据，每条数据由负载和油温构成，分别为：High UseFul Load, High UseLess Load, Middle UseLess Load, Low UseFul Load, Low UseLess Load, Oil Temperature。

在该数据集上，IoTDB-ML的模型推理功能可以通过以往高中低三种负载的数值和对应时间戳油温的关系，预测未来一段时间内的油温，赋能电网变压器的自动调控和监视。

用户可以使用tools文件夹中的向 IoTDB 中导入 ETT 数据集

我们可以在iotdb-cli 中输入以下SQL从 huggingface 上拉取一个已经训练好的模型进行注册，用于后续的推理。

该模型基于较为轻量化的深度模型DLinear训练而得，能够以相对快的推理速度尽可能多地捕捉到序列内部的变化趋势和变量间的数据变化关系，相较于其他更深的模型更适用于快速实时预测。

我们将对油温的预测的结果和真实结果进行对比，可以得到以下的图像。

图中10/24 00:00之前的数据为输入模型的过去数据，10/24 00:00后的蓝色线条为模型给出的油温预测结果，而红色为数据集中实际的油温数据（用于进行对比）。

可以看到，我们使用了过去96个小时（4天）的六个负载信息和对应时间油温的关系，基于之前学习到的序列间相互关系对未来48个小时（2天）的油温这一数据的可能变化进行了建模，可以看到可视化后预测曲线与实际结果在趋势上保持了较高程度的一致性。

变电站需要对电流、电压、功率等数据进行电力监控，用于检测潜在的电网问题、识别电力系统中的故障、有效管理电网负载以及分析电力系统的性能和趋势等。

我们利用某变电站中的电流、电压和功率等数据构成了真实场景下的数据集。该数据集包括变电站近四个月时间跨度，每5 - 6s 采集一次的 A相电压、B相电压、C相电压等数据。

测试集数据内容为data。

在该数据集上，IoTDB-ML的模型推理功能可以通过以往A相电压，B相电压和C相电压的数值和对应时间戳，预测未来一段时间内的C相电压，赋能变电站的监视管理。

用户可以使用tools文件夹中的导入数据集

我们可以在iotdb-cli 中选择内置模型或已经注册好的模型用于后续的推理。

我们采用内置模型STLForecaster进行预测，STLForecaster 是一个基于 statsmodels 库中 STL 实现的时间序列预测方法。

我们将对C相电压的预测的结果和真实结果进行对比，可以得到以下的图像。

图中 02/14 20:48 之前的数据为输入模型的过去数据， 02/14 20:48 后的蓝色线条为模型给出的C相电压预测结果，而红色为数据集中实际的C相电压数据（用于进行对比）。

可以看到，我们使用了过去10分钟的电压的数据，基于之前学习到的序列间相互关系对未来5分钟的C相电压这一数据的可能变化进行了建模，可以看到可视化后预测曲线与实际结果在趋势上保持了一定的同步性。

在民航交通运输业，存在着对乘机旅客数量进行异常检测的需求。异常检测的结果可用于指导调整航班的调度，以使得企业获得更大效益。

Airline Passengers一个时间序列数据集，该数据集记录了1949年至1960年期间国际航空乘客数量，间隔一个月进行一次采样。该数据集共含一条时间序列。数据集为airline。
在该数据集上，IoTDB-ML的模型推理功能可以通过捕捉序列的变化规律以对序列时间点进行异常检测，赋能交通运输业。

用户可以使用tools文件夹中的导入数据集

IoTDB内置有部分可以直接使用的机器学习算法，使用其中的异常检测算法进行预测的样例如下：

我们将检测为异常的结果进行绘制，可以得到以下图像。其中蓝色曲线为原时间序列，用红色点特殊标注的时间点为算法检测为异常的时间点。

可以看到，Stray模型对输入序列变化进行了建模，成功检测出出现异常的时间点。

触发器提供了一种侦听序列数据变动的机制。配合用户自定义逻辑，可完成告警、数据转发等功能。

触发器基于 Java 反射机制实现。用户通过简单实现 Java 接口，即可实现数据侦听。IoTDB 允许用户动态注册、卸载触发器，在注册、卸载期间，无需启停服务器。

IoTDB 的单个触发器可用于侦听符合特定模式的时间序列的数据变动，如时间序列 root.sg.a 上的数据变动，或者符合路径模式 root.**.a 的时间序列上的数据变动。您在注册触发器时可以通过 SQL 语句指定触发器侦听的路径模式。

目前触发器分为两类，您在注册触发器时可以通过 SQL 语句指定类型：

有状态的触发器。该类触发器的执行逻辑可能依赖前后的多条数据，框架会将不同节点写入的数据汇总到同一个触发器实例进行计算，来保留上下文信息，通常用于采样或者统计一段时间的数据聚合信息。集群中只有一个节点持有有状态触发器的实例。
无状态的触发器。触发器的执行逻辑只和当前输入的数据有关，框架无需将不同节点的数据汇总到同一个触发器实例中，通常用于单行数据的计算和异常检测等。集群中每个节点均持有无状态触发器的实例。

触发器的触发时机目前有两种，后续会拓展其它触发时机。您在注册触发器时可以通过 SQL 语句指定触发时机：

BEFORE INSERT，即在数据持久化之前触发。请注意，目前触发器并不支持数据清洗，不会对要持久化的数据本身进行变动。
AFTER INSERT，即在数据持久化之后触发。

触发器的逻辑需要您编写 Java 类进行实现。
在编写触发器逻辑时，需要使用到下面展示的依赖。如果您使用 Maven，则可以直接从 Maven 库中搜索到它们。请注意选择和目标服务器版本相同的依赖版本。

编写一个触发器需要实现类。

该类主要提供了两类编程接口：生命周期相关接口和数据变动侦听相关接口。该类中所有的接口都不是必须实现的，当您不实现它们时，它们不会对流经的数据操作产生任何响应。您可以根据实际需要，只实现其中若干接口。

下面是所有可供用户进行实现的接口的说明。

接口定义描述default void validate(TriggerAttributes attributes) throws Exception {}用户在使用语句创建触发器时，可以指定触发器需要使用的参数，该接口会用于验证参数正确性。default void onCreate(TriggerAttributes attributes) throws Exception {}当您使用语句创建触发器后，该接口会被调用一次。在每一个触发器实例的生命周期内，该接口会且仅会被调用一次。该接口主要有如下作用：帮助用户解析 SQL 语句中的自定义属性（使用）。可以创建或申请资源，如建立外部链接、打开文件等。default void onDrop() throws Exception {}当您使用语句删除触发器后，该接口会被调用。在每一个触发器实例的生命周期内，该接口会且仅会被调用一次。该接口主要有如下作用：可以进行资源释放的操作。可以用于持久化触发器计算的结果。default void restore() throws Exception {}当重启 DataNode 时，集群会恢复 DataNode 上已经注册的触发器实例，在此过程中会为该 DataNode 上的有状态触发器调用一次该接口。有状态触发器实例所在的 DataNode 宕机后，集群会在另一个可用 DataNode 上恢复该触发器的实例，在此过程中会调用一次该接口。该接口可以用于自定义恢复逻辑。

数据变动时，触发器以 Tablet 作为触发操作的单位。您可以通过 Tablet 获取相应序列的元数据和数据，然后进行相应的触发操作，触发成功则返回值应当为 true。该接口返回 false 或是抛出异常我们均认为触发失败。在触发失败时，我们会根据侦听策略接口进行相应的操作。

进行一次 INSERT 操作时，对于其中的每条时间序列，我们会检测是否有侦听该路径模式的触发器，然后将符合同一个触发器所侦听的路径模式的时间序列数据组装成一个新的 Tablet 用于触发器的 fire 接口。可以理解成：

请注意，目前我们不对触发器的触发顺序有任何保证。

下面是示例：

假设有三个触发器，触发器的触发时机均为 BEFORE INSERT

触发器 Trigger1 侦听路径模式：root.sg.*
触发器 Trigger2 侦听路径模式：root.sg.a
触发器 Trigger3 侦听路径模式：root.sg.b

写入语句：

序列 root.sg.a 匹配 Trigger1 和 Trigger2，序列 root.sg.b 匹配 Trigger1 和 Trigger3，那么：

root.sg.a 和 root.sg.b 的数据会被组装成一个新的 tablet1，在相应的触发时机进行 Trigger1.fire(tablet1)
root.sg.a 的数据会被组装成一个新的 tablet2，在相应的触发时机进行 Trigger2.fire(tablet2)
root.sg.b 的数据会被组装成一个新的 tablet3，在相应的触发时机进行 Trigger3.fire(tablet3)

在触发器触发失败时，我们会根据侦听策略接口设置的策略进行相应的操作，您可以通过下述接口设置，目前有乐观和悲观两种策略：

乐观策略：触发失败的触发器不影响后续触发器的触发，也不影响写入流程，即我们不对触发失败涉及的序列做额外处理，仅打日志记录失败，最后返回用户写入数据成功，但触发部分失败。
悲观策略：失败触发器影响后续所有 Pipeline 的处理，即我们认为该 Trigger 触发失败会导致后续所有触发流程不再进行。如果该触发器的触发时机为 BEFORE INSERT，那么写入也不再进行，直接返回写入失败。

您可以参考下图辅助理解，其中 Trigger1 配置采用乐观策略，Trigger2 配置采用悲观策略。Trigger1 和 Trigger2 的触发时机是 BEFORE INSERT，Trigger3 和 Trigger4 的触发时机是 AFTER INSERT。正常执行流程如下：

如果您使用 Maven，可以参考我们编写的示例项目 trigger-example。您可以在这里找到它。后续我们会加入更多的示例项目供您参考。

下面是其中一个示例项目的代码：

您可以通过 SQL 语句注册和卸载一个触发器实例，您也可以通过 SQL 语句查询到所有已经注册的触发器。

我们建议您在注册触发器时停止写入。

触发器可以注册在任意路径模式上。被注册有触发器的序列将会被触发器侦听，当序列上有数据变动时，触发器中对应的触发方法将会被调用。

注册一个触发器可以按如下流程进行：

按照编写触发器章节的说明，实现一个完整的 Trigger 类，假定这个类的全类名为
将项目打成 JAR 包。
使用 SQL 语句注册该触发器。注册过程中会仅只会调用一次触发器的和接口，具体请参考编写触发器章节。

完整 SQL 语法如下：

下面对 SQL 语法进行说明，您可以结合使用说明章节进行理解：

triggerName：触发器 ID，该 ID 是全局唯一的，用于区分不同触发器，大小写敏感。
triggerType：触发器类型，分为无状态（STATELESS）和有状态（STATEFUL）两类。
triggerEventClause：触发时机，目前仅支持写入前（BEFORE INSERT）和写入后（AFTER INSERT）两种。
pathPattern：触发器侦听的路径模式，可以包含通配符 * 和 **。
className：触发器实现类的类名。
uriClause：可选项，当不指定该选项时，我们默认 DBA 已经在各个 DataNode 节点的 trigger_root_dir 目录（配置项，默认为 IOTDB_HOME/ext/trigger）下放置好创建该触发器需要的 JAR 包。当指定该选项时，我们会将该 URI 对应的文件资源下载并分发到各 DataNode 的 trigger_root_dir/install 目录下。
triggerAttributeClause：用于指定触发器实例创建时需要设置的参数，SQL 语法中该部分是可选项。

下面是一个帮助您理解的 SQL 语句示例：

上述 SQL 语句创建了一个名为 triggerTest 的触发器：

该触发器是无状态的（STATELESS）
在写入前触发（BEFORE INSERT）
该触发器侦听路径模式为 root.sg.**
所编写的触发器类名为 org.apache.iotdb.trigger.ClusterAlertingExample
JAR 包的 URI 为 http://jar/ClusterAlertingExample.jar
创建该触发器实例时会传入 name 和 limit 两个参数。

可以通过指定触发器 ID 的方式卸载触发器，卸载触发器的过程中会且仅会调用一次触发器的接口。

卸载触发器的 SQL 语法如下：

下面是示例语句：

上述语句将会卸载 ID 为 triggerTest1 的触发器。

可以通过 SQL 语句查询集群中存在的触发器的信息。SQL 语法如下：

该语句的结果集格式如下：

TriggerNameEventTypeStatePathPatternClassNameNodeIdtriggerTest1BEFORE_INSERT / AFTER_INSERTSTATELESS / STATEFULINACTIVE / ACTIVE / DROPPING / TRANSFFERINGroot.**org.apache.iotdb.trigger.TriggerExampleALL(STATELESS) / DATA_NODE_ID(STATEFUL)

在集群中注册以及卸载触发器的过程中，我们维护了触发器的状态，下面是对这些状态的说明：

状态描述是否建议写入进行INACTIVE执行的中间状态，集群刚在 ConfigNode 上记录该触发器的信息，还未在任何 DataNode 上激活该触发器否ACTIVE执行成功后的状态，集群所有 DataNode 上的该触发器都已经可用是DROPPING执行的中间状态，集群正处在卸载该触发器的过程中否TRANSFERRING集群正在进行该触发器实例位置的迁移否

触发器从注册时开始生效，不对已有的历史数据进行处理。即只有成功注册触发器之后发生的写入请求才会被触发器侦听到。
触发器目前采用同步触发，所以编写时需要保证触发器效率，否则可能会大幅影响写入性能。您需要自己保证触发器内部的并发安全性。
集群中不能注册过多触发器。因为触发器信息全量保存在 ConfigNode 中，并且在所有 DataNode 都有一份该信息的副本。
建议注册触发器时停止写入。注册触发器并不是一个原子操作，注册触发器时，会出现集群内部分节点已经注册了该触发器，部分节点尚未注册成功的中间状态。为了避免部分节点上的写入请求被触发器侦听到，部分节点上没有被侦听到的情况，我们建议注册触发器时不要执行写入。
触发器将作为进程内程序执行，如果您的触发器编写不慎，内存占用过多，由于 IoTDB 并没有办法监控触发器所使用的内存，所以有 OOM 的风险。
持有有状态触发器实例的节点宕机时，我们会尝试在另外的节点上恢复相应实例，在恢复过程中我们会调用一次触发器类的 restore 接口，您可以在该接口中实现恢复触发器所维护的状态的逻辑。
触发器 JAR 包有大小限制，必须小于 min(, 2G)，其中是一个配置项，具体含义可以参考 IOTDB 配置项说明。
不同的 JAR 包中最好不要有全类名相同但功能实现不一样的类。例如：触发器 trigger1、trigger2 分别对应资源 trigger1.jar、trigger2.jar。如果两个 JAR 包里都包含一个类，当使用到这个类时，系统会随机加载其中一个 JAR 包中的类，最终导致触发器执行行为不一致以及其他的问题。

配置项含义trigger_lib_dir保存触发器 jar 包的目录位置stateful_trigger_retry_num_when_not_found有状态触发器触发无法找到触发器实例时的重试次数

连续查询(Continuous queries, aka CQ) 是对实时数据周期性地自动执行的查询，并将查询结果写入指定的时间序列中。

用户可以通过连续查询实现滑动窗口流式计算，如计算某个序列每小时平均温度，并写入一个新序列中。用户可以自定义子句去创建不同的滑动窗口，可以实现对于乱序数据一定程度的容忍。

注意：
如果where子句中出现任何时间过滤条件，IoTDB将会抛出异常，因为IoTDB会自动为每次查询执行指定时间范围。
GROUP BY TIME CLAUSE在连续查询中的语法稍有不同，它不能包含原来的第一个参数，即 [start_time, end_time)，IoTDB会自动填充这个缺失的参数。如果指定，IoTDB将会抛出异常。
如果连续查询中既没有GROUP BY TIME子句，也没有指定EVERY子句，IoTDB将会抛出异常。

为连续查询指定一个全局唯一的标识。
指定了连续查询周期性执行的间隔。现在支持的时间单位有：ns, us, ms, s, m, h, d, w, 并且它的值不能小于用户在配置文件中指定的。这是一个可选参数，默认等于group by子句中的。
指定了每次查询执行窗口的开始时间，即。现在支持的时间单位有：ns, us, ms, s, m, h, d, w。这是一个可选参数，默认等于子句中的。
指定了每次查询执行窗口的结束时间，即。现在支持的时间单位有：ns, us, ms, s, m, h, d, w。这是一个可选参数，默认等于.
表示用户期待的连续查询的首个周期任务的执行时间。（因为连续查询只会对当前实时的数据流做计算，所以该连续查询实际首个周期任务的执行时间并不一定等于用户指定的时间，具体计算逻辑如下所示）
- 可以早于、等于或者迟于当前时间。
- 这个参数是可选的，默认等于。
- 首次查询执行窗口的开始时间为.
- 首次查询执行窗口的结束时间为.
- 第i个查询执行窗口的时间范围是。
- 如果当前时间早于或等于, 那连续查询的首个周期任务的执行时间就是用户指定的.
- 如果当前时间迟于用户指定的，那么连续查询的首个周期任务的执行时间就是中第一个大于或等于当前时间的值。

<every_interval>，<start_time_offset> 和 <group_by_interval> 都应该大于 0
<group_by_interval>应该小于等于<start_time_offset>
用户应该根据实际需求，为<start_time_offset> 和 <every_interval> 指定合适的值
如果<start_time_offset>大于<every_interval>，在每一次查询执行的时间窗口上会有部分重叠
如果<start_time_offset>小于<every_interval>，在连续的两次查询执行的时间窗口中间将会有未覆盖的时间范围
start_time_offset 应该大于end_time_offset

指定了我们如何处理“前一个时间窗口还未执行完时，下一个窗口的执行时间已经到达的场景，默认值是.
- 意味着即使下一个窗口的执行时间已经到达，我们依旧需要阻塞等待前一个时间窗口的查询执行完再开始执行下一个窗口。如果使用策略，所有的时间窗口都将会被依此执行，但是如果遇到执行查询的时间长于周期性间隔时，连续查询的结果会迟于最新的时间窗口范围。
- 意味着如果前一个时间窗口还未执行完，我们会直接丢弃下一个窗口的执行时间。如果使用策略，可能会有部分时间窗口得不到执行。但是一旦前一个查询执行完后，它将会使用最新的时间窗口，所以它的执行结果总能赶上最新的时间窗口范围，当然是以部分时间窗口得不到执行为代价。

下面是用例数据，这是一个实时的数据流，我们假设数据都按时到达。

在子句中使用参数指定连续查询的执行间隔，如果没有指定，默认等于。

计算出传感器每10秒的平均值，并且将查询结果存储在传感器下，传感器路径前缀使用跟原来一样的前缀。

每20秒执行一次，每次执行的查询的时间窗口范围是从过去20秒到当前时间。