동블

그래프 뷰

02. Freshness Completeness Accuracy 상세

6 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • freshness, completeness, accuracy는 같은 품질 문제가 아니라 어떻게 다른가?
  • 최신성은 맞지만 누락되거나, 누락은 없지만 값이 틀리는 상황을 어떻게 구분하는가?
  • 각 차원별 SQL rule과 alert 기준은 어떻게 잡아야 하는가?
  • Java/Spring 백엔드 변경이 세 품질 차원에 어떤 영향을 줄 수 있는가?

개요

freshness는 최신성이다.

completeness는 누락 여부다.

accuracy는 값의 정확성이다.

세 차원은 모두 “데이터가 이상하다”로 보이지만 원인과 복구가 다르다.

freshness 문제를 backfill로 풀려고 하면 필요 없는 재처리를 할 수 있다.

accuracy 문제를 freshness 지표만 보고 놓치면 잘못된 숫자가 빠르게 제공된다.

Freshness

freshness는 마지막 데이터 시각을 본다.

SELECT now() - max(event_time) AS freshness_lag
FROM mart_order_events;

기준은 데이터 사용 목적에 따라 다르다.

실시간 모니터링은 몇 분, daily report는 몇 시간까지 허용할 수 있다.

freshness 실패 원인은 scheduler 지연, consumer lag, source event 중단, Airflow queue 지연일 수 있다.

복구는 pipeline 재시작이나 lag 해소가 중심이다.

Completeness

completeness는 있어야 할 데이터가 모두 있는지 본다.

SELECT source.cnt - target.cnt AS missing_count
FROM (
  SELECT count(*) cnt FROM orders WHERE order_date = :dt
) source
CROSS JOIN (
  SELECT count(*) cnt FROM mart_order_daily WHERE order_date = :dt
) target;

source와 target grain이 같을 때 count 비교가 유효하다.

mart가 주문별이 아니라 일별 집계라면 count 비교 대신 group 수나 key coverage를 봐야 한다.

completeness 실패는 extract range 누락, join filter 오류, partition 누락에서 자주 생긴다.

복구는 빠진 range backfill이다.

Accuracy

accuracy는 값이 business 의미와 맞는지 본다.

SELECT source.amount_sum - target.amount_sum AS amount_diff
FROM (
  SELECT sum(paid_amount) amount_sum FROM orders WHERE order_date = :dt
) source
CROSS JOIN (
  SELECT sum(paid_amount) amount_sum FROM mart_order_daily WHERE order_date = :dt
) target;

count가 맞아도 금액이 틀릴 수 있다.

환불 반영, timezone, currency, tax 포함 여부 같은 business rule이 accuracy를 흔든다.

복구는 transform logic 수정 후 재처리다.

세 차원의 조합

세 차원은 조합될 수 있다.

FreshnessCompletenessAccuracy해석
실패미확인미확인pipeline 지연 가능성
성공실패미확인최신이지만 일부 누락
성공성공실패row 수는 맞지만 계산 오류
실패실패실패source 또는 pipeline 큰 장애

처음부터 모든 원인을 단정하지 말고 차원별로 좁힌다.

백엔드 변경 영향

백엔드 schema 변경은 completeness와 accuracy에 영향을 줄 수 있다.

새 status가 추가됐는데 pipeline filter가 모르면 일부 row가 빠진다.

금액 column 의미가 바뀌면 accuracy rule이 실패한다.

event 발행이 멈추면 freshness가 실패한다.

따라서 백엔드 PR에는 downstream 품질 rule 영향이 포함되어야 한다.

Alert 기준

alert는 차원별로 다르게 잡는다.

freshness_lag > 30m -> warning
freshness_lag > 2h -> critical
completeness_ratio < 0.99 -> critical
amount_diff_abs > 10000 -> critical

threshold는 business 영향 기준으로 정한다.

모든 rule 실패가 critical이면 알림 피로가 생긴다.

운영 지표

  • freshness lag by dataset
  • expected vs actual count
  • missing key count
  • amount difference
  • accuracy mismatch count
  • rule failure duration

duration도 중요하다.

1분 freshness 지연과 2시간 지연은 같은 실패가 아니다.

개인 프로젝트 기준

개인 프로젝트에서는 daily order mart를 기준으로 세 rule을 만든다.

최신 event time이 기준 안에 있는지 본다.

source와 target count를 비교한다.

source와 target amount sum을 비교한다.

각 rule 결과를 quality_rule_runs table에 남긴다.

위험 신호!

  • freshness rule만 있다.
  • count가 맞으면 accuracy도 맞다고 본다.
  • source와 target grain을 문서화하지 않는다.
  • threshold가 business 영향과 연결되어 있지 않다.
  • 백엔드 schema 변경 시 quality rule을 갱신하지 않는다.

확인 질문

확인 질문

  • 현재 품질 이상은 최신성, 누락, 값 오류 중 무엇인가?
    • freshness, completeness, accuracy rule 결과로 답해야 한다.
  • count 비교가 의미 있으려면 source와 target grain이 같은가?
    • grain이 다르면 coverage나 aggregate 기준을 바꿔야 한다.
  • accuracy rule은 어떤 business rule 변경에 영향을 받는가?
    • 환불, 취소, timezone, tax 같은 rule을 확인해야 한다.

참고 문서

관련 문서