이전 글에서 ETL/ELT 기본 개념을 정리했다면, 이번엔 실무에서 반드시 마주치는 핵심 개념들을 다룹니다.
⚡ 1. Batch vs Streaming 파이프라인
Batch Processing
데이터를 일정 시간 동안 모아서 한꺼번에 처리하는 방식입니다. 스케줄에 따라 주기적으로 실행됩니다.
Source → [데이터 쌓임] → Batch Job 실행 (1시간/1일마다) → Target DW 적재Stream Processing
데이터가 발생하는 즉시 연속적으로 처리하는 방식입니다.
Source → 이벤트 발생 → Stream Processor → 실시간 적재/알림비교
| 구분 | Batch | Streaming |
|---|---|---|
| 처리 단위 | 대량 (묶음) | 이벤트 단위 |
| 지연(Latency) | 분~시간 | 밀리초~초 |
| 처리량(Throughput) | 높음 | 상대적으로 낮음 |
| 복잡도 | 낮음 | 높음 |
| 대표 도구 | Spark, dbt, Airflow | Kafka, Flink, Spark Streaming |
| 적합한 사례 | 일일 리포트, 정산 | 실시간 알림, 사기 탐지 |
🏗️ 2. Lambda / Kappa 아키텍처
Lambda 아키텍처
Batch와 Streaming을 병렬로 운영해 정확성과 실시간성을 동시에 확보하는 아키텍처입니다.
Data Source
├── Batch Layer → Batch View ─┐
│ (Hadoop/Spark, 높은 정확도) ├→ Serving Layer → 쿼리 응답
└── Speed Layer → Real-time View┘
(Kafka/Flink, 낮은 지연)- Batch Layer: 전체 데이터를 주기적으로 재처리. 정확하지만 느림.
- Speed Layer: 최근 데이터만 실시간 처리. 빠르지만 완전하지 않음.
- Serving Layer: 두 결과를 병합해 쿼리 응답.
⚠️ 단점: 두 레이어를 모두 유지해야 해서 복잡도가 높고, 같은 처리 로직을 두 번 작성해야 합니다.
Kappa 아키텍처
Lambda의 복잡성을 제거하고 스트리밍 단일 경로만 사용하는 아키텍처입니다.
Data Source
→ Append-only Event Log (Kafka)
→ Stream Processor (Flink / Spark Streaming)
→ Serving Layer모든 데이터를 이벤트 로그로 영구 보관하고, 재처리가 필요할 때는 처음부터 다시 읽습니다.
✅ 장점: 아키텍처가 단순하고 운영이 쉬움. 단, 스트리밍 처리 기술에 대한 높은 역량이 필요합니다.
🔁 3. 멱등성 (Idempotency)과 재실행 가능한 파이프라인
멱등성이란 동일한 작업을 여러 번 실행해도 결과가 항상 동일한 성질입니다.
파이프라인 장애 후 재실행 시, 데이터 중복이나 오염 없이 안전하게 복구할 수 있어야 합니다.
멱등성이 없는 경우 vs 있는 경우
❌ 멱등성 없음:
1회 실행 → 100행
2회 실행 → 200행 (중복 누적!)
3회 실행 → 300행 (집계 오류 발생)
✅ 멱등성 있음:
1회 실행 → 100행
2회 실행 → 100행 (동일)
3회 실행 → 100행 (동일)멱등성 구현 핵심 패턴
| 패턴 | 설명 |
|---|---|
| INSERT → UPSERT | 중복 키가 있으면 UPDATE, 없으면 INSERT |
| DELETE → INSERT | 먼저 기존 파티션 삭제 후 재삽입 (Overwrite) |
| 파티션 키 활용 | 날짜/시간 기준 파티션을 통째로 교체 |
| 고유 실행 ID | job_id로 중복 실행 여부를 추적·방지 |
📥 4. Incremental Load vs Full Refresh vs Backfill
Incremental Load (증분 적재)
마지막 실행 시점 이후 변경된 데이터만 추출해 적재합니다.
[1월 ✓] [2월 ✓] [3월 ✓] [4월 ✓] [5월 NEW →처리]- ✅ 빠른 처리 속도, 리소스 효율적
- ⚠️ 소스에서 변경 감지 필요, 삭제된 레코드 처리 어려움
Full Refresh (전체 갱신)
매번 전체 데이터를 삭제하고 소스에서 전부 다시 적재합니다.
실행 1회차 → 전체 삭제 후 100% 재적재
실행 2회차 → 전체 삭제 후 100% 재적재
실행 3회차 → 전체 삭제 후 100% 재적재- ✅ 구현이 단순, 데이터 일관성 보장
- ⚠️ 처리 시간·비용 증가, 대용량 테이블에 부적합
Backfill (소급 처리)
파이프라인 신규 도입 또는 로직 변경 후, 과거 특정 기간의 데이터를 재처리합니다.
새 로직 적용 → [2024-01 🔄] [2024-02 🔄] [2024-03 🔄] [2024-04 🔄] [2024-05 현재]- ✅ 로직 변경 시 과거 데이터 정합성 유지, 신규 컬럼 과거분 채우기
- ⚠️ 대규모 처리 비용 발생, 멱등성 설계가 필수
✅ 5. 데이터 품질 (Data Quality) 6대 원칙
데이터 품질은 파이프라인 신뢰성의 핵심입니다. 6가지 차원으로 측정하고 관리합니다.
| 차원 | 설명 | 예시 |
|---|---|---|
| Completeness (완전성) | 필요한 데이터가 누락 없이 존재하는가 | email 컬럼에 NULL이 없는가 |
| Accuracy (정확성) | 데이터가 실제 값을 정확히 반영하는가 | 상품 가격이 실제 판매 가격과 일치하는가 |
| Consistency (일관성) | 여러 시스템 간 데이터가 서로 일치하는가 | CRM과 DW의 고객 수가 동일한가 |
| Timeliness (적시성) | 데이터가 필요한 시점에 최신 상태인가 | 일일 리포트가 오전 9시 전에 갱신되는가 |
| Uniqueness (유일성) | 중복 레코드 없이 고유한 데이터인가 | user_id가 중복 없이 유일한가 |
| Validity (유효성) | 데이터가 정해진 형식·범위를 따르는가 | 나이 컬럼이 0~120 사이 값인가 |
파이프라인에서 품질 체크 적용 위치
Source → [수집 시 검증] → Staging → [변환 전 검증] → Transform → [변환 후 검증] → Target🛠️ 대표 도구: Great Expectations, dbt tests, Soda
파이프라인 각 단계에서 자동 품질 체크를 실행하고, 실패 시 알림을 보냅니다.
📝 정리
- Batch: 주기적 대량 처리 / Streaming: 실시간 이벤트 처리
- Lambda: Batch + Stream 병렬 운영 (복잡) / Kappa: Stream 단일 경로 (단순)
- 멱등성: 몇 번을 실행해도 같은 결과 → 안전한 재실행의 핵심
- Incremental: 변경분만 / Full Refresh: 전체 재적재 / Backfill: 과거 소급 처리
- Data Quality: 완전성·정확성·일관성·적시성·유일성·유효성 6가지로 측정
데이터를 향해, 한 걸음씩 천천히.