ksqlDB : Window 정리

들어가기 전

https://docs.ksqldb.io/en/latest/img/ksql-window.png

ksqlDB는 스트림을 이용해서 특정 기간(Window)의 이벤트를 집계해서 보내주는 형태의 Window 쿼리를 제공한다. 특정 기간을 Duration으로 나타내고, Duration은 WINDOWSTART / WINDOWEND로 표현할 수 있다. WINDOWSTART / WINDOWEND는 Window 쿼리를 생성하면 SELECT 절에 선언해서 사용할 수 있다. 

https://docs.ksqldb.io/en/latest/img/ksql-window-aggregation.png

• Tumbling Window
• Hopping Window
• Session Window

이 Window 쿼리는 총 세 가지 모드가 존재한다. 또한 Window에는 Grace Period라는 부가 기능이 있어서 Window를 보조해주는 역할을 한다.

 

Windowing의 의의

Window는 한번 더 그룹화를 한다는 의미가 있다. Window는 Group By를 이용해서 각 Key에 대한 집계치를 모은다. GROUP BY를 사용하면서 Key로 그룹화를 했다. 그런데 Window를 추가했다는 것은 각 Key를 Window로 한번 더 그룹핑 한다는 것이다. 

 

 

 

 

 

Window 쿼리 생성

Window를 이용한 쿼리를 생성했을 때의 내용을 한번 살펴보려고 한다.

Window 쿼리는 독립적으로 집계됨.

Window를 가지고 있는 쿼리를 생성하면 각 쿼리마다 독립적으로 집계가 된다. 

SELECT orderzip_code, 
  from_unixtime(WINDOWSTART) as Window_Start,
  from_unixtime(WINDOWEND) as Window_End,
  from_unixtime(max(ROWTIME)) as Window_Emit,
  count(orderId) as number_of_orders
FROM orders
  WINDOW TUMBLING (SIZE 5 minute, GRACE PERIOD 1 minute)
  GROUP BY order_zipcode
  EMIT CHANGES;

예를 들어 위와 같은 쿼리를 두 개를 만든다고 가정해보자. 그렇지만 생성되는 시간은 다르다고 가정해보자. 12:00 / 12:01에 한 개씩 생성된 것으로 생각해보자. 그리고 각 쿼리의 이름을 쿼리 A / 쿼리 B 라고 정해보자. 그렇다면 쿼리 A와 쿼리 B는 동일한 Window 영역(Start / End)를 가질 수 있다. 그렇지만 쿼리 A와 쿼리 B의 결과는 독립적으로 집계가 된다. 

예컨데 다음 상황처럼 집계된다. (C(A)는 A의 갯수를 Count 했다는 의미다.). 아무튼 그림으로 보면 좀 더 명확히 이해할 수 있다. 

 

Window 쿼리의 기간은 자동으로 설정됨. 

Window 쿼리를 생성하면 WINDOWSTART / WINDOWEND를 이용해서 WINDOW의 구간이 어디인지 확인할 수 있다. 이 때 Window의 시작 지점은 "쿼리가 생성되는 시점"이 아니다. Window의 시작 지점은 내부 로직(?)에 의해서 특정 시간대로 정해지는 것을 볼 수 있다. 예를 들어 쿼리를 14:01:10초에 생성했다고 하면 Window의 시작 지점은 14:00:00으로 지정될 가능성이 높다.

위의 그림에서 쿼리를 생성하자마자 바로 메세지를 보냈다. 메세지가 도착한 시간은 14:02:22분 정도였는데, 쿼리를 생성한 시간은 길어도 14:01분이 지나지 않았을 것이다. 그렇지만 WINDOW_START는 14:00:00으로 설정된 것을 확인할 수 있다. 이 말은 쿼리를 생성한 시점이 Window의 시작 지점이 되지 않는다는 것이다. 

 

Window 쿼리의 Grace Period

Grace Period는 네트워크가 느려져서 늦게 도착한 녀석들이 있을 수도 있는데, 이 녀석들이 Grace Period 내에만 도착한다면 이 값을 Window 내에 집계를 해주겠다는 것이다. 그러면 이 Grace Period는 무엇을 기준으로 판단하는지를 살펴봤다. Window까 14:00:00 ~ 14:01:00이고 Grace Period는 30초라고 가정해보자. 그러면 14:00:30까지 도착하는 녀석은 첫번째 Window의 값이 될 것이다.

1. 14:01:10에 메세지를 발송해서 14:01:11에 메세지가 ksqlDB에 도착함 -> Grace Period에 포함되지 않음.
2. 14:00:59에 메세지를 발송해서 14:01:20에 메세지가 ksqlDB에 도착함 -> Grace Period에 포함될 것 같음.

1번은 확실히 실험을 통해서 Grace Period 내에 도착했지만 첫번째 Window에 포함되지 않았다. 메세지의 시간은 생성된 시점, 받은 시점, 처리한 시점으로 나누어진다. 이 때 생성된 시점이 Window 안에 있고, 받은 시점이 Grace Period 안에 있는 메세지만 Grace Period 기간에 포함되는 것 같다. 

 

Window 종류

여기서는 각 Window마다 어떻게 동작하는지를 확인하고자 한다.

Tumbling Window

https://docs.ksqldb.io/en/latest/img/ksql-time-windows-tumbling.png

• Fixed Duration : 윈도우의 기간을 의미한다. 
• Window 시작 / 끝 시간은 자동으로 정해짐. 
• 해당 기간동안의 메세지를 집계해서 보내줌. WINDOWEND Time은 집계에 포함되지 않음.
• 하나의 Window가 끝나면 바로 다음에 겹치지 않도록 다음 Window가 생성됨.
  • 따라서 Overlap 기간이 존재하지 않음. (End Time이 집계에 포함되지 않기 때문임)

텀블링 Window는 한 가지 시간을 바탕으로 동작하고 다음 특징을 가진다. 

 

Hopping Window

https://docs.ksqldb.io/en/latest/img/ksql-time-windows-hopping.png

 

 

 

 

 

참고

ksqlDB docs : https://docs.ksqldb.io/en/latest/concepts/time-and-windows-in-ksqldb-queries/