백필(Backfill) 및 리플레이(Replay) 설계은(는) 무엇을 하나요?
사용 시기
- 새 모델/파이프라인을 위한 이력 로드.
- 변환 버그 수정 후 과거 윈도우 재처리.
- 이벤트 리플레이 또는 원시 데이터로부터 테이블 재도출.
- 일반 증분 실행에는 사용하지 마십시오(
building-dbt-models/authoring-airflow-dags참조).
왜 신중해야 하는가
백필은 데이터 엔지니어링에서 가장 위험한 일상 작업입니다: 이력을 덮어씁니다. 잘못 수행하면 이중 집계, 어제의 숫자 변경, 또는 프로덕션 과부하가 발생합니다. 올바르게 수행하면 지루하고 반복 가능합니다. 전제 조건은 멱등성입니다(writing-idempotent-transformations 참조).
워크플로
- [ ] 백필 **전에** 변환이 멱등인지 확인(재실행 == 한 번 실행)
- [ ] 정확한 윈도우와 파티션 세분성 정의
- [ ] 하나의 파티션을 드라이런하고 소스와 비교하여 카운트/합계 검증
- [ ] 한 번에 모두 처리하지 말고 파티션 단위로 실행(제한된 병렬성)
- [ ] 백필 컴퓨팅을 프로덕션 워크로드와 격리
- [ ] 총계 검증 및 조정 후 정규 스케줄 재개
- 먼저 멱등성을 증명하십시오. 윈도우를 재실행했을 때 결과가 변경될 수 있다면, 이력을 건드리기 전에 먼저 수정하십시오. 비멱등 작업을 백필하면 데이터가 배가됩니다.
- 범위를 정확히 설정하십시오. 정확한 시작/종료일과 파티션 단위(일/시간/지역).
- 하나의 파티션을 드라이런하고 소스와 조정한 후 확장하십시오.
- 청크 단위로 실행하십시오. 파티션을 제한된 배치로 처리하여 모니터링, 일시 중지, 재개가 가능하도록 하십시오 — 절대 단일 대규모 unbounded 작업을 하지 마십시오.
- 컴퓨팅을 격리하십시오. 별도의 웨어하우스/클러스터/풀을 사용하여 백필이 프로덕션 SLA를 굶주리지 않도록 하십시오.
- 검증 + 재개. 백필 범위에 대한 총계를 조정한 후 정규 스케줄로 돌아가십시오.
패턴
멱등 파티션별 백필 — 각 파티션 덮어쓰기는 독립적이며 재시도해도 안전합니다:
# 제한된 병렬성, 하루에 하나씩; 각 날짜는 자체 파티션을 덮어씁니다.
for day in $(seq_dates 2026-01-01 2026-01-31); do
run_transform --run-date "$day" # delete-insert / MERGE for that day only
done
Airflow — catchup/backfill은 간격을 재실행합니다. 작업이 멱등이고 데이터 간격으로 매개변수화된 경우에만 안전합니다. dbt — 증분 모델을 대상 윈도우로 필터링하거나 제한된 윈도우에 대해 --full-refresh를 사용합니다.
격리 + 제한 — 전용 웨어하우스/클러스터와 동시성 제한으로 백필이 실시간 대시보드를 저하시킬 수 없도록 합니다.
일반적인 함정
- 비멱등 작업의 백필 — 중복 또는 변동하는 총계; 먼저 멱등하게 만드십시오.
- 단일 대규모 unbounded 실행 — 모니터링 및 재개가 불가능하고 프로덕션에 과부하를 줍니다; 파티션별로 진행하십시오.
- 프로덕션 컴퓨팅 공유 — 백필이 부하를 급증시키고 SLA를 파괴합니다; 격리하십시오.
- 검증 없음 — 성공을 가정하지 마십시오; 범위에 대한 카운트/합계를 조정하십시오.
- 백필 중간에 로직 변경 — 일관되지 않은 이력; 전체 실행 동안 코드 버전을 고정하십시오.
- 다운스트림 간과 — 기본 테이블을 백필하면서 의존하는 마트/집계를 새로고침하지 않으면 불일치가 발생합니다.