Quiz: Event time, watermarks and late rows

WATERMARK FOR ts AS ts - INTERVAL '5' SECOND 인 표에서 지금까지 본 최대 ts 가 12:03:20 이다. 1분 TUMBLE 창 [12:03:00, 12:04:00) 에 12:03:10 의 행이 도착하면?

• 창이 이미 닫혔으므로 버려진다
• 워터마크 12:03:15 는 창 끝보다 이르므로 창이 받는다
• 워터마크보다 이른 행이라 오류가 난다
• 창이 다시 열려 결과를 -U/+U 로 고친다

같은 자료에서 지연을 5초에서 30초로 늘렸다. 무엇이 달라지나?

• 창 결과가 나오는 시점이 늦어지는 대신 버려지는 행이 줄어든다
• 버려지는 행은 그대로이고 창 결과만 빨리 나온다
• 창 크기가 30초 늘어나 창마다 행이 더 들어간다
• 배치 모드와 똑같이 동작해 워터마크를 쓰지 않는다

5초 지연에서 ts <= CURRENT_WATERMARK(ts) 인 행은 98건인데, 창 집계가 버린 행은 15건이었다. 차이가 나는 이유는?

• CURRENT_WATERMARK 가 처리 시간 기준이라 값이 다르다
• 창 집계가 늦은 행 일부를 다음 창으로 옮겨 넣었다
• 워터마크보다 이른 행이라도 그 행의 창 끝이 아직 워터마크 뒤면 창이 받아 준다
• sql-client 가 늦은 행 일부를 출력하지 않았다

행이 보는 CURRENT_WATERMARK 가 '자기 자신을 포함한' 최대 ts 가 아니라 '앞 행들까지의' 최대 ts − 지연인 이유는?

• 워터마크는 체크포인트가 끝날 때만 갱신되기 때문이다
• SQL 이 행을 ts 순서로 정렬한 뒤 처리하기 때문이다
• 워터마크는 창이 닫힐 때만 계산되기 때문이다
• 워터마크 생성기가 레코드를 먼저 내보내고 그 뒤에 워터마크를 올리기 때문이다

pipeline.auto-watermark-interval 을 1h 로 바꿨더니 끝이 있는 파일에서 버려진 행이 0건이 됐다. 가장 정확한 설명은?

• 워터마크가 첫 값 뒤로 전진하지 않아 창이 파일 끝의 최대 워터마크에서 한꺼번에 닫혔다
• 간격이 길면 Flink 가 자동으로 배치 모드로 바꾼다
• 간격이 길면 지연이 1시간으로 늘어난 것과 같다
• 간격 설정은 늦은 행을 버리지 말라는 뜻이다

병렬도 4 인 원천 중 파티션 하나에 한동안 자료가 오지 않는다. 창 결과가 멈췄다. 왜 그런가?

• 다른 세 파티션의 워터마크가 평균으로 낮아져서
• 창 연산자의 이벤트 시간은 입력 워터마크들의 최솟값이라 조용한 파티션이 전체를 붙잡아서
• 자료가 없는 파티션이 늦은 행을 만들어서
• 파티션 수가 슬롯 수보다 많아서