Hi, Marc
1. I think you should choose which type of window you want to use first.
(Thumbling/Sliding/Session) From your description, I think the session
window maybe not suit your case because there is no gap.
2. >>> how this would work in practise or how to handle the case where
timers fire for data that has already been ejected from the window (as it
has been matched with past data)?
Do you want to know the lifecycle of the element in the window? I
think you could know that the lifecycle of the window and element in it
after you choose your window type. For example, the element could be
assigned to multiple slide windows and an element ejected from a sliding
window could be processed from another sliding window.[1]
3. I think you could find some examples in the `WindowTranslationTest`.
4. If these window types do not work for your application. I think you
might need a customized window(trigger/evictor). However, I think you
could make a simple POC with the current type window first.
[1]
https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/stream/operators/windows.html#sliding-windows
Best,
Guowei
ba <marc.de...@baranalytics.co.uk> 于2020年5月21日周四 下午4:00写道：
> Hi Guowei,
>
> Thank you for your reply. Are you able to give some detail on how that
> would
> work with the per window state you linked? I'm struggling to see how the
> logic would work.
>
> I guess something like a session window on a keyed stream (keyed by sensor
> ID). Timers would fire 90 seconds after each element is added to the window
> and then be evaluated? I can't quite think how this would work in practise
> or how to handle the case where timers fire for data that has already been
> ejected from the window (as it has been matched with past data)?
>
> If there are any examples showing similar uses of this function that would
> be great?
>
> Any assistance is very appreciated!
>
> Best,
> Marc
>
>
>
>
>
> --
> Sent from:
> http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/
>
