inconsistent results between query with state window and stream with state window
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 25.1k
- Forks
- 5k
- Avg merge
- 4d 59m
- Merged PRs (30d)
- 7
Description
1. 创建超级表语句
CREATE STABLE skywalk_smm.truck (ts timestamp, lng double, lat double, berth_id varchar(20), speed double) TAGS (device_no varchar(20), terminal_id varchar(20), type int);
2. 创建流式计算
create stream if not exists berthsteam7 trigger at_once watermark 180s ignore update 0 fill_history 1 into skywalk_smm.berthsteam7 as select _wstart as start_time, _wend as end_time ,berth_id,timediff(_wstart,_wend ,1s) as diff,device_no from skywalk_smm.truck partition by tbname state_window(berth_id);
3. 状态窗口查询
select _wstart as start_time, _wend as end_time ,berth_id,timediff(_wstart,_wend ,1s) as diff,device_no from skywalk_smm.truck partition by tbname state_window(berth_id);
**问题:**通过流式计算进行统计数据,后台数据跑了一天后,查询某台设备的数据,窗口关闭,并且多了一条不应该存在的窗口数据,正常情况下应该是在同一个窗口里面
现象:
流式计算查询设备sql
SELECT * FROM SKYWALK_SMM.berthsteam7 where device_no =710;
状态窗口查询sql
select * from (select _wstart as start_time, _wend as end_time, berth_id, timediff(_wstart, _wend , 1s) as diff, device_no from skywalk_smm.truck partition by tbname state_window(berth_id) ) t where t.device_no =710;
预期结果值
使用流式计算结果应该与状态窗口查询统计的结果一致
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the CREATE STABLE, CREATE STREAM, and state_window queries shown in the issue, then compare the stream output with the direct query output for device_no 710. Investigate why the stream closes a window and emits an extra row; done means both result sets contain the same state-window boundaries and values.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- sql
- Domain
- databases, stream-processing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100