ETL, ELT, CDC, Orchestration
이 세션의 목표
데이터 플랫폼은 결국 데이터를 움직이는 시스템이다. 이때 자주 나오는 용어가 ETL, ELT, CDC, Orchestration이다.
- ETL: Extract → Transform → Load
- ELT: Extract → Load → Transform
- CDC: Change Data Capture
- Orchestration: 여러 작업의 순서, 의존성, 재시도, 스케줄을 관리
ETL과 ELT
ETL은 데이터를 가져와서 중간 처리 계층에서 변환한 뒤 목적지에 적재하는 방식이다.
ELT는 데이터를 먼저 목적지 저장소에 적재한 뒤, warehouse/lakehouse 내부 compute로 변환하는 방식이다.
| 방식 | 흐름 | 잘 맞는 상황 |
|---|---|---|
| ETL | source → transform engine → target | 목적지에 넣기 전 강한 정제가 필요할 때, target compute가 약할 때 |
| ELT | source → raw target → transform in target | warehouse/lakehouse compute가 강하고 raw 보존이 중요할 때 |
현대 cloud warehouse/lakehouse에서는 ELT가 자주 쓰인다. raw를 먼저 남기고, SQL/dbt/Spark로 transform하는 방식이 재처리와 추적에 유리하기 때문이다.
CDC: 변경분을 따라간다
CDC(Change Data Capture)는 DB의 변경 사항을 잡아 downstream으로 전달하는 방식이다. MySQL binlog, PostgreSQL WAL, SQL Server transaction log 같은 로그가 대표적인 source다.
CDC가 필요한 이유는 전체 dump를 매번 뜨기 어렵기 때문이다. 데이터가 크고 freshness 요구가 높으면 변경분만 전달해야 한다.
INSERT · UPDATE · DELETE → Change Log
binlog · WAL · redo log → CDC Connector
ordering · checkpoint → Warehouse / Lake
merge · upsert · history
CDC에서 DBA가 봐야 할 것
CDC는 단순히 “로그를 읽는다”가 아니다. 운영 DB의 특성과 downstream 모델이 함께 맞아야 한다.
| 체크 | 이유 |
|---|---|
| primary key 존재 | update/delete를 target에 정확히 반영하려면 key가 필요 |
| 이벤트 순서 | 같은 row의 update 순서가 뒤집히면 최종 상태가 틀림 |
| DDL 변경 | column 추가/삭제/타입 변경이 connector와 target schema를 깨뜨림 |
| snapshot + streaming 전환 | 초기 적재와 변경분 연결 구간에서 누락/중복 위험 |
| delete 처리 | hard delete, soft delete, tombstone 정책 결정 필요 |
| lag monitoring | source와 target의 시간 차이를 알아야 함 |
| idempotency | 같은 이벤트를 다시 처리해도 결과가 같아야 함 |
Orchestration
Orchestration은 작업을 “언제, 어떤 순서로, 실패하면 어떻게” 실행할지 관리한다. Airflow, Dagster, Prefect, Argo Workflows 같은 도구가 여기에 속한다.
Orchestration이 하는 일은 다음이다.
- 스케줄링
- dependency 관리
- retry
- backfill
- parameter 전달
- alert
- task log 수집
- SLA/timeout 관리
Orchestration은 pipeline 자체가 아니다. Pipeline을 실행하고 감시하는 control plane에 가깝다.
Batch, Streaming, Micro-batch
| 방식 | 설명 | 예시 |
|---|---|---|
| Batch | 일정 시간마다 묶어서 처리 | 매일 02:00 전체 집계 |
| Streaming | 이벤트가 들어오면 계속 처리 | Kafka/Flink 실시간 처리 |
| Micro-batch | 짧은 주기로 작은 batch 처리 | 5분마다 증분 적재 |
DBA 관점에서는 latency만 보지 말고 복구 난이도를 봐야 한다. Streaming은 freshness가 좋지만 checkpoint, exactly-once, replay, backpressure를 이해해야 한다.
좋은 Pipeline의 조건
- 실패해도 재실행 가능하다.
- 중복 실행해도 결과가 망가지지 않는다.
- source부터 target까지 lineage가 남는다.
- 입력 row 수와 출력 row 수가 관측된다.
- schema drift가 감지된다.
- SLA가 문서화되어 있다.
- alert가 원인 파악에 필요한 정보를 포함한다.
세션 과제
운영 중인 pipeline 하나를 골라 다음을 적어보자.
| 항목 | 답 |
|---|---|
| 수집 방식 | ETL / ELT / CDC / manual |
| 실행 방식 | batch / streaming / micro-batch |
| orchestrator | |
| checkpoint 위치 | |
| 재처리 방법 | |
| 중복 방지 기준 | |
| schema 변경 대응 |
References
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html
- https://debezium.io/documentation/reference/stable/index.html
- https://www.ibm.com/think/topics/etl
- https://www.ibm.com/think/topics/elt
- https://www.confluent.io/learn/change-data-capture/