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.

이 도메인은 대규모 데이터셋에 대한 분석 쿼리 및 BI를 지원하는 AWS 서비스의 설계, 튜닝, 운영을 다룹니다. Athena, Redshift, OpenSearch, QuickSight 전반에 걸친 비용 효율적이고 고성능인 쿼리 패턴과, 이 서비스들이 S3, Glue, 트랜잭션 스토어와 어떻게 상호 운용되는지에 중점을 둡니다. 이 분야를 마스터하려면 스토리지 포맷, 파티셔닝, 컴퓨팅 유형, 데이터 배치 간의 균형을 맞춰 스캔되는 바이트와 네트워크 스큐(skew)를 최소화하면서 지연 시간이 짧은 인사이트를 제공해야 합니다.

Amazon Athena 쿼리 최적화

Athena의 요금은 스캔한 바이트를 기준으로 책정되므로, 물리적 데이터 레이아웃과 메타데이터가 주요 최적화 요소입니다. 컬럼 기반 포맷(Parquet 또는 ORC)과 압축(Parquet의 경우 Snappy, Zlib/ORC 옵션)을 사용하여 크기와 CPU 사용량을 줄이십시오. 카디널리티가 높고 쿼리에서 필터링되는 컬럼(예: 날짜, 리전)을 기준으로 데이터를 파티셔닝하고, Glue Data Catalog에 파티션을 등록하십시오. 일반적인 패턴:

s3://bucket/events/date=2026-08-02/와 같은 경로에 데이터를 S3에 쓰고, Glue 크롤러나 MSCK REPAIR TABLE을 사용하여 파티션을 채웁니다.
CREATE EXTERNAL TABLE … STORED AS PARQUET TBLPROPERTIES (‘parquet.compress’=‘SNAPPY’)를 사용하여 컬럼 기반 압축을 강제합니다.
파티션 키를 참조하는 WHERE 절을 통해 프로젝션 및 파티션 프루닝(pruning)을 사용하여 불필요한 파티션 스캔을 방지합니다.

쿼리가 트랜잭션 스토어와의 조인을 필요로 할 때, Athena Federated Query(Lambda 커넥터)를 사용하여 RDS, DynamoDB 또는 Redshift와 교차 소스 조인을 수행합니다. 커넥터는 Lambda 함수로 배포되고 Athena에 데이터 소스로 등록됩니다. 콘솔 흐름 예시: Athena > 데이터 원본 > 커넥터 > 새로 만들기. 결정 기준:

RDS/DynamoDB의 데이터 볼륨이 적거나 작은 차원 테이블을 큰 S3 데이터셋에 조인할 때 Federated Query를 사용합니다.
반복적인 대규모 조인의 경우, 운영 데이터를 S3(Parquet)로 추출하고 구체화(materialize)하여 조인 비용을 단일 ETL로 전환하고, 반복적인 읽기에는 Athena를 사용합니다.

Amazon Redshift 쿼리 튜닝 및 분산

Redshift 성능은 데이터 이동을 최소화하고 존 맵(zone map)을 활성화하기 위한 분산 스타일(distribution style)과 정렬 키(sort key)에 따라 결정됩니다. 다음 결정 포인트를 사용하여 DIST 스타일을 선택하십시오:

DISTKEY (KEY): 카디널리티가 높은 조인 키로 대용량 테이블을 조인할 때 유용합니다. 두 테이블이 동일한 DISTKEY를 공유하면 재분산(redistribution)을 방지합니다.
ALL: 작은 차원 테이블을 모든 노드에 복제하여 조인을 위한 네트워크 셔플(shuffle)을 방지합니다.
EVEN: 예측 불가능한 워크로드나 적절한 키가 없을 때의 기본값입니다. 핫스팟(hotspot)을 방지합니다.
AUTO: 명확한 지침이 없는 경우 Redshift가 테이블 크기와 워크로드에 기반하여 선택하도록 합니다.

범위 필터나 ORDER BY에 사용되는 컬럼에 SORTKEY를 정의하여 존 맵을 활성화하고 디스크 읽기를 줄입니다. 일반적인 운영 명령어:

CREATE TABLE sales (…) DISTKEY(user_id) SORTKEY(order_date);
주기적으로 VACUUM과 ANALYZE를 사용하십시오: VACUUM; ANALYZE VERBOSE table; SVV_TABLE_INFO와 STL_QUERY를 모니터링하여 스큐 및 분산 지표를 확인합니다. Redshift Spectrum을 사용하면 Glue Data Catalog를 통해 S3 외부 테이블을 쿼리할 수 있습니다. 다음을 사용하여 외부 스키마를 생성합니다:
CREATE EXTERNAL SCHEMA spectrum FROM DATA CATALOG DATABASE ’ext_db’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftSpectrumRole’ CREATE EXTERNAL DATABASE IF NOT EXISTS; Spectrum 대 네이티브 Redshift 결정 기준:
S3에 저장된 드물게 쿼리되는 대용량 콜드 데이터나 계층형 데이터 아키텍처에 Spectrum을 사용합니다.
성능을 위해 자주 조인되는 핫 데이터셋은 Redshift 내부에 유지합니다. Spectrum과 조인할 때는 조인 키를 동일한 위치에 배치(colocate)하기 위해 DISTKEY를 선택하거나 재분산을 사용하여 네트워크 I/O를 최소화합니다.

로그 분석을 위한 Amazon OpenSearch Service

OpenSearch는 수집 및 빠른 임시(ad-hoc) 로그 분석에 최적화되어 있습니다. 인덱스와 클러스터 구성이 처리량과 비용을 결정합니다. 인덱스 설계 및 수명 주기:

logs-YYYY.MM.DD와 같은 인덱스 패턴과 인덱스 템플릿을 사용하여 index.number_of_shards(작은 인덱스: 1개 샤드, 큰 인덱스: ~10-50GB 크기의 여러 샤드)와 가용성을 위한 index.number_of_replicas를 설정합니다.
비용 관리를 위해 인덱스 수명 주기 정책(ILM)을 구성하여 인덱스를 hot, warm, cold, UltraWarm 티어로 전환합니다. UltraWarm은 기록 데이터에 대한 hot 노드 스토리지 비용을 절감합니다. 샤딩과 복제본은 쿼리 및 인덱싱 성능에 영향을 미칩니다:
샤드가 많을수록 병렬성은 증가하지만 오버헤드가 추가됩니다. 힙과 CPU를 기반으로 노드당 샤드 수를 조정합니다.
복제본은 읽기 처리량과 내결함성을 향상시킵니다. 쿼리 동시성 및 SLA에 따라 복제본 수를 설정합니다. 운영 명령어 및 콘솔 패턴:
OpenSearch Dev Tools(또는 curl)를 사용하여 인덱스 템플릿과 ILM 정책을 PUT하고, 클러스터 상태 API로 모니터링합니다. 노드 속성을 할당하고 샤드 할당 인식을 사용하여 핫스팟을 방지합니다. 결정 기준:
기록 로그에 대한 쿼리 지연 시간 요구 사항이 더 낮은 스토리지 비용을 위해 더 높은 읽기 지연 시간을 허용할 수 있을 때 UltraWarm을 선택합니다.
최신 인덱스는 hot 노드에 유지하여 빠른 집계와 대시보드를 지원합니다.

BI 및 시각화를 위한 QuickSight

QuickSight는 두 가지 주요 수집 모드인 SPICE(인메모리)와 직접 쿼리(direct query)를 통해 빠른 대시보드를 제공합니다. SPICE는 대시보드에 대해 1초 미만의 성능을 제공하며 반복적인 읽기에 적합합니다. 직접 SQL 쿼리(Athena, Redshift, RDS 대상)는 매우 큰 데이터셋이나 자주 변경되는 데이터에 더 적합합니다. 주요 구성 및 모범 사례:

콘솔에서 데이터셋 생성: 새 데이터셋 > 소스 선택(Athena/Redshift/RDS/OpenSearch) > SPICE로 가져오기 또는 직접 쿼리 사용.
일별/거의 실시간 요구 사항에 대해 예약된 SPICE 새로 고침을 사용합니다. 데이터 이동을 제한하기 위해 타임스탬프 파티셔닝을 통해 증분 새로 고침을 구성합니다. 보안 및 거버넌스:
QuickSight 사용자/그룹 매핑 및 데이터셋 규칙을 통해 행 수준 보안(row-level security)을 구현합니다.
교차 계정 데이터 액세스를 위해 QuickSight가 수임할 IAM 역할 및 리소스 기반 권한을 배포합니다. 결정 기준:
동시 뷰어가 많고 새로 고침 기간이 예측 가능한 대시보드에는 SPICE를 사용합니다.
데이터 최신성이 중요하거나 SPICE 용량이 제한될 때 직접 쿼리를 사용합니다. 대화형 UX를 위해 계산된 필드 및 파라미터와 결합합니다.

일반적인 함정과 결정 기준

Athena는 스캔한 데이터 양에 따라 요금을 부과하므로, 항상 쿼리 조건자를 기준으로 파티셔닝하고 컬럼 기반 형식(Parquet/ORC)으로 저장하며 압축(Snappy/Zlib)을 사용하여 스캔되는 바이트를 줄여야 합니다.
카디널리티가 낮은 열에 Redshift DISTKEY를 사용하면 데이터 스큐가 발생하므로, DISTKEY에는 카디널리티가 높은 조인 키를 선택하거나 작은 차원 테이블에는 DISTSTYLE ALL을 사용해야 합니다.
Redshift Spectrum 외부 테이블은 Glue Data Catalog가 필요하므로, 대상 리전에서 Glue가 활성화되어 있는지, 그리고 IAM 역할이 Redshift의 카탈로그 접근을 허용하는지 확인해야 합니다.
OpenSearch 샤드 수 및 크기 조정 실수 — 너무 작은 샤드를 많이 만들지 않도록 주의하고, 샤드 크기는 수십 GB로 조정하며 ILM을 사용하여 오래된 인덱스를 UltraWarm으로 이동시켜 비용을 절감해야 합니다.
Redshift에 대량 로드 후 RUN ANALYZE/VACUUM 실행을 잊는 경우 — ANALYZE와 VACUUM을 스케줄링하여 통계를 새로 고치고 디스크 공간을 회수하여 최적의 쿼리 계획을 수립하도록 해야 합니다.
QuickSight SPICE 오버플로 및 오래된 데이터 문제 — SPICE 용량을 계획하고, 증분 새로 고침을 사용하거나, 실시간 요구사항에는 직접 쿼리로 전환해야 합니다.

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

Acme Retail은 Amazon RDS의 트랜잭션 주문, S3의 클릭스트림 이벤트, DynamoDB의 사용자 프로필을 결합한 일일 BI 보고서가 필요하며, 비용 제한이 있고 최신 데이터에 대해서는 1분 미만의 대시보드 새로 고침이 요구됩니다.

S3의 클릭스트림 데이터를 날짜 기반으로 파티셔닝된 Parquet으로 변환하고, Snappy로 압축한 후, 크롤러를 통해 AWS Glue에 메타데이터를 등록합니다.
S3에 대한 임시 쿼리에는 Athena를 사용하고, RDS 및 DynamoDB용 Federated Query 커넥터를 배포하여 작은 차원 테이블과의 조인을 수행합니다. 쿼리가 반복되는 경우, 자주 사용되는 조인 결과는 Parquet으로 구체화합니다.
무거운 분석 조인을 위해 Redshift를 프로비저닝합니다. 집계된 스냅샷을 Redshift에 로드하고, 카디널리티가 높은 customer_id에 DISTKEY를 설정하며, order_date에 SORTKEY를 정의합니다. 오래된 S3의 기록 데이터에는 Spectrum을 사용합니다.
일별 인덱스 패턴을 사용하여 애플리케이션 로그를 OpenSearch로 수집합니다. ILM을 적용하여 최신 인덱스는 핫 노드에 유지하고, 오래된 인덱스는 비용 절감을 위해 UltraWarm으로 이동시킵니다.
QuickSight 대시보드를 구축합니다. 1분 미만의 체감 응답성을 위해 예약된 증분 새로 고침을 사용하여 최신 집계 데이터를 SPICE로 가져오고, 항상 최신 상태여야 하는 지표에는 직접 쿼리를 사용합니다.

근거: 이 접근 방식은 파티셔닝과 컬럼 기반 형식을 통해 Athena 스캔 비용을 최소화하고, 적절한 분산 키와 정렬 키로 Redshift 네트워크 셔플을 줄이며, Spectrum을 사용하여 오래된 데이터를 Redshift에 저장하는 것을 피하고, OpenSearch ILM을 적용하여 스토리지 비용을 최적화하며, 직접 쿼리를 통해 중요한 데이터의 최신성을 유지하면서 SPICE를 활용하여 반응성이 뛰어난 대시보드를 제공합니다.

← 데이터 오케스트레이션 및 워크플로우 관리 · 모든 도메인 · 데이터 보안 →

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