다중 워터마크 정책 — 여러 스트림의 워터마크가 다르면 무엇을 기준으로 삼는가
Delta Lake Generated Columns 및 Spark 다중 워터마크 정책 공식 문서 종합 (웹 리서치, 2026) — Databricks 공식 문서(delta/generated-columns), Apache Spark 공식문서(Structured Streaming Programming Guide — multiple watermarks) Apache Spark 공식문서 Structured Streaming Programming Guide
이 모듈을 다 읽으면
- spark-learn-67의 Stream-Stream Join처럼 여러 입력에 각자 워터마크가 있을 때, 전역 워터마크가 어떻게 하나로 정해지는지 설명할 수 있다
- min 정책(기본값)과 max 정책이 각각 어떤 대가를 치르는지 설명할 수 있다
spark-learn-44에서 다룬 단일 워터마크와 spark-learn-67의 Stream-Stream Join(양쪽 입력 각각에 워터마크가 필요)을 전제로, 여러 스트림에 서로 다른 워터마크가 동시에 존재할 때 이를 하나의 전역 값으로 합치는 정책을 정리한다.
min 정책(기본값) — 가장 느린 스트림 속도에 맞춘다
spark-learn-67의 Stream-Stream Join처럼 쿼리에 워터마크가 여러 개 있는 상황에서, spark.sql.streaming.multipleWatermarkPolicy의 기본값은 min이다 — 여러 워터마크 중 가장 작은(가장 뒤처진) 값을 전역 워터마크로 쓴다. 이렇게 하면 한 스트림이 다른 스트림보다 느려도, 그 느린 스트림의 데이터를 성급하게 '늦었다'고 판단해 버리는 실수를 막을 수 있다 — 전역 워터마크가 가장 느린 스트림의 속도에 맞춰 안전하게 전진하고, 필요하면 쿼리 출력 자체를 지연시킨다.
핵심 포인트
- 기본값 min: 여러 워터마크 중 가장 작은(뒤처진) 값을 전역 워터마크로 채택 — 느린 스트림 데이터를 성급하게 늦었다고 판단하는 실수 방지
- 전역 워터마크가 가장 느린 스트림 속도에 맞춰 전진 — 필요하면 쿼리 출력이 지연됨
max 정책 — 빠르지만 느린 스트림 데이터를 공격적으로 버린다
Spark 2.4부터는 이 정책을 max로 바꿀 수 있다 — 전역 워터마크가 가장 빠른 스트림의 속도로 전진하게 된다. 이러면 쿼리 출력 지연은 줄지만, 그 대가로 더 느린 스트림에서 오는 데이터는 공격적으로(aggressively) 버려질 수 있다 — 이미 전역 워터마크가 그 느린 스트림 기준으로는 한참 지나버린 시점을 가리키기 때문이다. 공식 문서는 이 설정을 신중하게(judiciously) 쓰라고 권고하고, 쿼리 실행 중간에 이 정책을 바꾸면 워터마크 값 자체가 일관성을 잃을 수 있다고 경고한다 — 즉 한 번 정하면 바꾸지 않는 게 원칙이다.
핵심 포인트
- max 정책(2.4+): 전역 워터마크가 가장 빠른 스트림 속도로 전진 — 출력 지연은 줄지만 느린 스트림 데이터가 공격적으로 버려질 수 있음
- 공식 문서 권고: 신중히 사용, 쿼리 실행 중간에 정책을 바꾸면 워터마크 값 자체가 일관성을 잃을 수 있어 한 번 정하면 안 바꾸는 게 원칙