Streaming Systems - Chapter 3

Percentile watermarks

이 전까지 watermark는 가장 빠른 event time을 기준으로 계산함. 이렇게 최소 점 대신에, 특정 퍼센트를 정해서, 그 퍼센트까지 데이터가 도착했으면 데이터가 도착했다고 간주함. (ex. 99%로 선정했다면, 빠른 99%가 도착했다면 데이터가 도착했다고 가정) outlier에 의한 지연을 제거할 수 있음. 100 -> 66 -> 33% 워터마크가 될 수록 점점 그림이 빨리 그려짐: latency는 개선되나 precision이 떨어짐.

Processing-Time watermarks

event time watermark로는 한시간 전의 데이터를 빠르게 처리하는 시스템과, 현제의 데이터를 한시간동안 걸려서 처리하는 시스템을 구분할 수 없다.

event time watermark와 대비되는 processing time watermark를 사용, data delay와 별개로 processing delay를 구분할 수 있게 된다.

그림 3-12, 3-13에서는 event-time watermark가 늘어나면서 동시에 processing time watermark가 늘어나고 있다. -> system processing이 지연되고 있는 것.

처리 시간 워터마크 지연 = (현재 실제 처리 시간) - (가장 오래된 미완료 연산이 시작되었던 처리 시간 타임스탬프) : 실제로 처리를 시작하고 나서 지연되고 있다는 것 -> 유저나 관리자가 처리해야하는 문제가 있을 확률이 높다.

그림 3-12, 3-13과 대비되게 3-14의 경우는 event-time watermark는 증가하지만 processing-time watermark는 그대로 있다 -> 처리에 시간이 걸리고 있는게 아니라, 그 앞단에서 buffer에 쌓고 있거나 한 상황인 것.

그림 3-15의 경우 fixed window인데, window가 넘어갈 때마다 trigger가 되어서 이벤트들이 처리되면 watermark 값이 올라가고 그만큼 watermark delay의 값이 떨어져서 저런 모양이 나오는 것

Watermarks in Google Cloud dataflow

Dataflow는 key를 기반으로 데이터를 재분배해서 각각의 worker에 분배한다. 앞에서 watermark는 여러개의 단계로 구분된다고 했는데, Dataflow에서는 각 단계에서도 key range에 따라 별개로 트래킹이 필요하다. 그럼 이 key range를 관통하는, 최소한의 watermark를 계산해야한다. 조건:

• 모든 range들은 watermark를 보고해야 한다.
• watermark는 증가하기만 해야한다. late data가 들어오더라도 후진해서는 안된다. Google Cloud Dataflow는 중앙화된 aggregator에서 이를 계산한다. 이는 “single source of truth”로서 작동한다.

Watermarks in Apache Flink

플링크는 워터마크 추적과 집계를 인밴드(in-band) 방식으로 수행 source들이 중간중간에 워터마크 ‘체크포인트’들을 발생시키고, data stream에 함께 전달된다. 53이라는 타임스탬프가 발생하면 53 이전의 정시(nonlate) 데이터는 발생하지 않는다! (late data는 여전히 들어올 수 있겠지만…)

인밴드 워터마크의 장점:

• 워터마크 전파 지연 감소 및 매우 낮은 지연 시간의 워터마크: 워터마크 데이터가 여러 홉을 거치거나 중앙 집계를 기다릴 필요가 없기 때문에, 인밴드 방식은 매우 낮은 지연 시간을 더 쉽게 달성할 수 있습니다.
• 워터마크 집계에 대한 단일 장애 지점(single point of failure) 없음: 중앙 워터마크 집계 에이전트의 장애는 전체 파이프라인의 워터마크 지연을 초래할 수 있지만, 인밴드 방식에서는 파이프라인 일부의 장애가 전체 파이프라인의 워터마크 지연을 유발하지 않습니다.
• 내재된 확장성: 중앙 집중식 워터마크 집계 서비스로 확장성을 달성하려면 더 많은 복잡성이 필요하지만, 인밴드 워터마크는 암묵적인 확장성을 가집니다.

아웃오브밴드 워터마크 집계의 장점:

• “단일 진실 공급원(Single source of truth)”: 디버깅, 모니터링, 또는 파이프라인 진행 상황에 따른 입력 조절과 같은 애플리케이션을 위해, 시스템 각 구성요소가 부분적인 뷰를 갖는 것보다 워터마크 값을 제공할 수 있는 서비스가 있는 것이 유리합니다.
• 소스 워터마크 생성: 일부 소스 워터마크는 전역적인 정보가 필요합니다. 예를 들어, 소스가 일시적으로 유휴 상태이거나, 데이터 전송률이 낮거나, 워터마크를 생성하기 위해 소스 또는 다른 시스템 구성 요소에 대한 아웃오브밴드 정보가 필요할 수 있습니다. 이는 중앙 서비스에서 더 쉽게 달성할 수 있습니다. (예: 구글 클라우드 Pub/Sub의 소스 워터마크 사례)

Watermarks for Google Cloud Pub/Sub

각 client들은 구독을 하고 메세지를 pull 하는 방식. 최대한 old한 메세지부터 pull 되게 하지만, 강한 보장은 없다. 원본 데이터가 “Well behaved”라고 가정. 어느 정도의 순서 어긋남은 허용하지만, 그 범위는 제한. 현재 구현에서는 최소 10초의 재정렬을 허용하며, 이 범위를 벗어난 타임스탬프를 가진 데이터는 지연 데이터(late data)로 간주. 이 10초=추정 대역(estimation band). 기본구독/추적구독을 두고 메세지를 소비하는 기본구독 되에 빠르게 메타데이터만 소비하는 추적구독이 백로그 내 이벤트 타임스탬프의 최솟값을 가져옴. 추적구독이 기본구독보다 충분히 (최소 추정 대역만큼)앞서고 있고, 실제 시간에 가까우면 (백로그가 없으면) 이 추적구독의 데이터를 기반으로 워터마크를 추정함. -> 기본 구독의 가장 오래된 미확인 메시지보다 새로운 게시 타임스탬프를 가진, 또는 추정 대역 너비만큼의 추적 구독에서 읽은 이벤트 타임스탬프 대역을 고려하여, 이 대역 내의 최소 이벤트 시간을 워터마크 값으로 계산.

그림 3-19에서 보면 pt=100인게 ack를 안보낸 것 중 가장 오래 된 메세지. (pub/sub에서는 처리를 하고 나면 ack를 보냄.) ack가 안된거는 전달이 안되었거나, 전달까진 되었으나 처리되지 않은것임. pt=101인거는 게시는 더 나중에 된 것으로 보이나 처리가 완료되어서 ack까지 간 상태인 것.