ETL ELT Data Pipeline

ETL ELT Data Pipeline 챕터는 추출, 변환, 적재 단계를 나누고 의존성, 체크포인트, 스키마 변경, 장애 복구가 가능한 파이프라인을 설계한다.
목표는 ETL/ELT 용어를 외우는 것이 아니라, 원천 데이터를 어디에 보존하고 어느 단계부터 다시 계산할 수 있는지 판단하는 것이다.
Java/Spring 백엔드 개발자는 운영 DB 변경이 extract, raw, transform, warehouse, mart, quality rule에 어떤 영향을 주는지 설명할 수 있어야 한다.

ETL과 ELT 차이: ETL은 적재 전에 변환하고 ELT는 raw를 먼저 적재한 뒤 저장소 안에서 변환한다. 선택은 원천 보존과 계산 위치의 문제다.
Extract Transform Load 단계: extract, transform, load는 각각 실패 지점과 검증 기준이 다르다. 한 함수로 묶으면 재처리 범위가 커진다.
Pipeline Dependency와 Checkpoint: pipeline은 task 순서와 마지막 성공 위치를 알아야 재실행할 수 있다. checkpoint 없는 pipeline은 운영자가 기억에 의존한다.
Schema Change와 Pipeline 영향: 운영 DB 컬럼 변경은 pipeline parser, warehouse table, mart, dashboard까지 깨뜨릴 수 있다.
Pipeline 장애 대응: pipeline 장애는 API 장애와 다르게 늦게 발견될 수 있다. freshness와 completeness 알림이 없으면 사용자나 분석가가 먼저 발견한다.
이 챕터의 모든 문서는 Web-Database의 OLTP 판단을 넘어, 데이터 이동과 재처리 가능성을 중심으로 읽어야 한다.

ETL과 ELT를 도구 이름 차이로만 보기 쉽다.
- 핵심 차이는 변환을 적재 전에 할지, raw를 먼저 보존한 뒤 저장소 안에서 할지다.
- raw가 없으면 transform 버그를 고친 뒤 과거 데이터를 다시 계산하기 어렵다.
pipeline task 성공을 데이터 성공으로 보기 쉽다.
- task가 끝나도 row count, freshness, 합계 검증이 실패할 수 있다.
- checkpoint는 처리 완료와 품질 검증 완료를 구분해 갱신해야 한다.
운영 DB schema 변경을 백엔드 내부 변경으로만 보기 쉽다.
- 컬럼 rename, type 변경, null 허용 변경은 extract parser, warehouse table, mart, dashboard를 함께 깨뜨릴 수 있다.
- schema 변경은 pipeline owner와 영향 목록을 공유해야 한다.

이 챕터의 핵심 판단 기준은 무엇인가?
- 원천 raw 보존 여부, task별 입력과 출력, checkpoint 갱신 시점, schema 변경 영향, 품질 검증 기준이다.
Web-Database와의 경계는 무엇인가?
- Web-Database는 운영 DB 자체의 query와 schema 중심이고, 이 챕터는 그 데이터를 추출해 변환·적재·검증하는 이동 경로 중심이다.
개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- source range, raw 또는 staging 보관, target table, checkpoint table, count/freshness 검증 SQL이다.

동블