Backfill, rerun, time-travel read

Backfill 하는 날, 설계 실력이 청구서로 날아와

어떤 버그가 3주 동안 metric 을 조용히 오염시켰다는 걸 발견하는 날, 선택지는 둘이야: 코드만 고치고 앞으로만 가거나, 코드를 고치고 지난 3주까지 고쳐진 파이프라인으로 다시 돌리거나. 두 번째가 backfill 이고 — 파이프라인이 애초에 그걸 위해 설계돼 있을 때만 가능해.

Backfill 되는 파이프라인의 조건

Window 로 파라미터를 받아. 파이프라인이 logical date / window 를 입력으로 받아 — NOW() 를 박아 넣는 게 아니라.
Write 가 idempotent 해. Window 를 다시 돌리면 append 가 아니라 replace 가 일어나.
숨은 state 가 없어. 명시적으로 덮어쓸 수 없는 watermark 에 기대는 "마지막 run 이후 새 row 만" 은 안 돼.
Source 가 과거를 내줄 수 있어. Upstream API 나 warehouse 가 historical window 를 서빙할 수 있는지 — 버그 나고 확인하지 말고 미리 확인해.

Time-travel read

Modern lakehouse 포맷 (Iceberg, Delta Lake) 은 time-travel read 를 지원해 — "이 테이블, 2026-04-01 에 있던 그대로 줘." Backfill 과는 별개 아이디어야 — backfill 은 역사를 다시 쓰는 거고, time-travel 은 과거를 그때 모습 그대로 읽는 거야. 둘을 합치면 "이 버그를 2주 전에 고쳤다면 어제 리포트엔 뭐가 찍혔을까?" 에 답할 수 있어 — 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

본인이 가진 (또는 상상 속의) 스케줄 파이프라인 하나로 backfill 가능성 감사를 해 봐: (1) window 파라미터를 받나, (2) load 가 idempotent 한가, (3) upstream source 가 과거를 내주나, (4) 재현 못 할 "현재 state" 에 기대고 있나? 0–4 점. 4점 미만은 빚이야 — 나중에 이자까지 붙여서 갚게 돼.

Backfill 하는 날, 설계 실력이 청구서로 날아와

Backfill 되는 파이프라인의 조건

Time-travel read

Code

External links

Exercise

Progress

댓글 0