배치와 스트림, 하나의 엔진으로 — Spark 관점에서 재구성한 처리 모델 비교
Batch vs Stream Processing: The Plain-English Guide (2026) — (블로그, 발행처 미상) Batch vs Stream Processing: The Plain-English Guide (2026) — 전체(1~7페이지, assumption/time semantics/computation model/state 구간)를 Spark 아키텍처 관점에서 재구성
이 모듈을 다 읽으면
- 이 가이드가 부제(Spark vs Flink vs Kafka)에서 예고한 도구 비교를 본문에서 실제로 다루지 않는다는 점을 지적하고, 그 공백을 Spark의 실제 동작으로 채울 수 있다
- Structured Streaming이 '스트림을 계속 자라나는 테이블로 본다'는 모델을 통해 배치용 DataFrame API를 스트리밍에도 그대로 재사용하는 원리를 설명할 수 있다
- 가이드가 이분법으로 제시한 '배치=상태 없음, 스트리밍=상태 영속'이라는 구도가 Spark 내부에서는 RDD 계보 재구성과 체크포인트 상태 저장소로 각각 구현된다는 것을 설명할 수 있다
이 가이드는 배치와 스트림 처리를 데이터에 대한 가정, 시간 의미, 계산 모델, 상태 관리 등 도구에 종속되지 않는 8가지 축으로 비교하지만, 부제에서 예고한 'Spark vs Flink vs Kafka' 비교는 본문 어디에도 등장하지 않는다. 이 공백을 Spark 자체의 관점에서 메우면, Spark는 배치와 스트리밍을 서로 다른 두 엔진이 아니라 하나의 Structured API(DataFrame) 위에서 지원한다는 점이 핵심이다. Structured Streaming은 스트림을 '끝없이 행이 추가되는 테이블'로 보고, 배치 코드와 거의 동일한 DataFrame 연산을 그 테이블에 반복 실행하는 마이크로배치 모델로 구현된다. 가이드가 '배치는 상태가 잡이 끝나면 사라지고 스트리밍은 상태가 계속 유지된다'고 이분법으로 설명한 부분은 Spark 안에서는 배치 잡이 매번 RDD 계보를 처음부터 재구성하는 것과, Structured Streaming이 체크포인트 위치에 상태 저장소(state store)를 두어 마이크로배치 사이에도 상태를 이어가는 것으로 구체화된다.
이 자료가 다루지 않은 것 — 부제의 'Spark vs Flink vs Kafka'는 본문에 없다
이 가이드의 부제는 '배치 vs 스트림 처리를 설명하며 Spark vs Flink vs Kafka 같은 도구까지 다룬다'고 예고하지만, 실제 본문은 assumption about data, time semantics, freshness, failure handling, computation model, state management, cost, output nature라는 여덟 가지 축으로 배치와 스트림이라는 두 '개념'만 비교할 뿐, Spark나 Flink나 Kafka라는 이름은 마지막 다른 글 추천 문구를 빼면 등장하지 않는다. 이는 사실 오류라기보다 제목과 본문 사이의 기대 불일치이지만, 학습자가 이 자료만으로 실제 도구 선택까지 판단하려 하면 안 된다는 점을 분명히 해 둘 필요가 있다. 이어지는 절에서는 이 가이드가 다루는 여덟 가지 개념을 실제로 Spark라는 하나의 엔진이 어떻게 구현하고 있는지 연결한다.
핵심 포인트
- 가이드 부제는 Spark/Flink/Kafka 비교를 예고하지만 본문은 개념적 배치 vs 스트림 비교에 그친다
- 이 자료만으로 특정 도구를 선택하는 근거로 삼기는 어렵고, 실제 엔진 동작과 연결해서 읽어야 한다
Spark가 두 세계를 한 엔진에 담는 방법 — Structured Streaming은 배치 API 위에서 동작한다
가이드는 배치를 '유계(bounded) 데이터에 대한 일회성 실행', 스트림을 '무계(unbounded) 데이터에 대한 지속 실행'으로 구분한다. Spark는 바로 이 경계를 하나의 API로 허문다 — Structured Streaming은 스트림을 물리적으로 다른 무언가가 아니라 '끝없이 새 행이 추가되는 테이블(unbounded table)'로 취급하고, select/filter/groupBy 같은 배치용 DataFrame 연산을 그 테이블에 그대로 적용한 뒤, 새로 도착한 부분에 대해서만 반복적으로 짧은 배치 잡(마이크로배치)을 실행한다. 이는 레코드 단위로 즉시 처리하는 이벤트 기반(event-at-a-time) 모델과는 다른 접근이다. Spark에는 이벤트 단위에 더 가까운 Continuous Processing 모드도 2.3부터 실험적으로 존재하지만, 지원하는 연산 종류가 제한적이라 여전히 실무에서는 마이크로배치가 기본값이자 사실상 유일한 선택지다. 참고로 Spark의 스트리밍 API는 역사적으로 RDD 기반의 DStream(레거시)과 DataFrame 기반의 Structured Streaming(현재 표준) 두 가지가 있었는데, 신규 파이프라인은 Structured Streaming을 쓰는 것이 맞다.
핵심 포인트
- Structured Streaming은 스트림을 '계속 자라나는 테이블'로 보고, 배치와 동일한 DataFrame 연산을 반복 실행하는 마이크로배치 모델로 동작한다
- 이벤트 단위로 즉시 처리하는 Continuous Processing 모드도 존재하지만 2.3부터 여전히 실험적이고 지원 연산이 제한적이라 마이크로배치가 사실상 기본값이다
- 레거시 RDD 기반 DStream과 현재 표준인 DataFrame 기반 Structured Streaming을 혼동하지 않아야 한다
state의 생애주기 — 배치의 RDD 계보 재구성 vs 스트리밍의 체크포인트 상태 저장소
가이드는 '배치의 상태는 잡이 끝나면 사라지고 다음 실행이 아무것도 기억하지 못한 채 처음부터 다시 만든다, 스트리밍의 상태는 오래 유지되며 새 데이터가 올 때마다 갱신된다'고 설명한다. Spark 안에서 이 구도가 어떻게 구현되는지 보면, 배치 잡은 실행될 때마다 RDD 계보(lineage)를 소스부터 새로 구성해 액션이 호출된 시점의 데이터로 전체 트랜스포메이션을 다시 계산한다 — 이전 실행의 중간 결과를 이어받지 않는다는 점에서 가이드의 설명과 정확히 들어맞는다. 반면 Structured Streaming은 마이크로배치마다 상태가 사라지면 집계나 조인 같은 상태 기반(stateful) 연산이 불가능하므로, 체크포인트 위치에 상태 저장소(state store)를 두어 마이크로배치 사이에도 중간 집계 결과를 이어간다. 다만 이 상태 저장소도 무한정 유지되는 것은 아니며, 워터마크나 상태 만료 설정으로 오래된 상태를 정리하는 부분은 스트림 처리 일반의 상태 관리 주제이므로 여기서는 깊이 다루지 않는다.
핵심 포인트
- 배치 잡은 실행될 때마다 RDD 계보를 소스부터 새로 구성하므로, 이전 실행의 중간 상태를 전혀 이어받지 않는다는 가이드의 설명과 일치한다
- Structured Streaming은 체크포인트 위치의 상태 저장소(state store)를 통해 마이크로배치 사이에도 집계·조인 같은 상태 기반 연산의 중간 결과를 이어간다
- 상태 만료·워터마크 같은 상세 상태 관리 주제는 스트림 처리 전반에 걸친 별도 영역이므로 이 모듈에서는 다루지 않는다