Continuous Processing — 마이크로배치를 포기하고 밀리초 지연을 얻는 실험적 모드
Spark Continuous Processing 및 Barrier Execution Mode 공식 문서 종합 (웹 리서치, 2026) — Apache Spark 공식 문서(streaming/performance-tips.html) + Apache Spark JIRA(SPARK-24374, Project Hydrogen) Apache Spark 공식 문서 Structured Streaming Performance Tips
이 모듈을 다 읽으면
- Continuous Processing이 마이크로배치와 근본적으로 다른 실행 모델을 쓴다는 것을 설명할 수 있다
- 지연시간을 얻는 대신 어떤 보장 수준과 제약을 감수해야 하는지 설명할 수 있다
spark-learn-37에서 다룬 마이크로배치 기반 Structured Streaming을 전제로, 짧은 배치를 반복하는 대신 계속 실행되는 태스크로 밀리초 단위 지연을 노리는 대안 실행 모드 Continuous Processing의 동작 방식과 제약을 정리한다.
실행 모델 자체가 다르다 — 짧은 배치 반복이 아니라 '계속 도는 태스크'
기본 마이크로배치 모드는 짧은 배치 잡을 반복 실행하는 방식이라 배치 간격만큼의 지연이 항상 존재한다. Continuous Processing은 이와 달리 여러 개의 오래 실행되는(long-running) 태스크를 띄워, 그 태스크들이 소스에서 계속 데이터를 읽고, 처리하고, 싱크에 계속 쓰는 방식으로 동작한다 — 배치라는 단위 자체가 없어지는 셈이다. 이 덕분에 종단 간(end-to-end) 지연시간을 밀리초 수준까지 낮출 수 있다.
핵심 포인트
- 마이크로배치: 짧은 배치 잡 반복 실행, 배치 간격만큼의 지연 항상 존재
- Continuous Processing: 오래 실행되는 태스크가 소스→처리→싱크를 계속 이어감 — 배치 단위 자체가 없어 밀리초 수준 지연 가능
얻는 것과 잃는 것 — 지연시간 대신 exactly-once를 포기
기본 마이크로배치 모드가 exactly-once 보장을 제공하는 반면, Continuous Processing은 at-least-once만 보장한다 — 지연시간을 극단적으로 줄이는 대가로 정확히 한 번 처리 보장 수준을 낮추는 트레이드오프다. 이는 애플리케이션이 중복 처리에 대한 별도 대응(멱등적 쓰기 등)을 스스로 마련해야 한다는 뜻이다.
핵심 포인트
- Continuous Processing은 at-least-once만 보장(기본 마이크로배치는 exactly-once) — 밀리초 지연의 대가
- 애플리케이션이 중복 처리 가능성에 대비해 멱등적 쓰기 등 자체 대응을 마련해야 함
지원 범위가 제한적 — 소스/싱크와 연산 모두 제약
지원되는 소스는 Kafka와 rate 기반 소스(테스트용으로 일정 간격마다 타임스탬프·카운터 행을 생성)뿐이고, 싱크는 Kafka와 Console(디버깅용 Memory 싱크도 가능)만 지원한다. 지원 연산도 제한적이라, 지원되지 않는 소스·연산·싱크 조합으로 쿼리를 실행하려 하면 쿼리를 띄우기도 전에 UnsupportedOperationException이 발생한다. 이런 제약들 때문에 spark-learn-37에서도 언급했듯 실무에서는 여전히 마이크로배치가 사실상 유일한 선택지로 쓰이고, Continuous Processing은 초저지연이 반드시 필요한 특수한 상황에서만 검토 대상이 된다.
핵심 포인트
- 지원 소스: Kafka, rate 기반 소스뿐 / 지원 싱크: Kafka, Console(디버깅용 Memory 포함)뿐
- 지원 안 되는 조합은 쿼리 시작 전 UnsupportedOperationException 발생 — 이 제약들 때문에 실무에서는 여전히 마이크로배치가 사실상 유일한 선택지