Day 2 - 데이터 품질·검증: Glue Data Quality와 검증 게이트

데이터 품질의 여섯 차원

"쓰레기를 넣으면 쓰레기가 나온다(Garbage In, Garbage Out)." 파이프라인이 아무리 안정적이어도 들어오는 데이터가 틀렸다면 결과는 믿을 수 없다. 오늘은 품질을 측정·강제하고, 불량 데이터를 걸러 재처리하는 방법을 본다.

• 정확성은 규칙 하나로 끝나지 않는다. 믿을 수 있는 기준 데이터와 합계·건수를 맞춰 보는 방식으로만 근사할 수 있다.

💡 관련 이론: 품질 검증은 가능한 한 파이프라인의 앞쪽(수집 직후) 에 둔다. 불량 데이터가 curated 존까지 흘러간 뒤 발견하면 영향 범위와 재처리 비용이 급격히 커진다(shift-left).

Glue Data Quality 의 두 진입점

Glue Data Quality 는 오픈소스 Deequ 위에 만든 서버리스 기능이다. 같은 DQDL 을 쓰지만 실행 위치가 두 곳이고, 되는 일이 다르다.

• "불량 레코드만 골라 격리하고 나머지는 적재"는 ETL 쪽이어야 한다. "기존 테이블에 어떤 규칙을 걸지 모르겠다"는 Data Catalog 쪽의 규칙 추천으로 초안을 받는다.
• 중첩 구조나 리스트 타입 컬럼은 규칙으로 평가하지 못한다. 먼저 펼친(flatten) 뒤 평가한다.

DQDL 문법 깊이 보기

DQDL 문서는 대소문자를 구분하고, Rules 라는 이름의 목록 안에 규칙을 쉼표로 나열한다.

Rules = [
    RowCount > 1000,
    IsComplete "order_id",
    IsUnique "order_id",
    ColumnValues "status" in ["NEW", "PAID", "SHIPPED", "CANCELLED"],
    ColumnValues "amount" between 0 and 1000000,
    Completeness "customer_email" > 0.95,
    ColumnDataType "created_at" = "TIMESTAMP",
    DataFreshness "created_at" <= 24 hours,
    ReferentialIntegrity "customer_id" "customers.customer_id" >= 0.99,
    (IsComplete "coupon_code") or (ColumnValues "discount" = 0),
    ColumnValues "country" in ["KR", "JP", "US"] with threshold > 0.98
]

• 복합 규칙은 기본적으로 각 규칙을 테이블 전체에 대해 따로 평가한 뒤 결과를 결합한다. "행마다 A 이거나 B 이면 통과"라는 SQL 식 의미를 원하면 평가 방식을 행 단위(compositeRuleEvaluation.method = ROW)로 바꿔야 한다. 이것을 모르면 OR 규칙이 예상과 달리 실패한다.
• 동적 규칙은 임계값 자리에 과거 실행 결과를 넣는다. last(k) 가 직전 k 회의 값을 가리키고, k 가 2 이상이면 avg·min·max 같은 집계로 한 숫자로 줄여야 한다.
• Analyzers 블록은 조건 없이 통계만 수집한다. 아직 규칙을 쓸 만큼 데이터를 모를 때 통계부터 쌓아 두고, 그 통계를 이상 탐지가 쓴다.

Rules = [
    RowCount >= min(last(7)),           # 최근 7회 중 가장 적었던 날보다 줄면 실패
    DetectAnomalies "RowCount"           # 과거 추세에서 벗어나면 실패
]
Analyzers = [
    DistinctValuesCount "customer_id",
    Completeness "customer_email"
]

점수는 어떻게 계산되나

• 품질 점수 = 통과한 규칙 수 ÷ 전체 규칙 수. 불량 행의 비율이 아니다. 규칙 10개 중 1개가 실패하면 그 규칙이 행 한 건 때문에 실패했더라도 점수는 0.9 다.
• 그래서 게이트 기준을 점수 하나로만 잡으면 위험하다. "절대 깨지면 안 되는 규칙"(PK 중복, 필수 컬럼 누락)은 점수와 별개로 실패 즉시 중단시키고, 나머지를 점수로 본다.
• 이상 탐지가 만든 관찰(observation)은 점수에 반영되지 않는다. 점수는 규칙만으로 정해진다.

통계 기반 이상 탐지

고정 임계값(RowCount > 1000)은 데이터 양이 요일·계절에 따라 변하면 오탐을 내거나, 사업이 커진 뒤에는 아무것도 못 잡는다. 하루 100만 건 기준으로 만든 규칙은 평소 200만 건이 들어오게 된 뒤 25% 가 빠져도 통과한다.

• 규칙과 Analyzer 가 실행될 때마다 통계가 Glue 서비스 안에 쌓이고, 이상 탐지는 이 통계의 추세를 학습해 예상 범위(상한·하한)를 만든다. 실제 값이 범위를 벗어나면 관찰을 생성한다.
• 탐지에는 최소 세 개의 데이터 포인트가 필요하다. 처음 몇 번의 실행에서는 아무것도 나오지 않는다.
• 한 번 이상으로 잡힌 값은 따로 제외하지 않으면 다음 실행부터 정상값으로 학습에 들어간다. 장애로 생긴 값을 그대로 두면 같은 장애를 다시 못 잡는다. 통계 제외로 모델에 피드백을 준다.
• 탐지 모드는 둘이다. 추세·계절성을 따라가는 기본 모드(Linear)와, 시간 간격을 무시하고 기준선만 보는 모드(Fixed)다. 실행 간격이 불규칙하면 후자가 맞다.
• 과금은 탐지에 걸린 시간만큼이며 통계 하나마다 DPU 가 잡힌다. 통계 저장 자체는 무료다.

💡 관련 이론: 이상 탐지는 "절대값이 틀렸다"가 아니라 "평소와 다르다"를 잡는다. CloudWatch Anomaly Detection 도 같은 발상으로 지표의 정상 범위를 학습한다. 차이는 대상이다. CloudWatch 는 운영 지표를, Glue Data Quality 는 데이터 자체의 통계를 본다.

ETL 잡 안에서 평가하고 행을 가르기

from awsgluedq.transforms import EvaluateDataQuality
from awsglue.transforms import SelectFromCollection
 
result = EvaluateDataQuality().process_rows(
    frame=orders_dyf,
    ruleset=ruleset,
    publishing_options={
        "dataQualityEvaluationContext": "orders_ingest",
        "enableDataQualityCloudWatchMetrics": True,
        "enableDataQualityResultsPublishing": True,
    },
)
 
# 규칙별 결과(통과/실패, 실패 사유)
rule_outcomes = SelectFromCollection.apply(dfc=result, key="ruleOutcomes")
 
# 행별 결과: 원본 컬럼 + 판정 컬럼 4개
rows = SelectFromCollection.apply(dfc=result, key="rowLevelOutcomes").toDF()
valid = rows.filter(rows.DataQualityEvaluationResult == "Passed")
invalid = rows.filter(rows.DataQualityEvaluationResult == "Failed")
 
valid.write.mode("append").parquet("s3://lake-clean/orders/")
invalid.write.mode("append").json("s3://lake-quarantine/orders/dt=2026-06-26/")

• 행 단위 결과에는 DataQualityRulesPass, DataQualityRulesFail, DataQualityRulesSkip, DataQualityEvaluationResult 네 컬럼이 붙는다. 어떤 규칙 때문에 떨어졌는지가 행에 남으므로 격리 영역에 실패 사유와 함께 저장할 수 있다.
• 컬럼 존재 여부(ColumnExists)처럼 행 하나로는 판정할 수 없는 규칙은 행 단위 결과에서 건너뛴 규칙(DataQualityRulesSkip)으로 표시된다.

검증 게이트와 통보

검증 게이트는 품질이 기준 미달이면 다운스트림 진행을 막는 제어 지점이다.

[Glue 잡: 수집 + DQ 평가] → Choice 상태
   ├─ 치명 규칙 통과 그리고 점수 >= 0.95 → [curated 적재]
   └─ 그 외 → [격리(quarantine)] → [SNS 통보] → [실패로 종료]

• 평가가 끝나면 EventBridge 로 이벤트가 나간다. 실패한 평가만 받아 SNS·Lambda 로 넘기는 규칙을 만든다. CloudWatch 에는 통과·실패 규칙 수가 지표(glue.data.quality.rules.passed / failed)로 올라온다.
• EventBridge 발행은 "지표를 CloudWatch 로 게시" 옵션이 켜져 있어야 동작한다. 지표 게시를 끄면 이벤트도 끊긴다.

{
  "source": ["aws.glue-dataquality"],
  "detail-type": ["Data Quality Evaluation Results Available"],
  "detail": { "state": ["FAILED"] }
}

• 게이트를 통과하지 못한 데이터는 버리거나 덮어쓰지 않고 격리 영역으로 보낸다. 임계값을 낮춰 통과시키는 것은 게이트를 없애는 것과 같다.

격리와 재처리 설계

• 재처리 경로는 정상 경로와 같은 검증을 다시 통과해야 한다. 격리 데이터를 손으로 고쳐 curated 에 직접 넣는 지름길은 게이트를 우회한다.
• append 방식 적재는 재처리 때 중복을 만든다. 재처리를 염두에 둔 테이블은 처음부터 덮어쓰기나 MERGE 로 설계한다.

닮은 도구 구분

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 파이프라인이 실패했을 때 무슨 일이 있었는지 재구성하는 방법, CloudTrail 감사와 재시도·DLQ 를 다룬다.

📖 용어

• DQDL : Glue Data Quality 의 규칙을 쓰는 선언형 언어. 무엇을 만족해야 하는지만 적는다.
• 룰셋(ruleset) : 품질 규칙의 묶음. 평가하면 규칙별 결과와 점수가 나온다.
• 품질 점수 : 룰셋에서 통과한 규칙의 비율. 불량 행의 비율이 아니다.
• Analyzer : 통과·실패 판정 없이 통계만 수집하는 DQDL 구문.
• 동적 규칙 : 임계값을 고정하지 않고 지난 실행들의 값(last(k))과 비교하는 규칙.
• 이상 탐지 : 쌓인 통계의 추세를 학습해 평소와 다른 값을 찾아내는 기능.
• 검증 게이트 : 품질이 기준에 못 미치면 다음 단계로 못 넘어가게 막는 지점.
• 격리(quarantine) : 불량 데이터를 지우지 않고 따로 모아 두는 영역.
• 멱등성 : 같은 작업을 여러 번 해도 결과가 한 번 한 것과 같은 성질.
• shift-left : 검증을 파이프라인의 앞단으로 당겨 오염이 퍼지기 전에 막는 원칙.