Amazon DEA-C01: 데이터 품질, 검증 및 옵저버빌리티 — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

다음의 일부입니다: Amazon Data Engineer Associate DEA-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

이 도메인은 데이터 정확성을 보장하고, 이상을 탐지하며, 파이프라인의 신뢰성을 유지하는 데 사용되는 엔드투엔드 방식과 AWS 서비스를 다룹니다. 강력한 검증 및 관찰 가능성은 다운스트림 결함을 줄이고 SLA를 충족하며 안전한 재처리를 가능하게 합니다. 데이터 엔지니어는 Glue Data Quality, 검증 프레임워크, CloudWatch 이상 탐지, DLQ, 멱등성 설계를 결합하여 견고한 파이프라인을 구축해야 합니다.

AWS Glue Data Quality 규칙 및 평가

Glue Data Quality는 데이터 품질 정의 언어(DQDL) 규칙 세트를 사용하여 데이터 세트에 대한 어설션(행 수, null 임계값, 고유성, 사용자 지정 SQL 검사)을 정의합니다. 규칙 세트는 콘솔이나 CLI(예시 패턴:

undefined

)를 통해 생성할 수 있습니다. 규칙 세트는 Glue ETL 작업에 연결하거나 StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun API를 통해 독립적으로 실행하여 S3, 카탈로그 테이블 또는 Glue DynamicFrames에 저장된 데이터 세트를 평가할 수 있습니다.

주요 구성 세부 정보 및 결정 기준:

DQDL 구조: 규칙에는 ruleName, 표현식(DQDL 또는 SQL), 심각도, 실패 시 조치가 포함됩니다. 중요한 검사가 실패할 때 작업이 실패하도록 실패 시 조치를 FAIL로 명시적으로 설정하십시오. 그렇지 않으면 Glue는 실행을 실패시키지 않고 결과만 기록할 수 있습니다.
평가 컨텍스트: 작업 파라미터나 평가 실행 입력을 통해 테이블 또는 S3 경로 참조 및 샘플링 옵션(전체 스캔 vs. 샘플)을 제공하여 비용과 적용 범위 간의 균형을 맞춥니다.
출력: 규칙 평가는 결과를 Glue 지표와 Amazon S3에 JSON으로 기록합니다. 이 아티팩트를 감사 및 자동화된 해결에 사용하십시오.

Glue Data Quality와 외부 프레임워크 사용 시기 비교:

Glue 작업 및 리니지에 기본적으로 통합되는 표준 스키마, 완전성, 간단한 고유성 규칙에는 Glue DQDL을 사용하십시오.
더 풍부한 expectation 라이브러리, 더 표현력이 뛰어난 검사 또는 여러 시스템에서 공유되는 expectation 스위트가 필요한 경우 Great Expectations(다음 하위 도메인 참조)를 사용하십시오.

파이프라인의 데이터 검증 패턴

검증은 수집, 변환, 싱크 등 여러 접점에서 이루어져야 합니다. 일반적인 패턴:

파이프라인에 도달하기 전에 잘못된 행을 거부하거나 라우팅하기 위해 Lambda/Kinesis 생산자에서 스키마 및 기본값 범위에 대한 경량 사전 수집 검사를 수행합니다.
DQDL 규칙 세트와 코드 내 명시적 검증을 사용하여 Glue ETL(Spark) 작업에서 서버 측 검증을 수행합니다. Glue Studio에서는 규칙 세트를 참조하는 Data Quality 변환을 추가하고, CLI에서는

undefined

를 전달하거나 작업 파라미터를 포함하여 평가 실행을 트리거합니다.

Glue Python Shell 또는 Glue Spark 작업에 통합된 Great Expectations를 사용하여 변환 후 검증을 수행합니다. S3(expectations/ 디렉토리)에 expectation을 배포하고, S3 expectation을 작업 환경에 동기화한 후 작업에서

undefined

를 로드합니다.

검증 옵션 비교:

옵션	장점	단점
Glue DQDL	네이티브 통합, 낮은 운영 오버헤드, Glue 카탈로그/지표에 결과 작성	복잡한 논리적 expectation에 대한 표현력 부족
Great Expectations	풍부한 expectation, 데이터 문서, 통합된 체크포인트, 확장 가능한 백엔드	S3에서 expectation 아티팩트를 패키징 및 관리하고 Glue 작업에서 오케스트레이션 필요
코드 내 수동 검사(Spark/DataFrame)	완전한 유연성, 사용자 지정 로직에 대한 고성능	높은 유지보수 비용, 추가 작업 없이는 표준화된 보고 불가

스트리밍의 경우, 전송 중인 레코드를 검증하고 실패 시 폐기하는 대신 SQS DLQ(AWS CLI 또는 콘솔을 통해 maxReceiveCount로 RedrivePolicy 구성)로 푸시합니다. 배치의 경우, 검증 보고서 아티팩트를 생성하고 정책에 따라 출력을 실패 처리하거나 격리합니다.

이상 탐지 및 데이터 드리프트 모니터링

운영 지표(처리된 레코드 수, 오류율, 작업 기간)에 대해서는 CloudWatch 이상 탐지를 사용하십시오. CLI를 사용하여 탐지기를 생성하고(

undefined

), 그런 다음 이상 탐지 밴드를 참조하는 CloudWatch 경보를 생성합니다. 데이터 수준 드리프트(분포 변화, null 비율 변경)의 경우, Glue DataBrew 프로파일 작업(

undefined

)을 예약하여 통계, 히스토그램, 분위수를 계산하고 프로파일을 S3에 기준선으로 저장합니다.

이상 탐지 경보와 임계값 경보 간의 결정 기준:

지표 패턴이 계절적이거나 변동성이 클 때 CloudWatch 이상 탐지를 선택하십시오. 과거 동작을 학습하여 수동 임계값 조정을 줄여줍니다.
예측 가능성이 높은 이진 조건(예: 작업이 X시간 이상 중단됨)에는 정적 임계값 경보를 사용하십시오.

자동화된 드리프트 탐지를 위해:

데이터 속도에 따라 정기적인 DataBrew 프로파일 작업(매일/매주)을 예약하여 지표 기준선(null %, 카디널리티, 백분위수)을 캡처합니다.
새 프로파일 출력을 Glue 규칙 세트(사용자 지정 SQL 검사) 또는 기준 통계를 참조하는 Great Expectations 사용자 지정 expectation을 사용하여 기준 프로파일과 비교합니다.
드리프트가 정책 임계값을 초과하거나 이상 탐지기가 비정상적인 지표 동작을 감지하면 SNS / EventBridge를 사용하여 경고합니다.

SLA 관리 및 파이프라인 안정성

SLA 관리는 관측성(observability)을 문제 해결 및 안정성 엔지니어링과 연결합니다. 모든 파이프라인에 처리량(records/sec), 지연 시간(수집→싱크), 오류율, 작업/런타임, 다운스트림 개수와 같은 기준 지표를 설정하여 측정해야 합니다. Glue 작업(작업 실행 지표), Kinesis/Kafka 소비자 지연(lag), 그리고 PutMetricData를 통한 사용자 지정 애플리케이션 지표를 위해 CloudWatch Metrics를 사용하세요.

안정성 패턴 및 구성 세부 정보:

데드 레터 큐(SQS DLQ): 스트리밍 소비자(Lambda, Kinesis 소비자)를 위해 DLQ를 구성하고 RedrivePolicy(maxReceiveCount)를 설정합니다. DLQ 보존 기간과 별도의 처리 작업을 사용하여 DLQ 메시지를 검사하고 재처리합니다.
멱등성(Idempotent) 설계: 싱크가 멱등성 쓰기를 지원하도록 보장합니다 — 예시:
- DynamoDB: PutItem을 조건부 표현식과 함께 사용하거나 멱등성 토큰을 위한 복합 키를 사용합니다.
- S3: 원자적 이름 변경 패턴으로 쓰거나 콘텐츠 기반 키(레코드의 해시)를 사용하여 재실행 시 중복 생성 대신 덮어쓰도록 합니다.
- Redshift/Glue ETL: 재처리 후 중복을 제거하기 위해 키를 기준으로 스테이징 + MERGE를 사용합니다.
체크포인팅: Kinesis/DynamoDB 커넥터 체크포인트를 활성화하고, 재처리 기간과 중복 위험 사이의 균형을 맞추기 위해 소비자 체크포인트 빈도를 관리합니다.

재시도 vs 즉시 실패(fail-fast) 의사결정 기준:

일시적인 장애(다운스트림 스로틀링)의 경우, 지수 백오프(exponential backoff)를 사용한 재시도를 구현하고 최대 재시도 횟수 초과 시에만 DLQ로 보냅니다.
데이터 품질 장애(스키마 불일치)의 경우, 즉시 실패 처리하고 문제 레코드를 메타데이터와 함께 수동 검토를 위한 격리용 S3 프리픽스에 씁니다.

일반적인 함정과 의사결정 기준

Glue Data Quality 규칙은 기본적으로 실패를 기록만 할 뿐 작업을 실패시키지는 않습니다 — 중요한 검사에 대해서는 규칙 작업을 FAIL로 구성하고 규칙 세트 평가를 작업 실행에 연결해야 합니다.
DLQ가 없는 스트리밍 파이프라인은 실패한 레코드를 버리거나 유실합니다 — 항상 SQS DLQ(또는 영구적인 S3 스테이징)와 재처리 정책(redrive policy)을 구성하여 실패한 레코드를 검사하고 재처리해야 합니다.
멱등성 없이 재처리하면 중복 레코드가 생성됩니다 — 결정론적 키를 설계하고, 싱크에서 upsert/merge 시맨틱을 사용하거나, S3에 콘텐츠 기반 객체 키를 적용해야 합니다.
기준선 없는 데이터 드리프트 탐지는 노이즈가 많은 알림을 생성합니다 — Glue DataBrew 프로파일 작업을 스케줄링하여 기준 통계를 생성 및 저장한 다음, 새로운 프로파일을 이 기준선과 비교해야 합니다.
정적 CloudWatch 임계값에 과도하게 의존하면 오탐(false positive)이 발생합니다 — 계절성/변동성 있는 지표에는 CloudWatch 이상 탐지를 사용하고, 정적 임계값은 절대적인 한계치에 대해서만 사용해야 합니다.
maxReceiveCount를 너무 높게 설정하면 DLQ 라우팅이 지연되고 처리 지연 시간이 늘어납니다 — 지속적으로 실패하는 메시지가 DLQ로 적시에 수신되도록 합리적인 maxReceiveCount를 선택해야 합니다.

실용적인 문제: 사용 사례 시나리오

Streamline Retail은 야간 ETL 작업 후 다운스트림 리포팅에서 잦은 오류에 직면하고 있습니다: 간헐적인 스키마 변경, 감지되지 않는 규칙 위반, 실패한 작업 재처리 시 중복 주문 발생 등의 문제입니다.

스키마, null 임계값, order_id 고유성에 대해 Glue Data Quality 규칙(DQDL)을 구현합니다. 실패 시 작업이 FAIL되도록 작업을 설정하고 평가 결과물을 S3에 게시합니다.
복잡한 비즈니스 검사(테이블 간 주문 일관성)를 위해 Glue Python Shell 단계에 Great Expectations를 추가합니다. 기대값(expectations)을 S3에 저장하고 파이프라인에서 체크포인트를 실행합니다.
DataBrew 프로파일 작업을 스케줄링하여 일일 기준선(카디널리티, null 비율, 백분위수)을 캡처하고, 자동화된 비교를 사용하여 드리프트를 탐지합니다.
스트리밍 주문 이벤트의 경우, 적절한 RedrivePolicy를 사용하여 SQS DLQ를 구성하고, DLQ 메시지를 멱등적으로 처리하는 재처리 작업을 생성합니다(order_id를 중복 제거 키로 사용).
작업 런타임 및 오류 수에 대해 CloudWatch 이상 탐지기를 설정합니다. 이상 기반 알람을 SNS에 연결하여 온콜 에스컬레이션을 수행합니다.

AWS 모범 사례의 근거: 빠른 통합을 위해 네이티브 Glue 품질 제어 기능을 사용하고, 풍부한 표현력을 위해 Great Expectations를, 기준 통계를 위해 DataBrew를, 적응형 모니터링을 위해 CloudWatch 이상 탐지기를 결합합니다. DLQ와 멱등성 싱크는 SLA를 유지하면서 안전한 재시도와 재처리를 위한 선순환 구조를 완성합니다.

← 데이터 워크로드 비용 최적화 · 모든 도메인

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →