尧图网站建设 
TDengine 流式计算运维实战高可用、权限、重算与限制全解析【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengineTDengine 的流式计算Stream Processing采用计算与存储分离架构所有计算逻辑统一由 snode 执行。本文以官方运维指南《Operations and Limits》为主体系统讲解流计算任务部署 snode 的高可用方案、数据库级权限模型、WATERMARK 与重算机制、乱序/更新/删除等非典型数据摄入场景的处置策略以及全套配置参数、规则限制与升级兼容步骤帮助读者在生产环境中正确规划、监控与运维 TDengine 流计算任务。输出文章TDengine 流式计算运维实战高可用、权限、重算与限制全解析TDengine 的流式计算Stream Processing采用计算与存储分离架构所有流计算任务统一由 snode 节点执行。本文围绕官方运维指南 02-instructions.md 展开系统讲解 snode 部署与高可用、流任务权限模型、WATERMARK 与重算机制、乱序/更新/删除/过期数据等非典型摄入场景的处置策略以及全部配置参数、规则限制与版本升级兼容步骤帮助你在生产环境中正确规划、监控和运维 TDengine 流计算任务。总览流计算的其他特性与注意事项TDengine 流计算在架构上与存储彻底分离除数据读取外流处理的全部环节都在 snode 上完成因此集群中必须至少部署一个 snode。围绕这一架构运维者还需要掌握高可用部署、权限控制、重算机制、特殊数据场景处理、库表操作影响、配置参数与限制规则等一组关键知识。下文按官方指南的顺序逐项展开。高可用High Availability架构前提流计算任务可以视为事件驱动的有状态计算数据写入触发表后产生事件事件驱动窗口计算计算结果写入输出表。为了支撑这种模式TDengine 要求集群中至少部署一个 snode且创建流任务时必须有处于可用Running状态的 snode除数据读取外所有流计算功能仅在 snode 上执行每个 dnode 上最多部署一个 snode每个 snode 拥有多个执行线程。从源码结构看snode 由独立的 mgmt 模块管理smInt.h 中的SSnodeInfo维护了 snodeId、双 leader 的SNodeEpSet以及副本snodeReplica而 CREATE/DROP SNODE 则通过独立的内部消息类型TDMT_MND_CREATE_SNODE/TDMT_MND_DROP_SNODE见 msgTypeTable.ini在 mnode 与 dnode 之间流转最终由 mgmt_snode 模块落地执行。资源隔离与多副本建议snode 可以与 vnode、mnode 等节点类型共存于同一 dnode。但为了资源隔离强烈建议将 snode 部署在独立的 dnode 上确保流计算不会显著干扰写入、查询等其他操作。为保证流计算高可用建议在集群的不同物理节点上部署多个 snode流任务在多个 snode 之间负载均衡每对 snode 互为副本互相保存流状态与进度信息若集群只部署单个 snode则系统无法保证高可用。部署 / 查看 / 删除 Snode创建流任务前必须先部署 snodeCREATE SNODE ON DNODE dnode_id;查看所有 snodeSHOW SNODES;查看更详细的信息SELECT * FROM information_schema.ins_snodes;删除 snode 时要求 snode 及其副本同时在线以同步流状态信息若其中任一离线删除将失败DROP SNODE ON DNODE dnode_id;权限控制Permission Control流计算的权限控制只与数据库级权限相关。由于一个流可能关联多个数据库定义库、触发表库、输出表库、计算源库各项操作所需的权限如下关联数据库数量操作所需权限流定义所在数据库1创建、删除、停止、启动、手动重算Write触发表所在数据库1创建Read输出表所在数据库1创建Write计算源数据库1 个或多个创建Read可以看到流任务本身归定义库管理凡是对流任务生命周期或重算的干预都需要该库的 Write 权限而触发表、计算源所在的库只需要 Read 权限因为流只读取其中数据输出表所在库需要 Write 权限因为流要向其写入计算结果。重算Recomputation为什么要重算WATERMARK 的边界TDengine 的大多数 TSDB 窗口类型与主键时间戳列相关。例如事件窗口EVENT_WINDOW依赖按主键有序的数据来决定窗口何时开启与关闭。使用窗口类触发时触发表数据应当有序写入这样才能保证流计算最高效若写入乱序数据可能影响已触发窗口的结果正确性同样数据更新与删除也可能破坏结果正确性。为此 TDengine 支持通过WATERMARK水印缓解乱序、更新与删除带来的问题WATERMARK 是用户基于事件时间定义的时长代表系统流处理的进度反映了用户对乱序数据的容忍度当前水印定义为最近已处理事件时间 – WATERMARK 时长只有事件时间早于当前水印的数据才具备触发评估资格同样只有时间边界早于当前水印的窗口或其他触发条件才会被触发注意WATERMARK 不适用于 PERIOD定时触发PERIOD 模式下不进行重算。对于超出 WATERMARK 容忍范围的乱序、更新或删除场景需要借助重算Recalculation来保证结果正确性。重算的含义是对受乱序、更新或删除记录影响的数据区间重新触发并重新执行计算。已经写入输出表的结果不会被删除而是再次写入新结果。因此使用者必须保证计算语句与源表不依赖处理时间processing time——即同一触发条件即使被多次执行也应产生有效结果。重算分为自动与手动两种若不需要自动重算可通过配置项关闭。手动重算手动重算必须由用户显式发起可通过 SQL 命令启动RECALCULATE STREAM [db_name.]stream_name FROM start_time [TO end_time];使用注意点可指定基于事件时间的重算时间范围若不指定 end_time则重算范围从 start_time 一直延伸到发起手动重算时刻流的当前处理进度。手动重算不支持定时触发PERIOD但支持其他所有触发类型。对计数窗口触发COUNT_WINDOW而言start_time 与 end_time 都必须指定且重算只作用于流已经处理过的区间若指定范围包含流尚未开始处理的区间这部分会被自动忽略。重算过程中会在指定区间内重新划分触发窗口可能导致新窗口与先前计算的窗口错位因此用户可能需要手动删除该区间在输出表中的已有结果以避免重复结果。同理若不指定 end_time重算请求将被忽略。对于从某个起始时间开始、无明确结束的重算场景官方推荐的做法是删除流、重新创建并指定FILL_HISTORY_FIRST。SQL 返回成功只表示重算请求已被接受并不代表重算已经完成。请使用recalc_id与information_schema.ins_stream_recalculates监控请求进度。重算在后台运行。若在请求到达终态前服务或流任务发生重启/重新部署未完成的请求会被恢复并继续处理。瞬时执行失败会自动重试。不要因为请求仍处于Pending或Running状态就重复提交同一个请求应先查看status、progress与message。从实现看重算请求是解析器、节点与执行器协同工作的完整链路RECALCULATE STREAM语句在语法解析阶段生成QUERY_NODE_RECALCULATE_STREAM_STMT节点见 parAstCreater.c随后由 nodesUtilFuncs.c 序列化为消息下发执行系统表 systable.c 中注册了recalc_id字段配合information_schema.ins_stream_recalculates视图即可查询每次重算请求的状态与进度。非典型数据摄入场景Atypical Data Ingestion Scenarios乱序数据Out-of-Order Data乱序数据指以非时间顺序写入触发表的记录。计算本身不依赖源表是否有序但用户必须依据业务需求确保源表数据在触发发生前已完整写入。乱序数据的影响与处理因触发类型而异触发类型影响与处理定时触发PERIOD滑动触发SLIDING滑动步长不为 1 的计数窗口触发忽略不执行任何处理滑动步长为 1 的计数窗口触发如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)默认通过重算处理。可选通过STREAM_OPTIONS(IGNORE_DISORDER)忽略其他窗口触发默认通过重算处理。可选忽略不执行任何处理数据更新Data Updates数据更新指对同一时间戳的记录多次写入其他列的值可能变化也可能不变。更新操作只影响触发表与触发行为不直接影响计算过程本身触发类型影响与处理定时触发PERIOD滑动触发SLIDING滑动步长不为 1 的计数窗口触发忽略不执行任何处理滑动步长为 1 的计数窗口触发如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)默认视为乱序数据通过重算处理。可选通过STREAM_OPTIONS(IGNORE_DISORDER)忽略其他窗口触发视为乱序数据通过重算处理数据删除Data Deletions数据删除只影响触发表与触发行为不直接影响计算过程触发类型影响与处理定时触发PERIOD滑动触发SLIDING滑动步长不为 1 的计数窗口触发忽略不执行任何处理滑动步长为 1 的计数窗口触发如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)默认忽略不执行任何处理。可选通过STREAM_OPTIONS(DELETE_RECALC)视为乱序数据并重算其他窗口触发默认忽略不执行任何处理。可选视为乱序数据并重算过期数据Expired Dataexpired_time设置定义了一个数据过期时间区间。对每次流触发产生的每个分组系统通过比较最新数据的事件时间与过期阈值来判断新数据是否过期阈值为最新事件时间 – expired_time早于该阈值的数据均视为过期数据。关于过期数据需要理解以下几点过期数据只作用于触发表中的实时数据。历史数据与其他表的数据不存在过期概念。过期性在流触发时评估数据是否过期取决于其写入时机按事件时间有序写入的数据永远不会过期只有乱序数据可能被判定为过期。过期数据不会自动触发新的计算或重算即所有触发类型下过期数据都会被忽略不计算、不重算。如果不需要排除任何计算或重算的时间区间就无需指定expired_time。若已定义过期数据但仍希望对其中一部分进行计算或重算可以使用手动重算。过期数据只影响是否发生自动触发不影响计算范围本身。因此如果某次触发被判定为需要计算而触发表计算范围内恰好包含过期数据这些数据仍会被用于计算。从实现看snode 侧的任务结构中直接保存了expiredTime见 streamTriggerTask.c并在计算区间裁剪时使用oldThreshold - expiredTime作为范围下界streamTriggerTask.c可见阈值裁剪正是过期数据被排除在触发评估之外的核心实现手段。流创建后的库表操作Database and Table Operations流创建后用户可能对与之关联的数据库与表执行各种操作。下表汇总了这些操作对流的影响及流的处理方式操作影响与流的处理用户在触发超级表非虚拟表下新建子表并写入数据新子表自动纳入当前流处理或加入已有分组或创建新分组用户在虚拟触发超级表下新建子表并写入数据忽略不做额外处理用户删除触发超级表的子表默认忽略。可选部分触发类型可配置为自动重算或删除对应结果表仅适用于按子表分组的流。对ROLLUP BY流已生成的输出子表会保留用户删除触发表忽略不做额外处理用户给触发表增加列忽略不做额外处理用户删除触发表的列忽略不做额外处理用户修改触发超级表下子表的标签值若该标签列被流用作分组键操作不被允许并报错否则忽略用户修改触发表的列 schema忽略不做额外处理读取时发现 schema 不匹配会报错用户修改或删除源表忽略不做额外处理用户修改或删除输出表忽略不做额外处理写入时发现 schema 不匹配会报错若表不存在将重新创建用户拆分 vnode若 vnode 所在数据库是源库或触发表库不允许若使用虚拟表进行触发或计算不允许用户确认无影响后可用SPLIT VGROUP N FORCE强制执行用户删除数据库若被删数据库是流的源库或是不与流自身数据库相同的触发表库不允许若流对非目标库的虚拟表进行触发或计算不允许用户确认无影响后可用DROP DATABASE name FORCE强制执行除上表明确限制或特殊处理的操作外其余操作包括表中标记为忽略不做额外处理的均不受限制。但若这些操作可能影响流计算应由用户自行决定如何处理要么忽略影响要么执行一次手动重算以恢复正确性。配置参数Configuration Parameters流计算相关配置参数全部在服务端 taosd 中注册生效见 tglobal.c 与 tglobal.c。以下是参数清单及其在源码中注册的默认值与取值范围参数名作用默认值 / 范围来自 tglobal.cnumOfMnodeStreamMgmtThreadsmnode 上的流管理线程数默认 2范围 [2, 5]numOfStreamMgmtThreadsvnode/snode 上的流管理线程数默认 2范围 [2, 5]numOfVnodeStreamReaderThreadsvnode 上的流读取线程数默认 2范围 [2, INT32_MAX]numOfStreamTriggerThreads流触发线程数默认 4范围 [4, INT32_MAX]numOfStreamRunnerThreads流执行线程数默认 4范围 [4, INT32_MAX]streamBufferSize流处理可用最大缓冲区仅用于缓存%%trows结果单位 MB默认 128范围 [128, INT32_MAX]streamNotifyMessageSize控制事件通知消息的大小默认 8范围 [8, 1MB]streamNotifyFrameSize控制发送事件通知消息时底层帧的大小默认 8范围 [8, 1MB]上表默认值与取值范围直接取自当前仓库 tglobal.c 中的cfgAddInt32注册信息与官方文档保持一致并做了补充配置的完整说明可参见 taosd 组件文档。多数参数为CFG_DYN_SERVER_LAZY类型支持在线热更新后逐步生效。规则与限制Rules and Limitations创建与运行流任务时必须遵守以下规则创建流之前集群必须至少部署一个 snode且创建时必须有可用的正在运行的snode。每个流属于一个特定数据库因此创建流之前数据库必须已存在且同一数据库内流名称不能重复。流的触发表与源表可以相同也可以不同且可以分属不同数据库。流的输出表可以位于与流、触发表或源表不同的数据库但不能与触发表或源表相同。输出表超级表或普通表在流创建时自动创建若想写入已存在的表其 schema 必须完全一致。每个分组的输出子表无需预先创建计算写结果时会自动创建。每个触发分组的计算结果写入同一个子表若未指定分组所有结果写入单张普通表。若不同分组被配置为生成同名的子表其结果会写入同一张子表。用户必须确认这是预期行为否则应确保每个分组生成唯一命名的子表。除指定子表名外用户还可以定义输出超级表的标签列以及每个子表的标签值。流处理支持嵌套即可以基于已有流的输出表创建新的流。对滑动步长不为 1 的计数窗口触发乱序、更新、删除都会被忽略步长为 1如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)时乱序与更新默认触发重算、可用IGNORE_DISORDER忽略删除默认忽略、可用DELETE_RECALC触发重算。在非FILL_HISTORY_FIRST模式下历史窗口与实时窗口可能不对齐。对超级表窗口触发只有区间窗口INTERVAL与会话窗口SESSION支持按标签、按 rollup 标签、按子表分组或不分组其他窗口类型只支持按子表分组。ROLLUP BY与PARTITION BY、DELETE_OUTPUT_TABLE互斥。查询中不支持伪列 qstart、qend、qduration。临时限制Temporary Restrictions暂不支持按普通数据列分组。暂不支持 Geometry 数据类型。NOTIFY_OPTIONS中的ON_FAILURE_PAUSE选项暂不支持。兼容性说明Compatibility Notes与v3.3.6.0相比流计算已完成彻底重设计。从旧版本升级前必须执行以下步骤之后在新版流计算下重新创建流删除所有已有的流计算任务删除所有 TSMA删除所有 snode移除 snode 相关目录dataDir 配置路径下的 snode 目录默认/var/lib/taos/snode旧版checkpointBackupDir配置项指定的目录默认/var/lib/taos/backup/checkpoint/删除所有结果表。注意如果不执行上述步骤taosd 将无法启动。请在升级窗口内完成迁移后再以新版流计算语法见 流语法文档重新创建流任务。【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TDengine 流式计算运维实战：高可用、权限、重算与限制全解析
TDengine 流式计算运维实战高可用、权限、重算与限制全解析【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengineTDengine 的流式计算Stream Processing采用计算与存储分离架构所有计算逻辑统一由 snode 执行。本文以官方运维指南《Operations and Limits》为主体系统讲解流计算任务部署 snode 的高可用方案、数据库级权限模型、WATERMARK 与重算机制、乱序/更新/删除等非典型数据摄入场景的处置策略以及全套配置参数、规则限制与升级兼容步骤帮助读者在生产环境中正确规划、监控与运维 TDengine 流计算任务。输出文章TDengine 流式计算运维实战高可用、权限、重算与限制全解析TDengine 的流式计算Stream Processing采用计算与存储分离架构所有流计算任务统一由 snode 节点执行。本文围绕官方运维指南 02-instructions.md 展开系统讲解 snode 部署与高可用、流任务权限模型、WATERMARK 与重算机制、乱序/更新/删除/过期数据等非典型摄入场景的处置策略以及全部配置参数、规则限制与版本升级兼容步骤帮助你在生产环境中正确规划、监控和运维 TDengine 流计算任务。总览流计算的其他特性与注意事项TDengine 流计算在架构上与存储彻底分离除数据读取外流处理的全部环节都在 snode 上完成因此集群中必须至少部署一个 snode。围绕这一架构运维者还需要掌握高可用部署、权限控制、重算机制、特殊数据场景处理、库表操作影响、配置参数与限制规则等一组关键知识。下文按官方指南的顺序逐项展开。高可用High Availability架构前提流计算任务可以视为事件驱动的有状态计算数据写入触发表后产生事件事件驱动窗口计算计算结果写入输出表。为了支撑这种模式TDengine 要求集群中至少部署一个 snode且创建流任务时必须有处于可用Running状态的 snode除数据读取外所有流计算功能仅在 snode 上执行每个 dnode 上最多部署一个 snode每个 snode 拥有多个执行线程。从源码结构看snode 由独立的 mgmt 模块管理smInt.h 中的SSnodeInfo维护了 snodeId、双 leader 的SNodeEpSet以及副本snodeReplica而 CREATE/DROP SNODE 则通过独立的内部消息类型TDMT_MND_CREATE_SNODE/TDMT_MND_DROP_SNODE见 msgTypeTable.ini在 mnode 与 dnode 之间流转最终由 mgmt_snode 模块落地执行。资源隔离与多副本建议snode 可以与 vnode、mnode 等节点类型共存于同一 dnode。但为了资源隔离强烈建议将 snode 部署在独立的 dnode 上确保流计算不会显著干扰写入、查询等其他操作。为保证流计算高可用建议在集群的不同物理节点上部署多个 snode流任务在多个 snode 之间负载均衡每对 snode 互为副本互相保存流状态与进度信息若集群只部署单个 snode则系统无法保证高可用。部署 / 查看 / 删除 Snode创建流任务前必须先部署 snodeCREATE SNODE ON DNODE dnode_id;查看所有 snodeSHOW SNODES;查看更详细的信息SELECT * FROM information_schema.ins_snodes;删除 snode 时要求 snode 及其副本同时在线以同步流状态信息若其中任一离线删除将失败DROP SNODE ON DNODE dnode_id;权限控制Permission Control流计算的权限控制只与数据库级权限相关。由于一个流可能关联多个数据库定义库、触发表库、输出表库、计算源库各项操作所需的权限如下关联数据库数量操作所需权限流定义所在数据库1创建、删除、停止、启动、手动重算Write触发表所在数据库1创建Read输出表所在数据库1创建Write计算源数据库1 个或多个创建Read可以看到流任务本身归定义库管理凡是对流任务生命周期或重算的干预都需要该库的 Write 权限而触发表、计算源所在的库只需要 Read 权限因为流只读取其中数据输出表所在库需要 Write 权限因为流要向其写入计算结果。重算Recomputation为什么要重算WATERMARK 的边界TDengine 的大多数 TSDB 窗口类型与主键时间戳列相关。例如事件窗口EVENT_WINDOW依赖按主键有序的数据来决定窗口何时开启与关闭。使用窗口类触发时触发表数据应当有序写入这样才能保证流计算最高效若写入乱序数据可能影响已触发窗口的结果正确性同样数据更新与删除也可能破坏结果正确性。为此 TDengine 支持通过WATERMARK水印缓解乱序、更新与删除带来的问题WATERMARK 是用户基于事件时间定义的时长代表系统流处理的进度反映了用户对乱序数据的容忍度当前水印定义为最近已处理事件时间 – WATERMARK 时长只有事件时间早于当前水印的数据才具备触发评估资格同样只有时间边界早于当前水印的窗口或其他触发条件才会被触发注意WATERMARK 不适用于 PERIOD定时触发PERIOD 模式下不进行重算。对于超出 WATERMARK 容忍范围的乱序、更新或删除场景需要借助重算Recalculation来保证结果正确性。重算的含义是对受乱序、更新或删除记录影响的数据区间重新触发并重新执行计算。已经写入输出表的结果不会被删除而是再次写入新结果。因此使用者必须保证计算语句与源表不依赖处理时间processing time——即同一触发条件即使被多次执行也应产生有效结果。重算分为自动与手动两种若不需要自动重算可通过配置项关闭。手动重算手动重算必须由用户显式发起可通过 SQL 命令启动RECALCULATE STREAM [db_name.]stream_name FROM start_time [TO end_time];使用注意点可指定基于事件时间的重算时间范围若不指定 end_time则重算范围从 start_time 一直延伸到发起手动重算时刻流的当前处理进度。手动重算不支持定时触发PERIOD但支持其他所有触发类型。对计数窗口触发COUNT_WINDOW而言start_time 与 end_time 都必须指定且重算只作用于流已经处理过的区间若指定范围包含流尚未开始处理的区间这部分会被自动忽略。重算过程中会在指定区间内重新划分触发窗口可能导致新窗口与先前计算的窗口错位因此用户可能需要手动删除该区间在输出表中的已有结果以避免重复结果。同理若不指定 end_time重算请求将被忽略。对于从某个起始时间开始、无明确结束的重算场景官方推荐的做法是删除流、重新创建并指定FILL_HISTORY_FIRST。SQL 返回成功只表示重算请求已被接受并不代表重算已经完成。请使用recalc_id与information_schema.ins_stream_recalculates监控请求进度。重算在后台运行。若在请求到达终态前服务或流任务发生重启/重新部署未完成的请求会被恢复并继续处理。瞬时执行失败会自动重试。不要因为请求仍处于Pending或Running状态就重复提交同一个请求应先查看status、progress与message。从实现看重算请求是解析器、节点与执行器协同工作的完整链路RECALCULATE STREAM语句在语法解析阶段生成QUERY_NODE_RECALCULATE_STREAM_STMT节点见 parAstCreater.c随后由 nodesUtilFuncs.c 序列化为消息下发执行系统表 systable.c 中注册了recalc_id字段配合information_schema.ins_stream_recalculates视图即可查询每次重算请求的状态与进度。非典型数据摄入场景Atypical Data Ingestion Scenarios乱序数据Out-of-Order Data乱序数据指以非时间顺序写入触发表的记录。计算本身不依赖源表是否有序但用户必须依据业务需求确保源表数据在触发发生前已完整写入。乱序数据的影响与处理因触发类型而异触发类型影响与处理定时触发PERIOD滑动触发SLIDING滑动步长不为 1 的计数窗口触发忽略不执行任何处理滑动步长为 1 的计数窗口触发如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)默认通过重算处理。可选通过STREAM_OPTIONS(IGNORE_DISORDER)忽略其他窗口触发默认通过重算处理。可选忽略不执行任何处理数据更新Data Updates数据更新指对同一时间戳的记录多次写入其他列的值可能变化也可能不变。更新操作只影响触发表与触发行为不直接影响计算过程本身触发类型影响与处理定时触发PERIOD滑动触发SLIDING滑动步长不为 1 的计数窗口触发忽略不执行任何处理滑动步长为 1 的计数窗口触发如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)默认视为乱序数据通过重算处理。可选通过STREAM_OPTIONS(IGNORE_DISORDER)忽略其他窗口触发视为乱序数据通过重算处理数据删除Data Deletions数据删除只影响触发表与触发行为不直接影响计算过程触发类型影响与处理定时触发PERIOD滑动触发SLIDING滑动步长不为 1 的计数窗口触发忽略不执行任何处理滑动步长为 1 的计数窗口触发如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)默认忽略不执行任何处理。可选通过STREAM_OPTIONS(DELETE_RECALC)视为乱序数据并重算其他窗口触发默认忽略不执行任何处理。可选视为乱序数据并重算过期数据Expired Dataexpired_time设置定义了一个数据过期时间区间。对每次流触发产生的每个分组系统通过比较最新数据的事件时间与过期阈值来判断新数据是否过期阈值为最新事件时间 – expired_time早于该阈值的数据均视为过期数据。关于过期数据需要理解以下几点过期数据只作用于触发表中的实时数据。历史数据与其他表的数据不存在过期概念。过期性在流触发时评估数据是否过期取决于其写入时机按事件时间有序写入的数据永远不会过期只有乱序数据可能被判定为过期。过期数据不会自动触发新的计算或重算即所有触发类型下过期数据都会被忽略不计算、不重算。如果不需要排除任何计算或重算的时间区间就无需指定expired_time。若已定义过期数据但仍希望对其中一部分进行计算或重算可以使用手动重算。过期数据只影响是否发生自动触发不影响计算范围本身。因此如果某次触发被判定为需要计算而触发表计算范围内恰好包含过期数据这些数据仍会被用于计算。从实现看snode 侧的任务结构中直接保存了expiredTime见 streamTriggerTask.c并在计算区间裁剪时使用oldThreshold - expiredTime作为范围下界streamTriggerTask.c可见阈值裁剪正是过期数据被排除在触发评估之外的核心实现手段。流创建后的库表操作Database and Table Operations流创建后用户可能对与之关联的数据库与表执行各种操作。下表汇总了这些操作对流的影响及流的处理方式操作影响与流的处理用户在触发超级表非虚拟表下新建子表并写入数据新子表自动纳入当前流处理或加入已有分组或创建新分组用户在虚拟触发超级表下新建子表并写入数据忽略不做额外处理用户删除触发超级表的子表默认忽略。可选部分触发类型可配置为自动重算或删除对应结果表仅适用于按子表分组的流。对ROLLUP BY流已生成的输出子表会保留用户删除触发表忽略不做额外处理用户给触发表增加列忽略不做额外处理用户删除触发表的列忽略不做额外处理用户修改触发超级表下子表的标签值若该标签列被流用作分组键操作不被允许并报错否则忽略用户修改触发表的列 schema忽略不做额外处理读取时发现 schema 不匹配会报错用户修改或删除源表忽略不做额外处理用户修改或删除输出表忽略不做额外处理写入时发现 schema 不匹配会报错若表不存在将重新创建用户拆分 vnode若 vnode 所在数据库是源库或触发表库不允许若使用虚拟表进行触发或计算不允许用户确认无影响后可用SPLIT VGROUP N FORCE强制执行用户删除数据库若被删数据库是流的源库或是不与流自身数据库相同的触发表库不允许若流对非目标库的虚拟表进行触发或计算不允许用户确认无影响后可用DROP DATABASE name FORCE强制执行除上表明确限制或特殊处理的操作外其余操作包括表中标记为忽略不做额外处理的均不受限制。但若这些操作可能影响流计算应由用户自行决定如何处理要么忽略影响要么执行一次手动重算以恢复正确性。配置参数Configuration Parameters流计算相关配置参数全部在服务端 taosd 中注册生效见 tglobal.c 与 tglobal.c。以下是参数清单及其在源码中注册的默认值与取值范围参数名作用默认值 / 范围来自 tglobal.cnumOfMnodeStreamMgmtThreadsmnode 上的流管理线程数默认 2范围 [2, 5]numOfStreamMgmtThreadsvnode/snode 上的流管理线程数默认 2范围 [2, 5]numOfVnodeStreamReaderThreadsvnode 上的流读取线程数默认 2范围 [2, INT32_MAX]numOfStreamTriggerThreads流触发线程数默认 4范围 [4, INT32_MAX]numOfStreamRunnerThreads流执行线程数默认 4范围 [4, INT32_MAX]streamBufferSize流处理可用最大缓冲区仅用于缓存%%trows结果单位 MB默认 128范围 [128, INT32_MAX]streamNotifyMessageSize控制事件通知消息的大小默认 8范围 [8, 1MB]streamNotifyFrameSize控制发送事件通知消息时底层帧的大小默认 8范围 [8, 1MB]上表默认值与取值范围直接取自当前仓库 tglobal.c 中的cfgAddInt32注册信息与官方文档保持一致并做了补充配置的完整说明可参见 taosd 组件文档。多数参数为CFG_DYN_SERVER_LAZY类型支持在线热更新后逐步生效。规则与限制Rules and Limitations创建与运行流任务时必须遵守以下规则创建流之前集群必须至少部署一个 snode且创建时必须有可用的正在运行的snode。每个流属于一个特定数据库因此创建流之前数据库必须已存在且同一数据库内流名称不能重复。流的触发表与源表可以相同也可以不同且可以分属不同数据库。流的输出表可以位于与流、触发表或源表不同的数据库但不能与触发表或源表相同。输出表超级表或普通表在流创建时自动创建若想写入已存在的表其 schema 必须完全一致。每个分组的输出子表无需预先创建计算写结果时会自动创建。每个触发分组的计算结果写入同一个子表若未指定分组所有结果写入单张普通表。若不同分组被配置为生成同名的子表其结果会写入同一张子表。用户必须确认这是预期行为否则应确保每个分组生成唯一命名的子表。除指定子表名外用户还可以定义输出超级表的标签列以及每个子表的标签值。流处理支持嵌套即可以基于已有流的输出表创建新的流。对滑动步长不为 1 的计数窗口触发乱序、更新、删除都会被忽略步长为 1如COUNT_WINDOW(1)或COUNT_WINDOW(n, 1)时乱序与更新默认触发重算、可用IGNORE_DISORDER忽略删除默认忽略、可用DELETE_RECALC触发重算。在非FILL_HISTORY_FIRST模式下历史窗口与实时窗口可能不对齐。对超级表窗口触发只有区间窗口INTERVAL与会话窗口SESSION支持按标签、按 rollup 标签、按子表分组或不分组其他窗口类型只支持按子表分组。ROLLUP BY与PARTITION BY、DELETE_OUTPUT_TABLE互斥。查询中不支持伪列 qstart、qend、qduration。临时限制Temporary Restrictions暂不支持按普通数据列分组。暂不支持 Geometry 数据类型。NOTIFY_OPTIONS中的ON_FAILURE_PAUSE选项暂不支持。兼容性说明Compatibility Notes与v3.3.6.0相比流计算已完成彻底重设计。从旧版本升级前必须执行以下步骤之后在新版流计算下重新创建流删除所有已有的流计算任务删除所有 TSMA删除所有 snode移除 snode 相关目录dataDir 配置路径下的 snode 目录默认/var/lib/taos/snode旧版checkpointBackupDir配置项指定的目录默认/var/lib/taos/backup/checkpoint/删除所有结果表。注意如果不执行上述步骤taosd 将无法启动。请在升级窗口内完成迁移后再以新版流计算语法见 流语法文档重新创建流任务。【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考