RuleGo RuleGo
🏠Home
  • Quick Start
  • Rule Chain
  • Standard Components
  • Extension Components
  • Custom Components
  • Visualization
  • RuleGo-Server
  • AOP
  • Trigger
  • Advanced Topics
  • Performance
  • Standard Components
  • Extension Components
  • Custom Components
  • Components Marketplace
  • Overview
  • Quick Start
  • Routing
  • DSL
  • API
  • Options
  • Components
🔥Editor (opens new window)
  • RuleGo Editor (opens new window)
  • RuleGo Server (opens new window)
  • StreamSQL
  • AI Agent Framework
  • TPCLAW Agent Platform (opens new window)
  • Github (opens new window)
  • Gitee (opens new window)
  • Changelog (opens new window)
  • English
  • 简体中文
🏠Home
  • Quick Start
  • Rule Chain
  • Standard Components
  • Extension Components
  • Custom Components
  • Visualization
  • RuleGo-Server
  • AOP
  • Trigger
  • Advanced Topics
  • Performance
  • Standard Components
  • Extension Components
  • Custom Components
  • Components Marketplace
  • Overview
  • Quick Start
  • Routing
  • DSL
  • API
  • Options
  • Components
🔥Editor (opens new window)
  • RuleGo Editor (opens new window)
  • RuleGo Server (opens new window)
  • StreamSQL
  • AI Agent Framework
  • TPCLAW Agent Platform (opens new window)
  • Github (opens new window)
  • Gitee (opens new window)
  • Changelog (opens new window)
  • English
  • 简体中文

广告采用随机轮播方式显示 ❤️成为赞助商
  • Quick Start

  • Rule Chain

  • Standard Components

  • Extension Components

  • Custom Components

  • Components marketplace

  • Visualization

  • AOP

  • Trigger

  • Advanced Topic

  • Agent Framework

  • RuleGo-Server

  • FAQ

  • Endpoint Module

  • Support

  • StreamSQL

    • Overview
    • Quick Start
    • Core Concepts
    • SQL Reference
    • API Reference
    • RuleGo Integration
    • Schema Validation
    • Advanced Examples
    • functions

    • case-studies

      • Case Studies Overview
      • Stream-Table JOIN Metadata Enrichment
      • Session Window and Device Online Analysis
      • Change Data Capture Case Study
      • Sliding Window and Continuous Detection
        • Business Scenario
        • SQL
        • Input
        • Output
        • Behavior Notes
        • 📚 Related Docs
      • Data Filtering and Transformation
      • IoT Temperature Alerting and Metrics Aggregation
目录

Sliding Window and Continuous Detection

# Sliding Window and Continuous Detection

# Business Scenario

Bus current needs "sustained over-threshold" alerting: only when the current is entirely above 200A for the past 10 seconds (no dip in between) is it a sustained overload. Slide every 2 seconds looking back over 10 seconds, and use HAVING to filter out windows that contained a dip.

# SQL

SELECT MIN(concurrency) AS mn,
       COUNT(*)         AS c
FROM stream
GROUP BY SlidingWindow('10s', '2s')
HAVING mn > 200
1
2
3
4
5
  • SlidingWindow('10s', '2s'): window size 10s, sliding every 2s; windows overlap (one event may fall in multiple windows).
  • MIN(concurrency) AS mn: the minimum across all events in the window; a single event ≤200 makes mn ≤200.
  • HAVING mn > 200: keeps only windows where "everything >200", i.e. the sustained-overload stretches.

# Input

Current readings over a period (the first 10s all >200; a 180 dip in the middle; recovery afterwards):

{"concurrency": 250, "ts": 1}
{"concurrency": 260, "ts": 3}
{"concurrency": 240, "ts": 5}
{"concurrency": 180, "ts": 7}   // dip; the window containing it has min=180 and is filtered by HAVING
{"concurrency": 270, "ts": 9}
{"concurrency": 280, "ts": 11}
1
2
3
4
5
6

# Output

Only windows where "everything >200" pass HAVING; the window with the 180 dip is filtered out:

{mn: 240 c: 3 ...}   // window without the dip
{mn: 270 c: 2 ...}   // window after the dip
(the window containing 180 is filtered by HAVING and not emitted)
1
2
3

# Behavior Notes

  • Sliding windows overlap: each event may enter multiple windows, so the same period produces multiple output points (one every 2s), smoother than a tumbling window.
  • HAVING references the SELECT alias (mn); you cannot repeat the aggregate function (HAVING MIN(concurrency) > 200 does not work).
  • Why min catches dips: the window aggregates all events in those 10s (including the dip); once MIN <200, HAVING filters it out — this is exactly the "sustained" semantics.
  • Contrast: Change Data Capture uses analytic functions for "instantaneous change" detection; this case uses window aggregation for "sustained period" detection — do not mix them.

How to run

A sliding window is an aggregation query; use Emit + AddSink to receive window results in batches. See How to Run Case SQL for the full boilerplate.

# 📚 Related Docs

  • How to Run Case SQL
  • SQL Reference — SlidingWindow, HAVING
  • Change Data Capture — instantaneous change detection (analytic functions)
Edit this page on GitHub (opens new window)
Last Updated: 2026/07/11, 04:40:00
Change Data Capture Case Study
Data Filtering and Transformation

← Change Data Capture Case Study Data Filtering and Transformation→

Theme by Vdoing | Copyright © 2023-2026 RuleGo Team | Apache 2.0 License

  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式