플링크는 시간에 관한 명확한 세 가지 개념을 지원합니다.
- Event Time
- 이벤트가 발생한 시간, 기기에 의해 생산(혹은 저장)되어 기록된 이벤트
- Ingetion Time
- 이벤트가 전달된 순간 플링크에 의해 기록된 시간
- Processing Time
- 파이프라인의 특정한 연산자에 의해 이벤트가 처리된 시간
만약 당신이 첫 번째 거래 시간 동안 도달한 주식의 최대 값을 계산한다면, 당신은 이벤트 시간을 사용해야 합니다.
- 이렇게 한다면 결과는 계산 성능에 의존되지 않습니다.
특정한 실시간 처리에서는 종종 프로세싱 타임을 사용하는 경우가 있지만,
그럴경우 그 때 발생한 이벤트가 아니라 해당 시간 동안 처리된 이벤트에 따라 결과가 결정됩니다.
프로세싱 타임에 기반하여 분석 계산을 수행하는건 불일치를 야기하고 기록을 재분석 하거나 새로운 구현체를 테스트하기 어렵게 합니다.
만약 당신이 이벤트 시간을 사용하길 원한다면, 플링크가 이벤트 시간의 진행을 추적하기 위해 사용하는 타임스템프 추출기와 워터마크 생성기의 지원이 필요할 것 입니다.
당신이 아래의 예시처럼 순서가 맞지 않는 타임 스탬프 이벤트 스트림을 가지고 있다고 가정해봅시다.
- 숫자들은 이벤트가 실제로 발생한 시간을 나타내는 타임스탬프 입니다.
몇 가지를 생각해 봅시다.
당신의 스트림 정렬기는 첫 번째 요소로 4를 보게될 것 입니다. 그러나 당신은 즉시 이것을 정렬된 스트림에 바로 전달할 수 없습니다. 이것은 순서를 벗어나서 도착하거나 더 먼저 발생한 이벤트가 아직 도착하지 않았을 수 있습니다.
사실, 당신은 스트림의 미래를 알 수 있는 신과 같은 능력을 가지고 있고, 당신의 스트림 정렬기가 2가 도착하기 전 까지 어떤 결과도 생성하지 않아야 하는 것을 알 수 있습니다.
약간의 버퍼링과 지연은 필요합니다.
만약 당신이 이것을 잘 수행하지 못하면, 당신은 영원히 기다려야 합니다.
첫 번째로 정렬기는 이벤트 4를 보고 그 다음 이벤트 2를 보게 됩니다. 2보다 먼저 발생한 이벤트가 도착할까요?
그럴 수도 있고 아닐 수도 있습니다. 당신은 영원히 기다리고 절대 이벤트 1을 볼 수 없습니다.
결국 당신은 용기를 내야하고 이벤트 2를 정렬된 스트림에 전달해야 합니다.
이제 필요한 것은 주어진 타임스탬프 이벤트에 대해 이전 이벤트가 도착할 때 까지 얼마나 기다려야 하는가에 대한 정책입니다.
이것이 바로 워터마크의 역할입니다.
워터마크는 이전에 발생한 이벤트를 언제까지 기다려야 하는가에 대해 정의합니다.
플링크에서 이벤트 시간 처리는 특별한 타임스탬프 요소를 스트림 내부로 넣어주는 워터마크 생성기(이하 워터마커)에 의존합니다.
스트림 정렬기는 언제 기다리는걸 멈추고 이벤트 2를 밀어 정렬된 스트림을 시작해야 할까요? 그건 바로 타임스탬프가 이벤트 2보다 큰 워터마크가 도착했을 때 입니다.
당신은 어떻게 워터마크를 생성할 것인지 선택하는 다른 정책들을 상상할 수 있습니다.
각 이벤트가 약간의 지연 이후에 도착할 때 이러한 지연들은 각기 다르므로, 몇몇의 이벤트들은 다른 이벤트들 보다 더 지연될 수 있습니다.
한가지 간단한 접근법으로 이러한 지연들은 일부 최대 지연에 의해 제한된다고 가정하는 것 입니다. 이것은 워터마킹에 접근하는 복잡한 방법을 더 쉽게 상상할 수 있게 하지만, 대부분의 어플리케이션은 고정 지연으로 충분합니다.
워터마크에 대해 생각하는 또 다른 방법은, 워터마크가 스트리밍 어플리케이션 개발자에게 지연과 완성도 간의 균형을 정할 수 있는 권한을 제공한다는 것입니다.
배치 처리에서는 다릅니다. 결과를 생성하기 전에 입력에 대한 모든 정보를 얻을 수 있는 사치스러운 배치 처리와는 다르게 스트리밍을 사용하면 더 많은 입력을 보기 위해 기다리는 것을 멈추고 결과를 생성해야 합니다.
또한, 당신은 짧은 딜레이로 제한된 공격적인 워터마킹을 구성할 수 있으며, 이로인해 불완전한 입력 정보에 의한 처리 결과에 리스크를 감수해야 합니다.
- 예를 들어, 잘못된 결과가 나오더라도 빠르게 처리해야 하는 경우가 있습니다.
또는 길게 기다려서 정확한 결과를 생성하는 이점을 챙겨갈 수 있습니다.
두 가지를 모두 구현한 방법을 적용할 수 있습니다. 초기 결과는 빠르게 처리하고 이후에 업데이트 하는 방식으로 많이 사용합니다. 이것은 몇몇 어플리케이션에서 아주 좋은 방법입니다.
지연은 워터마크를 기준으로 정의됩니다.
워터마크 t는 스트림이 t시간까지 완료되었다고 주장합니다. 타임스탬프가 t보다 작거나 같은 이 워터마크 다음에 오는 이벤트는 모두 늦습니다. (?)
Lateness is defined relative to the watermarks. A Watermark(t) asserts that the stream is complete up through time t; any event following this watermark whose timestamp is ≤ t is late.
이벤트 시간에 기반한 이벤트 처리를 수행하기 위해, 플링크는 각 이벤트와 관련된 시간을 알아야 하며 워터마크를 포함하는 스트림도 필요합니다.
In order to perform event-time-based event processing, Flink needs to know the time associated with each event, and it also needs the stream to include watermarks.
아래 예시의 택시 데이터는 이러한 세부 사항들을 다루고 있습니다. 그러나 당신의 어플리케이션에서는 이것을 스스로 관리해야 하며, 보통 이벤트로부터 타임스탬프를 추출하는 클래스를 구현하고, 요구사항대로 워터마크를 생성해야 합니다. 이러한 동작을 쉽게 하기 위해서 WartermarkStrategy를 사용합니다.
DataStream<Event> stream = ...
WatermarkStrategy<Event> strategy = WatermarkStrategy
.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(20))
.withTimestampAssigner((event, timestamp) -> event.timestamp);
DataStream<Event> withTimestampsAndWatermarks =
stream.assignTimestampsAndWatermarks(strategy);