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.

대규모 처리를 위한 Amazon EMR

EMR은 클러스터 수준의 제어, 사용자 지정 부트스트랩 액션 또는 특수 라이브러리가 필요한 경우, 사용자 정의 가능한 대규모 빅데이터 처리(Spark, Hadoop, Presto, Flink)를 위한 최고의 선택입니다. aws emr create-cluster CLI를 통해 클러스터를 생성하며 --instance-groups 또는 --instance-fleets 중 하나를 선택합니다. 인스턴스 플릿은 유연한 인스턴스 유형 조합과 스팟/온디맨드 조합을 제공하며, 인스턴스 그룹은 더 단순한 고정 크기 그룹입니다.

고려해야 할 EMR 클러스터 패턴:

• 임시 클러스터: --auto-terminate로 시작하고 스텝을 제출하여 스텝이 완료되면 클러스터가 종료되도록 합니다. 비용 제어에 좋지만, 종료 시 임시 HDFS 및 로컬 상태는 손실됩니다.
• 상시 실행 클러스터: 자동 종료되지 않으며, 대화형 워크로드, 영구적인 HDFS 또는 많은 작은 작업이 JVM 워밍업의 이점을 얻을 때 사용합니다. 클러스터 종료가 예상되는 경우 중요한 데이터는 S3 또는 EBS 기반 Hadoop 스토리지에 영구 저장해야 합니다.

구성 예시:

• 인스턴스 그룹 CLI:

undefined

• 인스턴스 플릿 CLI는 --instance-fleets를 사용하여 OnDemand/Spot 할당과 여러 인스턴스 유형을 활용해 복원력과 비용 최적화를 달성합니다.

Hadoop 에코시스템 구성 요소에 대한 완전한 제어, 사용자 지정 부트스트랩 스크립트 또는 중간 데이터를 위한 영구 HDFS가 필요할 때 EMR을 사용하십시오. 그렇지 않고 Glue Data Catalog와 통합되는 관리형 Spark ETL이 필요하다면 Glue Spark가 더 간단합니다.

Glue DataBrew와 시각적 변환

Glue DataBrew는 데이터 분석가와 엔지니어가 대화형으로 작업하는 것을 목표로 하는 데이터 프로파일링, 정제, 변환을 위한 시각적인 no-code/low-code 도구입니다. S3 또는 Glue Catalog에서 데이터 세트를 생성하고, 콘솔에서 변환 레시피를 구축하고, 샘플에서 미리보기를 한 후, 작업을 실행하여 레시피를 대규모로 적용합니다. DataBrew 작업을 예약하거나 aws databrew start-job-run --name my-databrew-job CLI를 통해 실행할 수 있습니다.

DataBrew는 표준화, 중복 제거, 유형 변환, 내장 함수를 사용한 열 수준 변환과 같은 데이터 준비 작업에 최적화되어 있습니다. Glue Catalog과 통합되며 출력물을 S3에 씁니다. 비즈니스 사용자가 셀프 서비스 데이터 정제 및 빠른 프로파일링이 필요할 때 DataBrew를 선택하고, 무거운 변환 로직, 복잡한 조인 또는 매우 큰 데이터 세트의 경우 Glue Spark 또는 EMR을 사용하는 것이 좋습니다.

시각적 변환과 코드 기반 변환 비교:

• Glue DataBrew
  • 장점: 빠른 프로파일링, 레시피 기반, 코딩 경험 없는 사용자도 파이프라인 구축 가능, 통합된 스케줄링.
  • 단점: 매우 크거나 매우 복잡한 분산 조인 및 사용자 지정 라이브러리에는 적합하지 않음.
• Glue Spark / EMR
  • 장점: 완전한 프로그래밍 방식 제어, 대용량 데이터 세트 처리, 서드파티 라이브러리 지원.
  • 단점: 개발자 기술과 더 많은 구성이 필요함.

일반적인 함정과 결정 기준

• Glue 작업 북마크가 JDBC 소스에 대해 작동한다고 가정하는 것 — 북마크는 S3 객체/파티션 상태만 추적합니다. JDBC 증분 로드의 경우 워터마크 컬럼, 변경 데이터 캡처(change-data-capture)를 사용하거나 진행 상황을 DynamoDB/S3에 저장해야 합니다.
• 임시 EMR 클러스터를 상태 저장(stateful) 시스템처럼 취급하는 것 — 임시 클러스터는 스텝 실행 후 종료되며 HDFS를 잃게 됩니다. 중간 데이터는 S3에 영구 저장하거나 내구성 있는 스토리지를 위해 EBS 볼륨을 사용해야 합니다.
• 스트리밍 파이프라인에서 Lambda 콜드 스타트를 무시하는 것 — 콜드 스타트는 지연 시간을 증가시킵니다. 중요한 경로에 대해 프로비저닝된 동시성으로 완화하거나, 엄격한 낮은 지연 시간 요구사항을 위해 오래 실행되는 컴퓨팅을 사용해야 합니다.
• Glue Python 셸에서 대규모 변환을 실행하는 것 — Python 셸 작업은 1 DPU로 제한됩니다. 대규모 데이터 세트의 경우 적절한 workerType/NumberOfWorkers를 갖춘 Glue Spark 작업을 사용해야 합니다.
• EMR 인스턴스 유형을 잘못 구성하는 것: 스팟 인스턴스를 활용한 비용 및 유연성을 위해 인스턴스 플릿을 선택하고, 예측 가능한 인스턴스 구성이 필요할 때는 인스턴스 그룹을 사용합니다.
• 긴급한 워크로드에 Glue Flex를 과도하게 사용하는 것 — FLEX는 비용을 절감하지만 시작 시간이 지연될 수 있습니다. 예측 가능한 시작 및 실행 시간을 위해서는 STANDARD를 사용합니다.

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

AcmeRetail은 매일 밤 클릭스트림 Parquet 파일을 통합 고객 활동 테이블로 처리하며, 긴급하지 않은 백필(backfill) 작업 비용을 낮게 유지하면서 수개월 분량의 데이터를 재처리하지 않기 위해 증분 처리를 원합니다.

1. S3 파티션 레이아웃(year=/month=/day=)을 사용하고 Glue Data Catalog에 데이터 세트를 등록합니다.
2. 스키마 유연성을 위해 DynamicFrame.from_catalog을 읽고, 매핑을 적용하고, 복잡한 조인을 위해 DataFrame으로 변환한 다음, 파티셔닝된 Parquet을 다시 S3에 쓰는 Glue Spark 작업(glueetl)을 생성합니다.
3. 매일 밤 실행 시 새로운 파티션만 처리하도록 Glue 작업 북마크(job-bookmark-enable)를 활성화합니다. JDBC 보강 소스의 경우, 처리된 최대 타임스탬프를 추적하기 위해 DynamoDB에 영구 저장되는 워터마크 컬럼을 구현합니다.
4. 정기적인 야간 실행에는 ExecutionClass=STANDARD를 사용하고, 긴급하지 않은 과거 데이터 재처리에는 --execution-class FLEX로 실행을 제출하여 비용을 절감합니다.
5. CloudWatch 지표로 모니터링하고 작업 실패에 대한 경보를 설정합니다. 매우 큰 규모나 사용자 지정 라이브러리가 필요한 경우, 중간 결과를 S3에 쓰고 자동 종료되는 EMR 임시 클러스터를 고려합니다.

근거: 이 접근 방식은 확장 가능한 변환을 위해 Glue의 관리형 Spark를, 반정형 입력을 위해 DynamicFrame을 활용하고, S3 증분 처리를 위해 작업 북마크를 사용하며, 백필 비용 절감을 위해 FLEX를 사용하여 비용, 안정성 및 운영 단순성을 유지합니다.

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

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

Amazon 찾아보기 →