java create 踩过半年生产坑，我把IoTDB连续查询的干货全整理了：从原理到落地全指南

java create 踩过半年生产坑，我把IoTDB连续查询的干货全整理了：从原理到落地全指南

引言

跟 IoTDB打交道也有这么久了，最让我惊喜的不是它超强的压缩比和快到离谱的点查询，而是它自带的连续查询功能——说出来你可能不信，我之前项目里把原来Flink做的实时降采样、滑动窗口聚合全迁到IoTDB原生连续查询上，直接省了三台Flink服务器的成本，运维工作量直接减了八成，端到端延迟还比原来低了一半。

最开始我做第一个工业产线项目的时候，产线设备是1秒采样一次温度、压力、振动这些数据，光一条产线一天就产生将近一千万条数据，产品经理要求大屏要展示每小时的平均温度，还要能查过去一年的趋势。最开始我用的方案是：原始数据存在IoTDB，用Flink做每小时的聚合，结果再写回IoTDB，整套弄下来，光是部署调优花了一周，还得天天盯着Flink有没有挂，那时候真的想，要是IoTDB自己能把这个聚合做了就好了。

后来翻IoTDB官方文档的时候发现了连续查询功能，试了一下，一行SQL就搞定了原来Flink几十行代码的逻辑，还不用额外运维，当时惊了。但是翻了一圈网上的内容，要么是几句话带过，要么就是只抄官方文档，很少有结合生产实战讲透的，尤其是很多坑，没人提，新人进去就是一头雾水。所以我整理了这篇，把我这大半年用连续查询踩过的坑、总结的经验全放出来，从背景、原理、语法、实战到调优踩坑java create 踩过半年生产坑，我把IoTDB连续查询的干货全整理了：从原理到落地全指南，全给你讲明白，新手看完就能上手用。

一、为什么我们需要IoTDB原生连续查询？时序数据聚合的痛点到底在哪？

要理解连续查询的价值，得先从物联网时序数据的特点说起。现在随着工业互联网、智能硬件的普及，设备采样频率越来越高：工业设备一般是1s~100ms采样一次，城市物联网的水表电表是1分钟采样一次，车联网的车载传感器更是到了10ms级别的采样频率。这么高的频率，带来了几个非常头疼的问题：

1.1 高频率采样带来的三大痛点 （1）实时聚合查询延迟太高

大部分业务场景下，我们看趋势、做报表、展示大屏，并不需要这么细粒度的原始数据，只需要聚合后的结果，比如1小时平均、10分钟最大。如果每次查询都实时聚合，要扫几十万甚至上亿条原始数据，等个几十秒都是常事，用户体验极差，高峰期甚至会把整个库的查询拖慢。

（2）存储成本膨胀过快

一百台设备按1秒采样，一年下来就是大概条数据，就算IoTDB压缩比再高，也要几个T的存储，要是上千台设备，就是几十个T，存储成本蹭蹭涨。但实际上，大部分业务只需要在线存3个月的原始数据用于排查问题，长期趋势只需要存1小时粒度的聚合结果，存储成本直接降几十倍。

（3）重复计算浪费资源

如果不提前预聚合，每次用户打开大屏都要重新计算一遍相同的聚合结果，CPU、IO资源白白浪费，本来可以用来处理更多写入请求的资源，都浪费在重复计算上了，非常不划算。

1.2 传统解决方案的天生缺陷

面对预聚合的需求，行业内原来的方案无非两种，但是都有很明显的痛点：

方案一：自定义定时任务跑批量聚合

就是自己写个脚本，用XXL-Job或者调度，每隔一段时间跑一次SQL，把聚合结果写回IoTDB。这个方案看起来简单，实际坑太多：

方案二：Flink/Spark 做流聚合

这个是现在行业的标准方案，但问题就是太重了：

1.3 IoTDB连续查询：原生解决痛点的方案

这个时候IoTDB原生的连续查询就刚好打中了所有痛点。它的核心定义非常简单：连续查询是对实时数据周期性自动执行的查询，并将查询结果写入指定时间序列中。说白了，就是IoTDB自带调度、自带计算，你只需要写一行SQL告诉它你要算什么、怎么存，它就自动帮你跑，完全不用你管，原生还支持滑动窗口、支持乱序数据容忍，完美契合时序数据预聚合的需求。

我用一句话总结它的核心优势：原生集成，零额外架构成本，开发效率提升10倍，资源占用降低一半，完美解决中小规模场景下的时序预聚合需求。

二、核心概念与运行原理：连续查询到底是怎么工作的？

讲具体语法之前，我们先把核心概念理清楚，很多人用错就是因为概念没搞懂。

2.1 核心基础概念 概念说明

连续查询（CQ, Query）

用户定义的周期性自动执行的聚合任务，IoTDB按照规则自动触发，不用人工干预

滚动窗口

窗口不重叠，每个数据只属于一个窗口，比如每小时一个窗口，计算每小时的聚合，适合做降采样、日报表

滑动窗口

窗口按固定间隔滑动，每个数据会属于多个窗口，比如每1分钟滑动一次，计算最近10分钟的平均，适合做实时异常检测、实时趋势计算

重采样

IoTDB提供的自定义窗口规则的子句，通过它可以灵活配置执行间隔、窗口大小，实现不同的滚动/滑动窗口

乱序容忍（Allow ）

允许晚到数据的最大延迟时间，超过这个时间才关闭窗口输出结果，解决物联网设备时钟不同步、离线批量上传导致的乱序问题

这里我要特意强调一下滚动窗口和滑动窗口的区别，很多人刚接触容易搞混：

2.2 完整运行流程

IoTDB连续查询的运行流程非常清晰，一共分四步：

任务调度：IoTDB启动专门的CQ调度线程，按照每个CQ定义的执行间隔（EVERY参数），周期性检查有没有需要执行的任务，到点就触发；窗口切分：触发任务后，根据定义的窗口大小（参数），切分出当前需要计算的时间窗口，然后从存储引擎中过滤出窗口内的原始数据；乱序等待：如果配置了ALLOW ，IoTDB会等窗口结束时间加上延迟时间之后，才关闭窗口，保证所有晚到的乱序数据都能被纳入计算；如果没配置，到点直接关闭窗口；计算写入：对窗口内的数据执行用户定义的聚合计算，然后把计算结果按照用户指定的路径写入目标时间序列，完成一次执行。

整个流程都在IoTDB内部完成，数据不用出IoTDB，没有额外的网络开销，所以延迟非常低，资源占用也很小。

2.3 和其他方案的对比

我们把连续查询和传统方案做个对比，就能很清楚看到它的优势：

方案架构复杂度运维成本开发成本端到端延迟原生支持乱序适用场景

自定义定时任务

不支持

离线批量聚合，对结果准确性要求不高的场景

Flink流计算

支持

复杂计算、大规模场景

IoTDB原生连续查询

极低

原生支持

预聚合、降采样、简单滑动窗口、中小规模场景

三、语法全解析：从创建到管理，每个参数讲透

现在我们来看具体语法，我会把每个部分拆解开，讲清楚每个参数的作用，怎么配置。

3.1 创建连续查询完整语法

创建连续查询的完整语法结构如下：

CREATE CONTINUOUS QUERY <cq_name>
[RESAMPLE 
  [EVERY <every_interval>] 
  [INTERVAL <interval>] 
  [OFFSET <offset_interval>]
  [ALLOW LATENCY <latency_interval>]
]
ON <database_name>
BEGIN
  SELECT <aggregation_func>(<measurement_name>) [, <aggregation_func>(<measurement_name>) ...]
  [INTO <target_series_template>]
  FROM <source_series>
  [WHERE <where_condition>]
  [GROUP BY <group_by_interval>]
END

看起来有点长，我们一个个部分拆解开讲。

3.2 子句：自定义窗口的核心

是整个连续查询最核心的部分，也是最容易用错的地方，它里面四个参数，我一个个讲：

参数作用是否必填说明

EVERY

连续查询的执行间隔，也就是多久触发一次任务

不填默认和（窗口大小）一致，就是滚动窗口；如果EVERY < 就是滑动窗口

每次计算的窗口大小，也就是计算覆盖多长时间的原始数据

如果不填，默认和GROUP BY的分组间隔一致，推荐显式配置，更灵活

窗口偏移量，调整窗口的起始时间，默认从0时区整点开始

大部分场景不需要改，特殊业务需求（比如你要从每个小时的10分开始切窗口）才用

ALLOW

乱序容忍时间，允许晚到数据的最大延迟

默认是0，也就是不等待，直接计算，物联网场景推荐一定要配置

这里我再把最容易搞混的EVERY和拿出来强调一遍，我第一次用就搞反了，结果不对，排查了半小时：

举个例子：

然后是ALLOW ，为什么物联网场景一定要配置？我给大家举个实际的例子：工业现场很多设备是离线运行，攒够10分钟的数据再联网上传，所以数据生成的时间戳比实际时间晚10分钟，如果我们配置ALLOW 0，窗口到点就关闭计算，这些晚到的数据就不会被算进去，结果就不准。所以一般根据你业务的最大乱序延迟，配置1分钟到10分钟就可以，不要配置太大，配置太大结果出来的时间就会变晚，延迟高，这个是 trade-off，要平衡准确性和延迟。

3.3 其他核心语法部分

讲完，剩下的部分就很容易理解了：

3.4 连续查询的管理语法

创建完之后，怎么查看、删除连续查询？非常简单：

-- 查看当前数据库所有连续查询的信息
SHOW CONTINUOUS QUERIES;
-- 删除指定名称的连续查询
DROP CONTINUOUS QUERY <cq_name>;

这里给大家提一个我刚用的时候踩的坑：IoTDB目前（v1.3版本）没有ALTER QUERY修改语法，如果你要改连续查询的参数，只能先删除，再重新创建，别找半天找不到修改的方法，我当时找了十分钟，才发现确实没有这个功能。

四、实战用例：从基础到高级，五个常用场景手把手写

讲完语法，我们来看实际的用例，都是我生产环境用过的，大家可以直接抄过去改改就能用。

用例1：基础场景：计算每小时平均温度，写入新序列

这个就是最经典的场景，题目里也提到了：原始数据是设备每秒采样的温度，存在root..line.*.temp，我们要每小时算一次平均，结果写到root..line.*.。

创建语句：

CREATE CONTINUOUS QUERY cq_temp_1h_avg
RESAMPLE
  EVERY 1h
  INTERVAL 1h
  ALLOW LATENCY 1m
ON factory_db
BEGIN
  SELECT AVG(temp)
  INTO root.factory.line.*.temp_1h_avg
  FROM root.factory.line.*.temp
  GROUP BY 1h
END

语句解释：

验证方法：创建完执行SHOW 能看到就是创建成功，等1个小时之后，直接查目标序列就能看到聚合结果了。

用例2：滑动窗口场景：每1分钟计算一次最近10分钟的平均功率

这个就是典型的滑动窗口流式计算，比如我们做实时异常检测，需要每一分钟更新一次最近10分钟的平均功率，判断有没有超过阈值，用连续查询一行SQL就能搞定。

创建语句：

CREATE CONTINUOUS QUERY cq_power_10m_slide_avg
RESAMPLE
  EVERY 1m
  INTERVAL 10m
  ALLOW LATENCY 30s
ON factory_db
BEGIN
  SELECT AVG(power)
  INTO root.factory.line.*.power_10m_slide_avg
  FROM root.factory.line.*.power
  GROUP BY 1m
END

语句解释：

很多人会问，滑动窗口重复计算会不会浪费资源？我实际测过，一百个滑动窗口CQ，占用的CPU不到10%，对于IoTDb来说完全没问题，而且比把数据拉出去到Flink算，资源占用小太多了。

用例3：乱序数据处理场景：设备离线批量上传，晚到10分钟怎么处理

工业现场很多设备是离线缓存，联网之后批量上传数据，经常会晚到10分钟左右，这个时候用ALLOW 就能完美解决，保证结果准确。

创建语句：

CREATE CONTINUOUS QUERY cq_temp_1h_avg_offline
RESAMPLE
  EVERY 1h
  INTERVAL 1h
  ALLOW LATENCY 10m
ON factory_db
BEGIN
  SELECT AVG(temp)
  INTO root.factory.line.*.temp_1h_avg
  FROM root.factory.line.*.temp
  GROUP BY 1h
END

原理很简单：IoTDB会在窗口结束时间加上ALLOW 之后，才计算窗口的结果，比如窗口结束时间是1点，延迟10分钟，就是1点10分才计算，所有晚到10分钟以内的数据都会被算进去，结果就准确了。代价就是结果出来的时间晚10分钟，这个就是准确性和延迟的平衡，根据你的业务选就可以。

用例4：降采样场景：1秒原始数据降成1分钟一个点，节省存储

这个场景真的太常用了，原始数据是1秒一个点，存一年太占空间，我们只需要存3个月原始数据用于排查问题，降采样成1分钟一个点存三年，存储成本直接降六十倍，非常香。

降采样的连续查询怎么写？非常简单：

CREATE CONTINUOUS QUERY cq_temp_1m_downsample
RESAMPLE
  EVERY 1m
  INTERVAL 1m
  ALLOW LATENCY 2m
ON factory_db
BEGIN
  SELECT FIRST(temp) -- 降采样可以选FIRST（第一个点）、AVG（平均），根据你的需求选
  INTO root.factory.line.*.temp_1m
  FROM root.factory.line.*.temp
  GROUP BY 1m
END

对，就是这样，原来1秒一个点，现在1分钟存一个点，存储直接减了六十倍，而且自动跑，不用管，我现在所有项目的长期趋势存储都是这么干的，成本减了好多。

用例5：多聚合场景：同时计算温度的平均、最大、最小

如果我们需要同时算一个测点的平均、最大、最小三个聚合结果，分别存到不同的序列，不用创建三个CQ，一个就搞定：

CREATE CONTINUOUS QUERY cq_temp_1h_multi_agg
RESAMPLE
  EVERY 1h
  INTERVAL 1h
  ALLOW LATENCY 1m
ON factory_db
BEGIN
  SELECT AVG(temp), MAX(temp), MIN(temp)
  INTO 
    root.factory.line.*.temp_1h_avg,
    root.factory.line.*.temp_1h_max,
    root.factory.line.*.temp_1h_min
  FROM root.factory.line.*.temp
  GROUP BY 1h
END

非常方便，一次定义，自动生成三个结果序列，不用重复创建任务，节省资源。

五、生产环境的管理与运维：怎么稳定维护连续查询

创建完CQ，生产环境怎么维护？我把实际用的运维要点整理出来。

5.1 基础管理

执行SHOW 就能看到当前数据库所有CQ的信息，包括名字、间隔、延迟、SQL语句，输出大概是这样：

al(ms)every(ms)(ms)

60000

所有参数一目了然，方便你核对配置对不对，有没有错。

5.2 监控与问题排查

生产环境肯定要排查问题，我总结了几个常见问题的排查方法：

问题1：创建完CQ，目标序列一直没有数据？

排查步骤：

看原始序列有没有数据，第一个窗口有没有到结束时间，加上ALLOW ，刚创建肯定没结果，等一等就好；看IoTDB的服务日志（iotdb-.log），搜关键字，有没有报错，常见的报错比如权限不足、路径不存在、语法错误，都会打日志；检查WHERE条件是不是太严格，把所有数据都过滤了。 问题2：结果不对，数据不全？

排查步骤：

检查ALLOW 是不是设太小了，乱序数据没等到就关窗口了，调大试试；检查EVERY和是不是搞反了，窗口切错了，核对参数；检查原始数据是不是真的有数据，有没有被清理掉。 5.3 集群环境的注意事项

如果用的是IoTDB集群，要注意：目前连续查询的调度是在节点执行的，不用每个都配置，只要创建成功，会自动调度，切主之后也会自动恢复任务，高可用没问题，不用额外处理。

六、参数调优：生产环境怎么调才能稳定跑

这里讲服务端配置和业务参数的调优，都是实际生产总结出来的经验。

6.1 服务端核心配置参数

IoTDB的配置文件iotdb-.里，有几个CQ相关的参数，根据你的规模调整：

参数名默认值作用调优建议

num

连续查询调度的线程数

如果你的CQ数量超过100个，调大到8~16，不要超过CPU核数的一半，避免占用太多存储查询的资源

story

false

创建CQ的时候是否自动计算已经存在的历史数据

如果你需要把创建之前的历史数据也聚合了，把这个改成true，创建完CQ会自动计算所有符合条件的历史数据，不用你自己处理，非常方便；如果只处理新数据，保持默认false就好

g

true

如果目标序列已经有同一个窗口的结果，是否覆盖

默认true就好，乱序数据重新计算会更新结果，保证准确性；如果你的数据不会变化java create，可以改成false，提升性能

调度器检查任务的间隔

默认就好，不用改

这里重点说一下story，我刚用的时候，创建完CQ发现历史数据没有聚合，查了半天，才发现这个参数默认是false，所以如果你需要处理历史数据，一定要先改这个参数，重启IoTDB再创建CQ，不然还要删了重新来，非常麻烦。

6.2 业务参数调优 ALLOW 选择：比你的业务最大乱序延迟多1分钟就好，不要太大，比如你的设备最大乱序是5分钟，就设6分钟，足够了，太大只会增加结果延迟，没有必要；CQ数量优化：如果CQ太多，超过两百个，调大num，把不用的CQ及时删掉，不要留着占资源；窗口大小选择：非必要不要用太小的窗口，比如不要搞1秒的窗口，一百个1秒窗口也会占用不少资源，根据业务需求选就好。 七、生产踩坑总结：我踩过的这些坑，你别再踩了

都是我实际踩过的坑，整理出来给大家避坑：

1. EVERY和搞反，结果不对

我第一次写滑动窗口的时候，把EVERY写成10m，写成1m，结果出来的结果完全不对，排查了半小时才发现搞反了。记住：EVERY是多久跑一次，是一次算多久，别搞反。

2. ALLOW 用默认0，乱序数据丢了

物联网设备基本都有乱序java create，默认是0，不等待，所以默认就会丢数据，结果不准。我刚用的时候不知道，结果偏差了5%，找了两天才找到原因，说多了都是泪java create 踩过半年生产坑，我把IoTDB连续查询的干货全整理了：从原理到落地全指南，只要是物联网场景，都设个1~10分钟，别用默认0。

3. 忘了开 ，历史数据没聚合

默认不开 ，如果你需要把创建之前的历史数据也聚合了，一定要先改配置开了，再创建CQ，不然创建完只有新数据，历史的没有，还要删了重新来，麻烦。

4. 目标路径设计不规范，后面维护麻烦

刚用的时候我随便起目标路径，比如root.，结果后面多了几个聚合，分不清哪个是哪个。现在我都是按原始路径_聚合粒度_聚合类型命名，比如root..line..，一目了然，好维护。

5. CQ太多拖慢IoTDB性能

我最开始项目里搞了两百多个CQ，线程数还是默认4，结果正常的查询都变慢了，后来把线程数调到16，删掉了几十个不用的CQ，就好了。所以CQ多了一定要调线程数，没用的及时删。

八、适用场景与局限性：什么时候用，什么时候不用

客观说，连续查询不是银弹，不是什么场景都适合，我总结一下：

适合用IoTDB连续查询的场景 时序数据降采样，节省存储成本，几乎所有项目都能用；实时聚合预计算，给报表、大屏提供数据，提前算好，查询飞快；简单滑动窗口流式计算，比如实时异常检测的滑动窗口聚合，完全够用；中小项目java create，不想搭Flink集群，降低架构复杂度和成本，完美。 不适合用连续查询的场景 复杂的多流关联计算、多数据源join，连续查询不支持，还是用Flink更合适；超大状态的计算，比如要算几个月的滑动窗口，状态太大，专业流计算框架更合适；金融级强一致性 Once需求，连续查询目前的一致性设计满足不了，还是用Flink。

所以大家根据自己的场景选，能用连续查询的就用，省成本省时间，复杂的就用Flink，组合起来用就是最好的方案。

九、总结

IoTDB的连续查询真的是物联网时序数据处理的一个大杀器，原生集成，开箱即用，解决了原来需要额外流计算框架才能做的预聚合、滑动窗口、降采样需求，大大降低了架构复杂度和运维成本，对于绝大多数物联网场景，完全可以替代外部流计算框架，节省大量成本。

我自己用了大半年，从最开始的踩坑，到现在项目里大部分聚合需求都用连续查询，真的感受到了原生功能的优势，开发效率提升了太多，原来要一周才能弄完的需求，现在半天就能弄完。

IoTDB 社区版：

企业版官网：