Data Quality Monitoring
3줄 요약
Data Quality Monitoring 챕터는 데이터가 최신인지, 빠지지 않았는지, 값이 맞는지, 형식과 관계가 유효한지 자동 rule로 검증하는 방법을 다룬다.- 핵심은 pipeline task success와 data quality success를 분리하고, freshness, completeness, accuracy, validity, consistency 문제를 서로 다른 대응으로 연결하는 것이다.
- Java/Spring 백엔드 개발자는 운영 DB 이벤트와 mart 숫자가 어긋날 때 검증 SQL, 알림 등급, 재처리 range, 회고 rule을 설명할 수 있어야 한다.
핵심 정리
Data Quality Dimension: quality dimension은 이상을 분류하는 공통 언어다. freshness, completeness, accuracy, validity, consistency를 구분해야 대응이 빨라진다.Freshness Completeness Accuracy: freshness는 최신성, completeness는 누락, accuracy는 값의 정확성이다. 모두 “데이터가 이상하다”지만 원인과 복구가 다르다.데이터 검증 SQL과 Rule: rule은 pipeline 결과에 던지는 자동 질문이다. threshold, owner, severity, 실행 주기, 실패 시 조치를 가져야 한다.알림과 장애 등급: 품질 알림은 사용자 영향, 의사결정 영향, 복구 난이도, 우회 가능성으로 등급을 나눈다.데이터 품질 회고와 재발 방지: 회고는 누가 실수했는지가 아니라 어떤 rule, alert, runbook이 없어서 늦게 발견됐는지 찾는다.- 이 챕터는 Web-Database의 query 성능이 아니라 downstream 데이터가 믿고 사용 가능한 상태인지 검증하는 운영 문제를 다룬다.
헷갈리는 지점
- Airflow나 batch가 success이면 데이터도 맞다고 착각하기 쉽다.
- task success는 코드가 끝났다는 뜻이고, count와 sum이 맞다는 뜻이 아니다.
- quality rule은 pipeline 성공 이후 별도로 실행되어야 한다.
- freshness만 보면 품질을 충분히 본다고 오해하기 쉽다.
- 최신이어도 일부 row가 빠질 수 있고, row 수가 맞아도 금액이 틀릴 수 있다.
- freshness, completeness, accuracy는 최소한 함께 봐야 한다.
- 품질 알림을 모두 같은 장애로 취급하면 대응이 흐려진다.
- 내부 실험 mart 지연과 경영 매출 대시보드 오류는 심각도가 다르다.
- severity와 owner가 있어야 알림이 행동으로 이어진다.
확인 질문
- 이 챕터의 핵심 판단 기준은 무엇인가?
- 어떤 데이터가 어느 freshness/completeness/accuracy 기준을 만족해야 사용 가능하며, 실패 시 누가 어떤 range를 재처리하는지다.
- Web-Database와의 경계는 무엇인가?
- Web-Database는 DB query와 transaction을 다루고, 이 챕터는 pipeline 결과의 신뢰성과 품질 이상 대응을 다룬다.
- 개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- 최신 시각 rule, source-target count/sum rule, null/range rule, rule 실행 로그, 실패 알림 또는 실패 상태 table이다.