优化tdengine stream针对不存在数据的清洗性能

开源版问题专区
1

【TDengine 使用环境】
生产环境 /测试/ Poc/预生产环境

【TDengine 版本】

3.4.1

【操作系统以及版本】

ubuntu20.04

【部署方式】容器/非容器部署

非容器部署

【集群节点数】

1

【集群副本数】

【描述业务影响】

占用了很高的CPU

【问题复现路径/shan】做过哪些操作出现的问题

【遇到的问题：问题现象及影响】

中间一段时间范围出现了数据的缺失，然后重新开始推送时序数据，然后stream清洗进程就占用很高的CPU了，如下图所示，缺失数据是不是要优化下，而且

image
image927×370 17.9 KB

【资源配置】

8C/32G

2

好的，多谢提供的问题。

请给一下建流语句，以及 流中涉及的源表的结构。我们分析看看。

3 
CREATE
STREAM IF NOT EXISTS iot_clean.stream_clean_6m
  INTERVAL(5m) SLIDING(5m)
  FROM iot.tsdata
  PARTITION BY product_id, device_id, identifier
  STREAM_OPTIONS(
      PRE_FILTER(product_id in('add80ab6-95ee-583a-95b9-e6b33f6c842e','3685200d-17a5-5c89-a6e9-53e8bddea1bd'))
      | MAX_DELAY(5m)
      | FILL_HISTORY_FIRST('2026-01-01 00:00:00')
  )
  INTO iot_clean.tsdata_clean_6m
  OUTPUT_SUBTABLE(
      CONCAT(
          'clean6min_',
          REPLACE(product_id, '-', ''),
          '_',
          REPLACE(device_id, '-', ''),
          '_',
          REPLACE(identifier, '-', '')
      )
  )
  TAGS (
      product_id VARCHAR(32) AS product_id,
      device_id  VARCHAR(32) AS device_id,
      identifier VARCHAR(64) AS identifier
  )
AS
SELECT _twstart                                 AS ts,
       LAST(double_v)                           AS double_v,
       LAST(bool_v)                             AS bool_v,
       LAST(long_v)                             AS long_v,
       CAST(_tlocaltime / 1000000 AS TIMESTAMP) AS insert_time
FROM %%trows;
4

另外一个问题是：针对1万点每秒的时序数据，10s的清洗CPU使用率偏高，在2C-4C

5

对这个流语句，建议一个优化：不要使用 FROM %%trows; 这个流程没有优化，研发给的建议是：
FROM iot.tsdata where c0 >= twstart and c0 < tend and PARTITION BY %%1,%%2,%%3;
请修改后再试试。

6

c0 >= _twstartand c0 < _twend这个针对延迟的数据有没有问题啊，比如上一个窗口还没完全闭合会不会导致部分窗口的数据丢失呢

7

%%trows: reference to the trigger dataset for each group in the trigger table (i.e., the set of rows that meet the current trigger condition) 这个不是触发表的相关数据么，这个跟c0 >= twstart and c0 < tend 这个差别大么

8

试了下上面的sql，cpu使用率没有下降

9

还有一个明显的问题，如果改为从tsdata取数据，where条件是不是要加上device_id与identifier啊，你那边现在改到的sql不是相当于查询全表数据了么

10

你刚才给到的清洗sql比我之前的方案还要高不少，我怀疑是查询条件没添加device_id,identifier的缘故

11

我给sql 里是有 partiton by的啊。
where _c0 >= twstart and _c0 < tend and PARTITION BY %%1,%%2,%%3;

12

这个跟partition by device_id,identifer有区别么