Brain💡 핵심 인사이트 배치 처리(Batch Processing)는 "대량의 데이터를 일정한 시간 간격 또는 정해진 시점에 모아서 한꺼번에 일괄 처리하는" 데이터 처리 방식입니다. 스트림 처리가 "데이터가 도착하는 즉시 처리"한다면, 배치 처리는 "데이터를 모아서 한 번에 처리"합니다. 이 방식은 대규모 데이터 변환, ETL, 리포트 생성, 데이터 마이닝 등 **처리 시간을 어느 정도 여유롭게 가져갈 수 있는 환경**에서 효율적입니다. Apache Hadoop MapReduce, Spark, Cron job 등이 대표적인 배치 처리 기술입니다.
Ⅰ. 배치 처리의 기본 개념: 모으고, 처리하고, 내보내기
배치 처리의 핵심은 데이터를 수집 → 처리 → 결과 산출의 주기를 갖는다는 것입니다.
[배치 처리 주기]
┌─────────────────────────────────────────────────────────────────┐
│ 배치 처리 주기 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 데이터 소스 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ OLTP DB │ │ 외부 API │ │ 파일 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 수집 (Extract) │ ◀── 정시(夜间 등)에 실행 │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 변환(Transform)│ ◀── 복잡한 Join, 집계, 정제 │
│ │ │ 대량 CPU 소모 작업 │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 적재 (Load) │ ◀── DW, Data Lake 등 │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 결과 산출 │ ◀── 리포트, 피드백 │
│ │ (Result) │ │
│ └───────────────┘ │
│ │
│ Batch Job 실행 주기: hourly, daily, weekly, monthly │
│ │
└─────────────────────────────────────────────────────────────────┘
배치 처리가 적합한 작업:
- 대규모 데이터 집계/통계: 월말 정산, 요약 보고서
- 복잡한 조인/변환: 다수의 소스를 조합한 데이터 정제
- 대량 데이터 migration: 시스템 전환 시 데이터 이전
- 알고리즘 중심 분석: 머신러닝 모델 훈련 (Batch Training)
Ⅱ. 배치 처리의 기술 생태계: Hadoop에서 Spark까지
배치 처리 기술은 오랜 기간 발전해 왔습니다.
1. Apache Hadoop MapReduce (선구자)
// MapReduce Word Count 예시
// Map 단계: 각 라인에서 단어 추출
Map(String text, Integer lineNum):
for each word in text.split():
Emit(word, 1) // (단어, 1) 쌍 출력
// Reduce 단계: 동일 단어의 빈도 합산
Reduce(String word, Iterator counts):
sum = 0
for each count in counts:
sum += count
Emit(word, sum) // (단어, 총빈도) 출력
- Map: 데이터를 **key-value pairs**로 변환 (파티셔닝)
- Shuffle: 동일 키를 가진 데이터 네트워크를 통해Reducer에 전달
- Reduce: 동일 키에 대해 연산 수행 후 결과 산출
2. Apache Spark (현대의 표준)
Hadoop MapReduce를 대체하는 최신 배치 처리 엔진입니다.
// Spark Word Count ( Scala )
val lines = spark.read.textFile("hdfs://input/data.txt")
val counts = lines
.flatMap(_.split(" "))
.map(word => (word, 1))
.reduceByKey(_ + _)
counts.saveAsTextFile("hdfs://output/result")
// 장점:
// - In-memory 연산: MapReduce보다 10~100배 빠름
// -lazy evaluation: 필요 시점까지 실행 미루어 최적화
// - Rich API: Scala, Python, Java, R 지원
Ⅲ. 배치 처리 아키텍처: 워크플로우와调度
배치 처리는 단순한 기술이 아니라 엔드투엔드 파이프라인입니다.
[배치 처리 파이프라인 아키텍처]
┌─────────────────────────────────────────────────────────────────┐
│ 배치 처리 워크플로우 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 소스 시스템 ETL/ELT Layer 타겟 시스템 │
│ ┌─────────┐ ┌──────────────┐ ┌─────────┐ │
│ │ ERP │──────>│ Apache Airflow │────>│ DW │ │
│ │ (Oracle)│ │ ( orchestration) │ │ (Snowflake│ │
│ └─────────┘ │ │ │ ) │ │
│ │ ┌───────────┐ │ └─────────┘ │
│ ┌─────────┐ │ │ Task 1 │ │ ┌─────────┐ │
│ │ CRM │──────>│ │ (Extract) │ │────>│ Data │ │
│ │ (MySQL) │ │ └───────────┘ │ │ Lake │ │
│ └─────────┘ │ ┌───────────┐ │ │ (S3) │ │
│ │ │ Task 2 │ │ └─────────┘ │
│ ┌─────────┐ │ │ (Transform│ │ ┌─────────┐ │
│ │ 외부 API │──────>│ │ & Load) │ │────>│ ML │ │
│ │ │ │ └───────────┘ │ │ Platform │ │
│ └─────────┘ └──────────────┘ └─────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 스케줄러 │ │
│ │ (Crontab, │ │
│ │ Airflow, │ │
│ │ Oozie) │ │
│ └──────────────┘ │
│ │
│ 실행 주기: │
│ - Hourly: 每正시 실행 │
│ - Daily: 02:00 (OLTP 부하最低時に) │
│ - Weekly: Sunday 01:00 │
│ - Monthly: 1일 03:00 │
│ │
└─────────────────────────────────────────────────────────────────┘
Apache Airflow는 대표적인 워크플로우 오케스트레이션 도구입니다:
- Python으로 DAG(Directed Acyclic Graph) 정의
- 태스크 간 의존성 자동 관리
- 실패 시 자동 Retry, 알림
- 웹 UI로 모니터링
Ⅳ. 배치 처리와 스트림 처리의 비교
[배치 vs 스트림: 종합 비교]
┌─────────────────┬────────────────────────┬────────────────────────┐
│ 항목 │ 배치 처리 │ 스트림 처리 │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 처리 방식 │ 일정 시간 모았다가 한꺼번에 │ 데이터 도착 즉시 처리 │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 지연 (Latency) │ 수시간 ~ 수일 │ 수초 ~ 수밀리초 │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 처리량 (Throughput)│ 대량 (수십 GB ~ 수 TB) │ 상대적으로 소량 (GB 수준) │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 데이터 모델 │ 유한 데이터셋 │ 무한 이벤트 스트림 │
├─────────────────┼────────────────────────┼────────────────────────┤
│故障 대응 │ 실패 시 해당 배치만 재실행 │ checkpoint 기반 복구 │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 구현 난이도 │ 비교적 단순 │ 상태 관리, 순서 보장 등 복잡 │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 비용 │ 간헐적 대량 컴퓨팅 │ 상시 실행 미들티어 │
├─────────────────┼────────────────────────┼────────────────────────┤
│ 적합 업무 │ 월정산, 리포트, 일별 집계 │ 모니터링, 알림, 실시간 분석 │
│ │ 대량 데이터 마이그레이션 │ 사기 감지, IoT 센서 처리 │
└─────────────────┴────────────────────────┴────────────────────────┘
실무에서는 Hybrid: 많은 시스템이 **배치 + 스트림**을 함께 사용합니다:
- 실시간 스트림: 운영 지표, 모니터링, 즉각적 알림
- 배치: 일별/월별 정산, 복잡한 분석, ML 모델 재훈련
Ⅴ. 배치 처리의 실제 적용과 📢 비유
Lambda Architecture: 배치와 스트림을 결합한 전형적인 아키텍처입니다.
[Lambda Architecture]
┌─────────────────────────────────────────────────────────────────┐
│ Lambda Architecture │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 사용자 질의 │
│ │ │
│ ┌────────────┴────────────┐ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 배치 레이어 │ │ 속도 레이어 │ │
│ │ (Batch View) │ │ (Speed/Stream │ │
│ │ │ │ View) │ │
│ │ - 전체 데이터 일별 │ │ - 최근 데이터만 │ │
│ │ 배치 처리 │ │ 실시간 처리 │ │
│ │ - 완전한 정확도 │ │ - 빠른 응답, 근사 │ │
│ │ │ │ 값 │ │
│ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │
│ └────────────┬────────────┘ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ 서빙 레이어 │ │
│ │ (Serving Layer) │ │
│ │ 배치뷰 + 스피드뷰 │ │
│ │ 병합하여 결과 반환 │ │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Kappa Architecture: Lambda의 복잡성(배치/스트림 두 코드베이스 유지)을 피하기 위해, 모든 것을 스트림으로만 처리하는 접근법입니다. Kafka에 전체 이력을 저장하고, 필요 시 스트림을 다시 읽어(Replay) 배치처럼 처리합니다.
📢 섹션 요약 비유: 배치 처리는 **"시골 배달 시스템에 비유"할 수 있습니다. 매일 아침 (정해진 시간에) "각 가정에서 보내는 소포를 마을 회관에서 모아, 자동차에 싣고, 각 개별 가정으로Delivery하는" 것과 같습니다. 즉각적이지 않지만 (기다림이 필요하지만), 한 번의運行으로 효율적으로 (비용과 시간을 절약하며) 처리가 완료됩니다. 반면 스트림 처리는 "택배 상자를 받는 순간 바로Doorstep에 놓는 (수령인은 기다리지 않아도 되는) 것과 같습니다. 신선도는 높지만, 배달원이 매번 움직여야 하는 (항시 리소스가 필요한) 부담이 있습니다. 상황에 따라 (대량 물품 이동이냐, 신선 식품 배달이냐) 적절한 방식을 선택해야 합니다.