Batch 개념

배치란?

일정량의 데이터를 모아서, 정해진 시점에, 한꺼번에 처리하는 방식

실시간:  요청 → 처리 → 응답 → 요청 → 처리 → 응답 ...
배치:    [데이터 쌓임 .......................] → 한 번에 처리 → 결과

배치 vs 실시간(스트림)

구분	배치	실시간 / 스트림
처리 시점	정해진 주기	이벤트 발생 즉시
처리 단위	대량 묶음	건건 또는 작은 단위
지연(latency)	큼 (분~시간)	작음 (ms~초)
처리량(throughput)	높음	상대적으로 낮음
복잡도	낮음, 재실행 쉬움	높음, 순서·유실 고려
예시	일일 정산, 데이터 동기화	결제 승인, 알림

핵심 용어

용어	뜻
Job	배치의 최상위 작업 단위
Step	Job을 구성하는 단계
Chunk	한 번에 처리하는 묶음
Trigger / Scheduler	언제 실행할지 결정
Reader / Processor / Writer	읽기 → 가공 → 쓰기
Checkpoint / Offset	어디까지 처리했는지 기록
Retry	일시적 실패 시 재시도
Skip	문제 있는 건만 건너뛰기
Idempotent	여러 번 실행해도 결과 동일

표준 구조: ETL

1. 정의

Extract (추출) -> Transform (변환) -> Load (적재)
여러 소스의 데이터를 꺼내, 목적에 맞게 가공한 뒤, 대상 저장소에 넣는 데이터 파이프라인 방식

2. 단계별 역할

1. Extract (추출)

   • 하는 일: 원본에서 데이터를 읽어옴
   • 대표 작업: API 호출, DB 조회, 파일 읽기, 크롤링
   • 흔한 실패: 네트워크 오류, 인증, 페이지네이션 누락

2. Transform (변환)

   • 하는 일: 목적에 맞게 가공
   • 대표 작업: 포맷 통일, 타입 변환, 결측 처리, 중복 제거, 조인, 마스킹
   • 흔한 실패: 스키마 불일치, 잘못된 값, 매칭 실패

3. Load (적재)

   • 하는 일: 목적지에 저장
   • 대표 작업: insert, upsert, 벌크 적재
   • 흔한 실패: 중복, 부분 저장, 제약 조건 위반

3. 각 단계에서 알아야 할 개념

1. Extract

   • Full vs Incremental: 전체를 매번 가져올지, 변경분만 가져올지
   • Pagination: 한 번에 다 못 가져오는 경우의 순회
   • Source 다양성: DB / API / 파일 / 웹페이지

2. Transform

   • 정규화(Normalization): 서로 다른 포맷을 공통 모델로
   • Validation: 값이 유효한지 검증
   • Enrichment: 다른 소스와 결합해 정보 보강
   • Cleansing: 공백, 결측, 이상치 처리

3. Load

   • Insert vs Upsert: 신규만 넣을지, 있으면 갱신할지
   • Idempotency: 여러 번 실행해도 결과 동일
   • Batch write: 건건이 아니라 묶음으로 저장

4. ETL vs ELT

• ETL
  • 순서: 변환 후 적재
  • 변환 위치: 별도 처리 서버/애플리케이션
  • 적합한 경우: 소스가 불안정·비정형, 적재 전 검증 필요
  • 대표 환경: 애플리케이션 배치
• ELT
  • 순서: 적재 후 변환
  • 변환 위치: 대상 DB(웨어하우스) 내부
  • 적합한 경우: 대용량, 강력한 DW 보유
  • 대표 환경: BigQuery, Snowflake 기반 분석

5. 교내 시스템 예시

• Extract: 공지, 학식, 학사일정, 셔틀 웹페이지
• Transform: 각 HTML -> Notice/CafeteriaDiet/Schedule
• Load: key 기준 upsert

6. ETL에서 자주 쓰는 설계 원칙

1. 단계 분리: 추출, 변환, 적재를 각각 독립 단위로 (테스트와 교체 용이)
2. 공통 모델: 소스가 늘어도 변환 결과는 하나로
3. 멱등성: 재실행해도 안전하게
4. 부분 실패 격리: 한 소스 실패가 전체를 막지 않게
5. 관측 가능성: 단계별 성공, 실패, 건수를 로그로 출력하고, DB에 저장
6. 순수 함수로 변환: Transform은 입력 -> 출력만 있게 만들면 테스트가 쉬움

핵심: 소스가 달라도 중간에 공통 모델로 통일하면, 뒷단은 소스를 몰라도 된다.

배치가 지켜야 할 4가지 성질

성질	질문	위반 시
멱등성	다시 돌려도 안전한가?	데이터 중복·오염
재실행성	실패 후 이어서 돌릴 수 있는가?	수동 복구 필요
관측 가능성	무슨 일이 일어났는지 알 수 있는가?	장애 원인 추적 불가
부분 실패 허용	일부 실패가 전체를 멈추는가?	한 소스 장애로 전체 중단

요구사항	대응되는 성질
중복 저장 금지	멱등성
502 재시도	재실행성 / 부분 실패 허용
Logger, DB 로그 저장	관측 가능성
전체 멈춤 시 console.log	관측 가능성

대표 실패 유형

1. 외부 시스템 장애 (502)
2. 데이터 오류 (형식 불일치, 필수값 누락)
3. 중복 실행
4. 부분 성공 (100건 중 50건만 저장된 채 중단)
5. 자원 문제 (메모리 부족, 타임아웃)

유명 배치 도구 (이름만)

도구	한 줄 설명
cron	OS 레벨 스케줄러
Spring Batch	Java 배치 프레임워크 표준 (Job/Step/Chunk 출처)
Airflow	워크플로(DAG) 기반 오케스트레이션
Quartz	Java 스케줄러 라이브러리
BullMQ	Node.js Redis 기반 작업 큐
Kafka / Flink	스트림 처리 대표

Spring Batch

1. 정의

자바 기반의 스프링 생태계에서 대용량 데이터를 안정적이고 효율적으로 일괄 처리하기 위해 지원하는 프레임워크

2. 전체 계층 구조

1. Job: 배치 처리의 최상위 단위이며, 하나 이상의 Step으로 구성
2. Step: Job을 구성하는 독립적인 실행 단위. Step은 크게 Tasklet 방식과 Chunk 지향 처리 방식으로 나뉨.
3. Chunk: 데이터들을 일정한 덩어리(블록) 단위로 묶은 것을 의미하며, 이 단위별로 트랜잭션(Commit/Rollback)이 수행

3. Chunk 지향 처리 핵심 구성 요소

1. ItemReader
   • 데이터를 한 번에 1건씩 읽어옴
   • 파일, 데이터베이스, 메시지 큐 등 다양한 소스에서 데이터를 조회
2. ItemProcessor (선택 사항)
   • Reader가 읽은 데이터 1건을 가공, 필터링, 변환
   • 반환값이 null이면 해당 데이터는 Writer로 전달되지 않고 필터링
3. ItemWriter
   • Processor를 거쳐 1건씩 쌓인 Chunk 단위(묶음)의 데이터를 한꺼번에 일괄 처리(DB Insert, 파일 출력 등)

4. 동작 흐름

• 예를 들어 Chunk Size가 5인 경우의 동작 방식은 다음과 같음

1. ItemReader가 데이터를 1건씩 5번 읽음
2. 읽은 5건의 데이터를 각각 ItemProcessor가 1건씩 5번 가공
3. 가공이 완료된 5건을 하나의 Chunk 묶음으로 만들어 ItemWriter에게 한 번에 전달하여 일괄 처리
4. 이 1개 Chunk 처리가 완료될 때 트랜잭션이 Commit됨
5. 중간에 예외(에러)가 발생하면, 해당 Chunk 범위까지만 Rollback 되고 이전에 커밋된 범위는 유지됨

Idempotent Batch Design (멱등성 배치 디자인)

1. 개념

동일한 대용량 데이터 배치 작업을 여러 번 실행해도 결과가 항상 동일하게 유지되도록 시스템을 설계하는 개념
중간에 시스템이 멈추거나 네트워크 오류가 발생해 같은 데이터를 다시 처리하더라도, 데이터가 중복으로 쌓이거나 손상되지 않고 언제나 데이터베이스의 최종 상태를 올바르게 보장하는 것이 핵심

2. 멱등성 배치가 필요한 이유

• 분산 시스템이나 대규모 데이터 엔지니어링에서 데이터는 보통 최소 한 번은 전송(At-least-once delivery) 되는 것을 목표로 함
• 시스템 장애나 타임아웃이 발생하면 “성공했는지 모호한” 상태가 되기 때문에, 시스템은 보통 안전하게 재시도를 선택
• 이때 배치가 멱등성을 갖추지 못하면 다음과 같은 심각한 문제가 발생
  • 데이터 중복: 어제 결제한 내역이 오늘 배치 재실행으로 인해 이중으로 청구되거나 포인트가 중복 적립됨.
  • 데이터 불일치: 통계 데이터가 누적 계산되어 수치가 비정상적으로 부풀어 오름.

3. 주요 구현 전략 및 패턴

1. 쓰기 단계에서 Upsert (기존 데이터 덮어쓰기)
   • 개념: INSERT 대신 식별자(PK)를 기준으로 이미 데이터가 존재하면 변경(Update). 없으면 삽입(Insert)하는 방식을 사용
   • 효과: 동일한 배치를 10번 실행해도 최종 데이터베이스에는 단 1개의 고유한 레코드만 남게 됨
2. 실행 전 기존 결과 삭제 (Clean & Rewrite)
   • 개념: 특정 날짜나 특정 배치 ID에 해당하는 데이터를 통째로 지우고 다시 처음부터 정밀하게 다시 쓰는 방식
   • 효과: 예를 들어 2026-10-12 날짜의 일간 통계 배치를 재실행한다면, 먼저 해당 날짜의 기존 통계 데이터를 DELETE 한 후 새로 계산된 데이터를 집어넣음
3. 고유한 식별자 및 중복 제거 (Idempotency Key)
   • 개념: 소스 데이터의 고유 키(예: 원본 거래 ID + 날짜 조합)를 해시값 등으로 묶어 시스템에 기록해둠
   • 효과: 배치가 실행될 때 처리 이력 테이블(Idempotency Table)을 먼저 조회하여 이미 성공적으로 처리된 키라면 계산을 건너뛰고 다음 데이터로 넘어감

전략	장점	단점 / 고려사항
Upsert 패턴	구현이 비교적 간단하고 실시간 데이터 흐름(Stream)에도 유리함	데이터베이스에 부하를 줄 수 있으며, 기존 상태를 덮어쓰므로 이력 추적이 어려울 수 있음
Clean & Rewrite	누적 통계나 일괄 분석(OLAP) 환경에서 가장 확실하고 안전함	대용량 데이터를 매번 지우고 쓰는 과정에서 쓰기 비용(I/O)이 많이 발생함
Idempotency Key	정확한 중복 제거(Skip)가 가능하여 불필요한 연산을 최소화함	별도의 이력 관리 저장소가 필요하며, 분산 환경에서 락(Lock) 관리가 복잡해질 수 있음

검색어

• batch processing vs stream processing 차이
• ETL 이란
• Spring Batch Job Step Chunk 구조
• idempotent batch design