반응형

데이터 파이프라인을 오래 운영하다 보면 모든 필드를 매일 새로 받는 방식이 점점 부담이 된다. 가격처럼 매일 바뀌는 값도 있지만, 회사 주소나 산업 분류처럼 자주 바뀌지 않는 값도 있다. 갱신 주기를 필드별로 나누면 비용과 장애 범위를 줄일 수 있다.

데이터 업데이트 스케줄 설계: 필드별 갱신 주기 관리 핵심 흐름과 판단식 도식
데이터 업데이트 스케줄 설계: 필드별 갱신 주기 관리 핵심 구조도

필드별 갱신 주기 예시

필드군 권장 주기 근거
가격, 거래량 매 거래일 분석 결과에 즉시 영향
재무제표 공시 발생 시 제출 이벤트 기반
기업 기본 정보 주 1회 또는 이벤트 기반 변경 빈도 낮음
분류, 매핑 변경 감지 시 한 번 틀리면 영향 큼

우선순위 점수로 배치 순서를 정한다

priority = impact_score * freshness_gap_days * dependency_count

if priority >= 80:
    run_now()
elif priority >= 30:
    run_today()
else:
    wait_next_window()

경보는 값이 아니라 지연에 걸어둔다

값이 변하지 않는 것은 정상일 수 있다. 대신 마지막 성공 시각과 기대 갱신 시각의 차이를 보고 freshness 경보를 건다.

운영 체크

  • 필드별 last_success_at을 저장한다.
  • 하위 배치가 실패하면 상위 집계가 오래된 값을 쓰지 않도록 막는다.
  • 재처리 작업은 일반 갱신 작업과 큐를 분리한다.

실전 적용 포인트

데이터 갱신 주기는 모든 테이블에 같은 규칙을 적용하면 금방 비효율이 생긴다. 가격처럼 매일 바뀌는 데이터와 기업 주소처럼 천천히 바뀌는 데이터는 실패했을 때의 영향도와 복구 비용이 다르다.

우선순위 점수는 운영자가 배치를 설명할 수 있게 만들어준다. 영향도, 지연 일수, 의존 배치 수를 곱해보면 오늘 당장 돌릴 작업과 다음 창구까지 기다려도 되는 작업을 분리하기 쉽다.

  • 필드별 마지막 성공 시각을 저장한다.
  • 하위 배치 실패가 상위 집계에 번지지 않게 막는다.
  • 갱신 지연 경보에는 영향 받는 지표를 함께 적는다.

함께 보면 좋은 글

반응형

+ Recent posts