Flink - Event Time

Flink 스트리밍 환경에서 세 가지의 특정 타임을 캡처할 수 있다.

Event Time

이벤트가 디바이스에서 생성된 시간을 의미한다.
예를들어 모바일에서 로그인이 발생했을때 모바일 기기에서 발생된 시간이다.

Processing Time

이벤트가 실제 Flink 서버에서 수행된 시간이다.
예를 들어 Window Time 을 매 1시간마다 스트림 처리중인 작업이 있다면, 같은 프로세싱 타임에 처리된 레코드들은 프로세싱 타임이 같다.
1시간마다 작업중인 스트리밍 처리에 100건의 레코드가 10:05 에 수행되었다면, 프로세싱 타임 10:05 에 100건의 레코드들이 수행된 것. (100건의 레코드들은 같은 프로세싱 타임에 수행된 것이다.)

Ingestion Time

이벤트가 플링크에 인입되는 시간이다.
인입된 각각의 단일 레코드들의 Timestamp를 실시간으로 할당한다. (Window 처리된 레코드들도 각자의 고유 Timestamp를 가진다.)

 

아래 그림을 통해 쉽게 이해할 수 있다.

 

 

위의 그림에서 보이다시피, Ingestion Time 은 개념적으로 Event Time과 Processing Time 사이에 위치한다. Ingestion Time 은 하나의 레코드마다 할당된 시간이므로 Window 사이즈만큼의 레코드에 단일 timestamp만 할당하는 Processing Time 에 비해 무겁다.

 

 

왜 시간을 저렇게 나누어 놓았을까?

Flink는 Event Time 기반으로 스트림 처리를 할 수 있는데..
먼저 Event Time기반이 아닌 Processint Time 기반의 문제점을 살펴보자.

아래 예시를 보자.
Time 기반의 Window 사이즈가 아래와 같이 레코드들이 생성되었다고 가정. (레코드의 Timestamp를 나타내었고 하나의 Window에는 5 단위의 Timestamp를 가질수 있다)

Window 1 : 2,4,5,1 (정상 Window Timestamp Range: 1 ~ 5)
Window 2 : 7,9,10 (정상 Window Timestamp Range: 6 ~ 10)
Window 3 : 11,8,12,13 (정상 Window Timestamp Range: 11 ~ 15)

위와 같이 Timestamp로 Window를 나타내었다고 보면, Window 3의 '8'의 레코드가 Window 3에 잘못 섞여있는 것을 볼 수 있다. 정상적이라면 Window 2에 있어야 하는데 메시지가 네트워크에 의해 지연 도착되었다던가, Flink 서버 이슈 혹은 Source에서의 문제에 의해 발생되었을 수도 있다.

Window를 통한 스트리밍 처리는 결국 Micro Batch 이기 때문에 MapReduce의 Shuffle 단계에서 sort가 되지만, '8' 의 레코드는 sort가 되어도 정상적으로 처리되어야 할 Window 2에서 벗어나있기 때문에 다른 처리 로직이 들어가야 한다.

 

Processing Time을 기반으로 '서버에서의 시간'을 기준으로 한다면 '실제 이벤트가 발생한 시간'을 기준으로 데이터 처리가 어렵다. 가령 클라이언트 시간을 기준으로 1시간 마다 UV를 구하고 싶다면, 정확히 1시간의 UV를 추출해야하는데, 위에서와 같이 Event Time으로부터 지연된 경우가 발생한다면 누락된 데이터가 발생하게 된다.

 

그래서 Flink는 Event Time 기반의 데이터 스트림 처리를 위해 Watermaks 라는 메커니즘을 사용한다.
다음 장에서 Watermaks에 대해 설명하겠다.