스파크 오퍼레이터 아키텍처 방향

Spark Streaming을 Spark Operator로 장기 실행시키고, 배치는 spark-submit로 On-Demand 실행한다.

Spark-Submit 과 Spark Streaming 비교

구분	spark-submit	Spark Streaming
실행 형태	배치(단발성) 또는 장시간 실행 모두 가능	장시간 실행(Streaming 전용)
작업 종료 시점	작업 완료 후 자동 종료 (배치) 또는 무한 루프 처리 가능	기본적으로 무한 루프, 명시적으로 종료해야 함
데이터 처리 방식	고정된 입력 데이터(파일, DB, S3 등)를 한 번에 처리	끊임없이 들어오는 데이터(Kafka, Socket 등)를 마이크로 배치/Continuous 모드로 처리
제출 방법	spark-submit CLI로 JAR/Py 파일 실행	spark-submit으로 실행은 동일하지만 코드 내부에서 스트리밍 API 사용
주요 API	DataFrame API, RDD API, SQL API	Structured Streaming API (readStream, writeStream)
실패 복구	재실행 시 처음부터 처리	체크포인트 기반으로 마지막 오프셋부터 복구
종료 조건	배치 완료 / 코드에서 명시적 종료	수동 종료 또는 외부 시그널
사용 사례	- 대용량 파일 변환

spark-submit 방식 활용

• 단발성 작업에 적합
  예: 하루치 로그를 모아서 Parquet로 변환, 대규모 집계, ML 모델 학습
• 주기 실행이 필요하면 Airflow, Jenkins, Cron 같은 잡 스케줄러와 연동
• 데이터가 계속 들어오지만 실시간성이 필요 없는 경우가 생기니 배치 간격(예: 매 10분)으로 실행하는 것이 효율적
• 장점은 실행 후 리소스 반납하기에 클러스터 리소스 효율적 활용
• 단점은 처리 주기 사이에 데이터 지연이 생김

Spark Streaming 활용

• 실시간 처리에 적합
  예: Kafka → Spark → 실시간 대시보드, Fraud Detection, IoT 이벤트 처리
• 장기간 프로세스가 유지되며 데이터 스트림을 지속적으로 수집/처리
• 마이크로 배치(예: 1초, 5초 단위) 또는 Continuous Processing 모드로 동작
• 장점은 이벤트 처리 지연 최소화, Kafka 오프셋 관리 및 체크포인트 기반 복구 가능
• 단점은 장기간 실행으로 리소스 점유하니, 운영 중 장애 처리/모니터링 필요