Backfill, rerun, time-travel read

Backfill 은 미래의 본인이 설계 감사할 거

3주간 metric silent 하게 corrupt 한 버그 발견하는 날, 두 옵션: 코드 forward 로 fix, 또는 코드 fix 그리고 지난 3주에 대해 corrected 파이프라인 다시 돌리기. 두 번째가 backfill, 그리고 파이프라인이 그 위해 설계됐을 때만 작동.

파이프라인을 backfillable 로 만드는 것

Window 로 parameterize. 파이프라인이 logical date / window 를 입력으로 받음 — NOW() 아니라.
Idempotent write. Window 다시 돌리면 replace, append 아니라.
숨은 state 없음. 명시적으로 override 가능한 watermark 없이 "마지막 run 이후 새 row 만" 안 함.
Source 데이터 reachable. Upstream API 또는 warehouse 가 historical window 서빙 가능 — 버그 후 아니라 이전 에 확인.

Time-travel read

Modern lakehouse 포맷 (Iceberg, Delta Lake) 이 time-travel read 지원 — "2026-04-01 시점 그대로 이 테이블 줘." Backfill 과 별도 아이디어 — backfill 은 이력 다시 쓰는 거, time-travel 은 과거 그대로 읽는 거. 둘이 함께 "버그 2주 전에 fix 됐다면 어제 리포트가 뭐 보여줬을까?" 답 가능 — stakeholder 한테 변경 설명 시 무가.

Code

Rate limit + idempotency 존중하는 backfill loop·python

from datetime import date, timedelta
import time
import logging

log = logging.getLogger('backfill')

def backfill(start: date, end: date, *, sleep_seconds: float = 1.0) -> None:
    '''[start, end) 의 각 날짜에 대해 파이프라인 다시 실행, 오래된 거 먼저.
    각 날짜가 partition; load 가 partition-replace 라 다시 돌려도 안전.
    '''
    cur = start
    while cur < end:
        log.info('backfill day=%s', cur)
        run_pipeline(window=cur.isoformat())   # production 과 같은 진입점
        cur += timedelta(days=1)
        time.sleep(sleep_seconds)              # upstream 한테 친절

# 예: 방금 버그 fix 해서 지난 21일 다시 처리
backfill(date(2026, 4, 9), date(2026, 4, 30))

Exercise

본인 소유 (또는 가상) 스케줄 파이프라인 골라. Backfillability audit: (1) window 파라미터 받나, (2) load 가 idempotent 인가, (3) upstream source 가 historical 인가, (4) 재현 어려운 "현재 state" 에 의존하나? 0–4 점수. 4 미만은 나중에 와서 받을 future-tax.