ETL 데이터 품질 검증과 이상치 탐지 설계

ETL의 신뢰성은 적재 전에 결정된다

데이터 품질은 분석·AI·운영 시스템의 정확성과 회복탄력성을 좌우한다. 정확성, 완전성, 일관성, 적시성, 유효성, 중복성 최소화라는 기준을 파이프라인 안에서 측정하고, 품질 목표는 SLO(SLI/Threshold)로 정량화해 자동 검증 게이트에 반영할 수 있다.

Data Validation Frameworks는 데이터의 스키마와 규칙(expectations/constraints)을 선언적으로 정의하고, 검증 결과와 리포트를 제공하는 도구 집합이다. Great Expectations(Python), Deequ(Scala/Spark), TFX/TFDV(TensorFlow Extended, Beam 기반)가 대표적이다.

규칙만으로는 미리 정의되지 않은 결함을 모두 포착하기 어렵다. Anomaly Detection in ETL은 데이터 분포, 트래픽, 메트릭에서 비정상적인 변화를 감지하는 통계·ML 절차다. 기준선(baseline)과 계절성(weekly seasonality)을 반영하며, 배치와 스트리밍 환경 모두에서 규칙 기반 검증을 보완한다.

적재 파이프라인에 품질 게이트를 넣는 방식

원천 로그·DB·이벤트를 추출할 때 스키마와 샘플 통계를 포함한 메타데이터를 수집한다. 이후 샘플링 또는 전수 검사를 선택해 타입·널·도메인을 확인하고, 키 유일성이나 합계 보존 같은 비즈니스 규칙을 적용한다. Z-score, ESD, Prophet 등의 방식으로 이상치도 판단한다.

검증 결과는 하드-페일과 소프트-워닝으로 나뉜다. 거래성 데이터에는 하드-페일을, 비핵심 지표에는 소프트-워닝을 적용할 수 있다. 실패한 데이터는 격리 테이블(quarantine)로 보내고, 성공한 데이터만 변환과 적재 MERGE 단계로 진행한다. 자동 재시도·리샘플과 표본 저장은 이후 RCA에 활용한다.

스테이징, 검증, 커밋을 분리한 2단계 로드와 MERGE(업서트), idempotency key는 반복 실행의 안정성을 높인다. 스냅샷 격리와 ACID 테이블(Delta/Iceberg/Hudi), 파티션 단위 커밋은 읽기·쓰기 경합을 줄이는 데 사용한다.

⤢✕

규칙, 프로파일, 관측성을 함께 운영한다

검증 레이어에서는 스키마 진화 정책(backward/forward compatibility)을 정하고, 필수 컬럼·타입·도메인 제약을 선언한다. 기대치 세트(expectation suite/constraints)와 체크포인트는 이를 파이프라인 게이트로 만든다.

이상치 판정에는 IQR, Z-score, MAD 같은 통계 임곗값과 Holt-Winters/Prophet 계열성 모델을 함께 둘 수 있다. 행 수 같은 볼륨, KS-test 기반 분포, 카테고리 카드inality를 다중 메트릭으로 조합하고 다수결 또는 가중 집계로 판단한다.

프로파일링 결과로는 컬럼별 null 비율, 분산, 상위 카테고리, 스케치(HyperLogLog)를 저장한다. 메타스토어에 남긴 스냅샷은 드리프트 추세와 RCA의 기반이 된다.

생산자와 소비자 사이에는 데이터 계약(Data Contract)으로 스키마와 품질 SLO를 명세한다. CI/CD에 검증 테스트를 넣고 실패하면 배포를 차단하며, 격리와 롤백 전략도 미리 정의한다. 라인리지(Lineage)와 이벤트 로그의 상관 분석은 오류 전파 범위를 파악하게 해주고, 적응형 임계치와 티켓·플레이북 연계는 경고 소음과 MTTR을 줄이는 데 쓰인다.

프레임워크별 운영 특성

프레임워크	성능	확장성	일관성	안정성	운영 편의
Great Expectations	중. Pandas/Spark 엔진 선택	중~상. Spark/DB 연결 지원	강. Expectation Suite와 Data Docs	상. 커뮤니티 성숙	높음. CLI/데이터 문서화, 온보딩 용이
Deequ	상. Spark 분산 제약 평가	상. 대규모 테이블 적합	중. JSON 메트릭 관리 필요	중~상. 프로덕션 사용 다수	중. Scala/Spark 지식 요구
TFDV	중. Beam/TFX 파이프라인	상. Beam 분산 실행	강. 스키마 Proto 기반	상. 구글 오픈소스	중. TFX 생태계 전제

최신 릴리스 및 호환성은 최신 정보 확인 필요.

Great Expectations로 선언한 주문 데이터 규칙

전제: Python 3.9+, great-expectations>=0.18, pandas>=2.0

# pip install great-expectations pandas
import pandas as pd
import great_expectations as gx

df = pd.DataFrame({
    "order_id": [1, 2, 3],
    "amount": [29.9, 49.0, 0.0],
    "country": ["KR", "US", "KR"]
})

context = gx.get_context(mode="ephemeral")
ds = context.sources.pandas_default.read_dataframe(df)

suite = context.suites.add("orders_suite")
suite.add_expectation("expect_column_values_to_not_be_null", {"column": "order_id"})
suite.add_expectation("expect_column_values_to_be_between", {"column": "amount", "min_value": 0.01})
suite.add_expectation("expect_column_values_to_be_in_set", {"column": "country", "value_set": ["KR","US","JP"]})

checkpoint = context.checkpoints.add(
    name="orders_checkpoint",
    validations=[{"batch": ds, "suite": suite}]
)

result = checkpoint.run()
assert result["success"], "품질 검증 실패: 격리/알림 수행 필요"

Spark 환경에서 Deequ 제약을 평가하는 코드

전제: Spark 3.5+, deequ 2.x, Scala 2.12

// libraryDependencies += "com.amazon.deequ" %% "deequ" % "2.0.6-spark-3.5"
import org.apache.spark.sql.SparkSession
import com.amazon.deequ.VerificationSuite
import com.amazon.deequ.checks.{Check, CheckLevel}

val spark = SparkSession.builder().appName("deequ-demo").getOrCreate()
import spark.implicits._

val df = Seq(
  (1, 29.9, "KR"),
  (2, 49.0, "US"),
  (3,  0.0, "KR")
).toDF("order_id", "amount", "country")

val check = Check(CheckLevel.Error, "basic-constraints")
  .isComplete("order_id")
  .isNonNegative("amount")
  .isContainedIn("country", Array("KR","US","JP"))

val result = VerificationSuite()
  .onData(df)
  .addChecks(Seq(check))
  .run()

if (result.status != com.amazon.deequ.analyzers.runners.Status.Success) {
  sys.error("품질 검증 실패: 페일오버/격리 수행")
}

참고: Deequ의 이상치 탐지는 AnalyzerRunner로 시계열 메트릭을 로깅한 뒤 AnomalyDetectionRunner 적용. 프로덕션에서는 메트릭 저장소(S3/DB)와 주기적 베이스라인 갱신 권장.

데이터 성격에 따라 달라지는 검증 대상

전자상거래 주문 파이프라인에서는 주문 금액>0, 통화 코드 ISO-4217, 주문-결제 조인 완전성을 규칙으로 둘 수 있다. 일일 주문량의 급락·급증이나 특정 카테고리의 결측 급증은 이상치로 감시하며, 결제 매출 누락 조기 탐지와 재처리 자동화로 이어진다.

금융 거래 모니터링은 계좌ID 유효성, 중복 거래 식별, 영업일 캘린더 준수를 확인한다. 시간대별 거래량 분포 이탈과 지역별 평균 티켓 크기의 급변은 이상치 신호가 되며, 사기 탐지 신호 강화와 규제 보고 품질 향상에 활용된다.

머신러닝 피처 스토어에서는 피처 도메인·스케일 고정과 스파스 피처 결측 상한을 검증한다. 피처 분포 드리프트와 레이블 지연 스큐를 감시하면 모델 성능 저하 사전 경보와 재학습 트리거 자동화에 연결할 수 있다.

품질 정책에서 선택해야 할 균형

정확성이 우선인 업무는 하드-페일을, 데이터 가용성이 더 중요한 업무는 소프트-워닝을 선택한다. 대규모 테이블은 스케치·샘플 검사와 중요 컬럼 전수 검사를 병행할 수 있다. 생산자 단계에서는 스키마 계약을 강제하고, 소비자 단계에서는 비즈니스 규칙을 보강한다.

스트리밍은 지연 최소화와 근사 통계에, 배치는 정밀 통계와 완전 검증에 맞는다. 혼합형 설계를 권장한다. 스키마 진화에서는 backward 호환을 우선하고 필수 컬럼 추가에는 grace 기간을 둔다. 로그와 샘플 데이터에는 PII 마스킹, 만료 정책, 접근통제를 적용한다.

데이터 결함 유입률은 50~~80% 감소하고 SLA 위반은 30~~40% 감소할 수 있다. 재처리 비용은 20~35% 절감되며 MTTR은 40% 이상 단축될 수 있다. 분석·ML 지표의 변동성을 낮추고 신뢰도와 감사(감사추적) 용이성을 높이는 효과도 기대된다. 수치는 업종/규모별 참고치다.

규칙 기반 검증, 이상치 탐지, 스테이징-검증-커밋, 메타데이터 프로파일링, 관측성 대시보드, 알림과 플레이북은 분리된 기능이 아니라 하나의 품질 운영 체계로 다뤄야 한다. 초기에는 GE/Deequ로 시작하고, 규모가 커지면 메트릭 저장소, 자동 베이스라인, 라인리지 연계로 성숙도를 높일 수 있다.