在实时数据库的流计算体系中，触发机制决定了数据处理的时机和粒度，窗口策略则定义了数据聚合的边界。合理选择触发方式和窗口配置，是构建高效流计算管道的关键。本文将深入解析流计算的六种触发方式、三种动作模式以及核心控制选项，帮助开发者在不同业务场景下做出最优配置。
六种触发方式详解
1. 定时触发 PERIOD
定时触发是最基础的触发方式，通过系统时间以固定间隔驱动计算。其时间基准为建流当天的系统时间零点，此后按照设定的周期持续触发。
这种方式适用于对时间精度要求较高、数据到达相对均匀的场景。例如，每小时统计一次设备运行指标，或每分钟计算一次平均温度。
CREATE STREAM sm1 PERIOD(1h) INTO tb2 AS
SELECT cast(_tlocaltime/1000000 AS TIMESTAMP), count(*)
FROM tb1;上述示例创建了一个每小时触发一次的流计算，将统计结果写入输出表tb2中。需要注意的是，定时触发依赖系统时间，与数据写入时间无关，因此即使没有新数据写入，也会按周期触发计算。
2. 滑动触发 INTERVAL SLIDING
滑动触发基于触发表的数据写入事件，按照事件时间以固定间隔驱动计算。与定时触发不同，滑动触发是数据驱动的，只有在有新数据写入时才会触发。
滑动触发支持两个参数：INTERVAL定义窗口大小，SLIDING定义滑动步长。当两者相等时，窗口之间没有重叠；当SLIDING小于INTERVAL时，窗口之间存在重叠，适用于需要平滑计算结果的场景。
CREATE STREAM sm1 INTERVAL(5m) SLIDING(5m) FROM stb1
PARTITION BY tbname INTO stb2 AS
SELECT _twstart, avg(col1) FROM %%tbname
WHERE _c0 >= _twstart AND _c0 <= _twend;该示例以5分钟为窗口和滑动步长，对超级表stb1中的数据按子表分组计算平均值。在工业数据管理平台中，滑动触发常用于设备指标的滚动统计。
3. 会话窗口触发 SESSION
会话窗口按照数据活跃度划分窗口边界。当数据持续到达时，窗口保持打开状态；当超过设定的间隔时间没有新数据到达时，窗口关闭并触发计算。
这种方式特别适用于用户行为分析、设备运行周期识别等场景，其中活动的持续时间不固定，但活动之间有明确的间隔。
4. 状态窗口触发 STATE_WINDOW
状态窗口根据数据字段值的变化来划分窗口。当指定字段的值发生变化时，当前窗口关闭，新窗口打开。这种方式适用于设备状态监控场景，例如当设备从”运行”状态切换到”停机”状态时，分别统计两种状态下的运行指标。
5. 事件窗口触发 EVENT_WINDOW
事件窗口通过定义事件的开始和结束条件来划分窗口。当满足开始条件时窗口启动，满足结束条件时窗口关闭并触发计算。同时支持TRUE_FOR参数，要求条件必须持续满足指定时长才触发窗口状态变更。
CREATE STREAM ana_temp
EVENT_WINDOW(start with 环境温度 > 80 end with 环境温度 <= 80)
TRUE_FOR(10m)
FROM vt_气象传感器02_471544 INTO ana_temp AS
SELECT _twstart+0s as output_timestamp, avg(环境温度) as 平均环境温度
FROM vt_气象传感器02_471544
where ts >= _twstart and ts <= _twend;上述示例定义了一个事件窗口：当环境温度持续超过80度达10分钟时启动窗口，温度降至80度及以下时关闭窗口，并计算窗口内的平均温度。在时序数据库的告警场景中，事件窗口能够有效过滤短暂的波动干扰。
6. 计数窗口触发 COUNT_WINDOW
计数窗口按照数据条数来划分窗口边界，支持列触发机制。当写入的数据条数达到设定阈值时，触发一次计算。
CREATE STREAM sm1 COUNT_WINDOW(1) FROM tb1 INTO tb3 AS
SELECT _twstart, avg(col1) FROM tb2
WHERE _c0 >= _twend - 5m AND _c0 <= _twend;该示例每收到1条数据就触发一次计算，适用于对数据到达频率敏感的场景。计数窗口特别适合低频数据采集场景，确保每条数据都能被及时处理。
三种触发动作模式
流计算触发后的动作分为三种模式，满足不同的业务需求：
| 模式 | 说明 | 适用场景 |
|---|---|---|
| 只通知不计算 | 通过WebSocket发送事件通知 | 告警通知、状态变更提醒 |
| 只计算不通知 | 执行查询并保存结果到输出表 | 数据聚合、指标统计 |
| 既通知又计算 | 执行查询同时发送通知 | 需要即时响应的监控场景 |
在实时数据库的应用中，选择合适的动作模式可以有效降低系统负载。例如，对于仅需要告警通知的场景，选择”只通知不计算”可以避免不必要的计算开销。
触发表与分组机制
流计算的输出表数量与触发表的分组个数直接相关。当使用PARTITION BY指定分组时，每个分组会产生一个对应的输出表；未指定分组时，整个流计算只产生一个输出表。
这种设计保证了数据隔离性，不同设备或不同维度的计算结果分别存储，便于后续查询和分析。在工业物联网场景中，通常按设备分组，每个设备拥有独立的输出表。
控制选项详解
流计算提供了丰富的控制选项，用于处理实际业务中的复杂情况。
WATERMARK 与乱序处理
WATERMARK定义了数据乱序容忍时长。在分布式系统中，数据到达的顺序可能与事件发生顺序不一致。通过设置WATERMARK，系统会等待指定时长后再关闭窗口，允许迟到的数据被纳入计算。
配合IGNORE_DISORDER选项，可以选择忽略超过乱序容忍时长的数据，避免因少量迟到数据导致大规模重新计算。
EXPIRED_TIME
EXPIRED_TIME定义了过期数据的间隔，超过该时间的数据将被丢弃，不再参与计算。这一选项对于存储资源有限的边缘计算场景尤为重要。
FILL_HISTORY
FILL_HISTORY选项允许从指定时间开始触发历史数据计算，适用于流计算创建后需要回填历史数据的场景。在时序数据库的实际部署中，这一功能可以避免新建流计算时的数据空白期。
LOW_LATENCY_CALC
LOW_LATENCY_CALC启用低延迟计算模式，减少计算结果的输出延迟。在对实时性要求极高的场景中，该选项可以显著提升响应速度。
PRE_FILTER
PRE_FILTER在触发计算前对数据进行过滤，减少参与计算的数据量。通过预先过滤无关数据，可以有效降低计算开销，提升整体处理吞吐量。
MAX_DELAY
MAX_DELAY定义了窗口未关闭时的最长等待时长。当窗口等待时间超过该值时，即使条件未完全满足也会强制关闭窗口并触发计算，防止窗口长时间不关闭导致的结果延迟。
重新计算机制
在实际运行中，数据乱序、更新和删除操作可能导致已计算结果不准确。流计算通过WATERMARK机制支持自动重新计算：当迟到数据到达时，系统会自动重新计算受影响的窗口结果。
同时也支持手动触发重新计算，适用于数据修正后的批量回算场景。这种机制保证了计算结果的最终一致性，是构建可靠流计算管道的重要保障。
总结
流计算的触发机制和窗口策略是实时数据库处理时序数据的核心能力。六种触发方式覆盖了时间驱动、数据驱动、状态驱动等多种业务场景，三种动作模式提供了灵活的响应策略，丰富的控制选项则确保了系统在复杂环境下的稳定运行。结合TDengine的流计算引擎，开发者可以基于SQL快速构建高效的实时数据处理管道，满足工业物联网、智能运维等场景的多样化需求。
