데이터 변환(Data Transformation)은 원자재를 완성품으로 가공하는 공장 공정과 같습니다. 수집된 원시 데이터는 그대로는 분석에 쓸 수 없는 경우가 많습니다. 형식이 맞지 않거나, 정제가 필요하거나, 다른 데이터와 합쳐야 하기 때문입니다. ETL(Extract-Transform-Load)이 바로 이 가공 과정을 의미합니다. AWS DEA-C01 시험에서는 "어떤 변환 도구를 선택하고, 어떤 파일 형식을 사용하며, 어떻게 분산 처리를 설계하는가"를 집중적으로 묻습니다.
ETL 서비스 비교 — 어떤 도구가 어떤 상황에 맞을까?
AWS에는 데이터 변환을 위한 여러 서비스가 있습니다. 각각의 역할과 적합한 상황을 이해하는 것이 핵심입니다.
| 서비스 | 특징 | 적합한 상황 | |--------|------|-----------| | AWS Glue ETL | 완전 서버리스, Apache Spark 기반, 자동 스케일링 | 정형/반정형 데이터 배치 변환, S3/Redshift/RDS 간 데이터 이동 | | Amazon EMR | Hadoop/Spark 클러스터 직접 관리 | 대규모 커스텀 처리, 복잡한 파이프라인, 비용 최적화가 중요한 경우 | | AWS Lambda | 완전 서버리스, 이벤트 기반, 최대 15분 | 단순 변환, 소규모 데이터, 이벤트 트리거 작업 | | Amazon Redshift | SQL 기반 변환 | 이미 Redshift에 로드된 데이터의 변환 및 집계 |
결정 규칙: 새로운 서버리스 ETL을 만든다면 → Glue ETL 기존 Hadoop/Spark 워크로드가 있거나 세밀한 클러스터 제어가 필요하다면 → EMR 파일 업로드나 API 호출 같은 이벤트에 반응하는 단순 변환 → Lambda 이미 Redshift 안에 있는 데이터를 변환하고 싶다면 → Redshift SQL
AWS Glue ETL — 서버리스 데이터 가공 공장
AWS Glue ETL은 인프라를 직접 관리하지 않고도 대규모 데이터 변환을 수행할 수 있는 서버리스 서비스입니다. 셰프(Glue)가 식재료(원시 데이터)를 받아서 레시피(ETL 스크립트)대로 요리(변환)하고, 완성된 요리(변환된 데이터)를 접시(S3, Redshift 등)에 담아준다고 생각하면 됩니다.
DynamicFrame이란?
Glue ETL에서 데이터를 다루는 기본 단위입니다. Apache Spark의 DataFrame과 비슷하지만, 스키마가 불일치하거나 NULL 값이 있어도 자동으로 처리해줍니다. 예를 들어 어떤 레코드에는 "age" 필드가 있고 다른 레코드에는 없는 경우에도 오류 없이 처리됩니다. 현실 세계의 지저분한 데이터를 다루기에 적합합니다.
Glue 북마크(Bookmarks)
북마크는 "이미 처리한 데이터를 기억하는" 기능입니다. 매일 밤 S3에 새 파일이 추가되는데, 어제까지 처리한 파일은 다시 처리하고 싶지 않을 때 사용합니다. 책갈피처럼, Glue가 "어디까지 읽었는지"를 기억해서 다음 실행 시 새로운 데이터만 처리합니다.
작업 유형 3가지:
Spark 작업: 대규모 배치 처리에 적합. 분산 처리로 수TB 데이터도 처리 가능. Streaming 작업: Kinesis나 MSK에서 들어오는 실시간 데이터를 마이크로배치로 처리. Python Shell 작업: 간단한 Python 스크립트. 소규모 데이터나 API 호출에 적합.
Glue Studio
코드를 몰라도 ETL 파이프라인을 만들 수 있는 시각적 편집기입니다. 드래그앤드롭으로 데이터 소스, 변환 단계, 목적지를 연결하면, Glue Studio가 자동으로 PySpark 코드를 생성합니다. 비개발자도 ETL 파이프라인을 구성할 수 있습니다.
파일 형식 선택 — 어떤 그릇에 데이터를 담을까?
데이터 파일 형식은 성능과 비용에 큰 영향을 미칩니다. 음식을 어떤 그릇에 담느냐에 따라 보관, 운반 효율이 달라지는 것처럼, 데이터 형식도 읽기/쓰기 속도와 저장 공간에 직접적인 영향을 줍니다.
| 형식 | 구조 | 압축 | 용도 | |------|------|------|------| | CSV | 행 기반, 텍스트 | 낮음 | 사람이 읽기 쉬운 원시 데이터, 소규모 | | JSON | 행 기반, 텍스트 | 낮음 | API 응답, 중첩 구조 데이터 | | Parquet | 열 기반(columnar), 바이너리 | 높음 | 분석 쿼리 최적화 (Athena, Redshift Spectrum, Spark) | | ORC | 열 기반, 바이너리 | 높음 | Apache Hive 워크로드, EMR | | Avro | 행 기반, 바이너리 | 중간 | 스트리밍, 스키마 자주 변경 |
열 기반 형식(Parquet/ORC)이 분석에 유리한 이유
책장에서 특정 페이지를 찾을 때, 책 전체를 읽는 것보다 목차를 보고 해당 페이지로 바로 가는 게 빠릅니다. 열 기반 형식이 바로 이 원리입니다. 분석 쿼리는 보통 전체 행이 아니라 특정 열 몇 개만 필요합니다. Parquet는 열별로 데이터를 저장하므로, 를 실행할 때 revenue와 date 열만 읽으면 됩니다. 수백 개의 열이 있는 테이블에서 쿼리 속도와 비용이 크게 향상됩니다.
Avro가 스트리밍에 강한 이유
Avro는 스키마를 데이터와 함께 저장합니다. 스키마가 변경되어도 이전 데이터를 다시 쓸 필요가 없습니다. 새 필드가 추가되거나 기존 필드가 삭제되어도 이전 레코드가 정상 작동합니다. 끊임없이 변하는 실시간 데이터 스트림에 적합한 이유입니다.
형식 선택 규칙: 분석 쿼리(Athena, Redshift Spectrum)가 주 목적 → Parquet Apache Hive/EMR 워크로드 → ORC 스트리밍 데이터, 스키마 변경 잦음 → Avro CSV 파일을 받았는데 Athena로 분석하고 싶다 → Glue로 Parquet 변환 먼저
Amazon EMR — 직접 운전하는 분산 처리 클러스터
Amazon EMR(Elastic MapReduce)은 Apache Hadoop과 Apache Spark 등의 분산 처리 프레임워크를 AWS에서 클러스터로 실행하는 서비스입니다. Glue ETL이 "택시(서버리스, 직접 운전 불필요)"라면, EMR은 "자가용(직접 클러스터를 관리하지만 완전한 제어권)"에 가깝습니다.
EMR 인스턴스 그룹의 3가지 역할
마스터 노드(Master Node): 클러스터의 두뇌. 작업을 배분하고 클러스터를 조율합니다. 항상 1개 존재하며, 장애 발생 시 클러스터 전체에 영향을 주므로 온디맨드 인스턴스 사용을 권장합니다. 코어 노드(Core Node): 실제 데이터 처리 + HDFS(분산 파일 시스템) 저장을 담당합니다. 코어 노드가 사라지면 데이터가 손실될 수 있으므로 온디맨드 인스턴스 사용을 권장합니다. 태스크 노드(Task Node): 처리만 담당합니다. HDFS에 데이터를 저장하지 않으므로, 언제든 추가/제거해도 데이터 손실이 없습니다. 스팟 인스턴스(저렴한 여유 용량)를 활용해 비용을 크게 절감할 수 있습니다.
스팟 인스턴스 활용 전략
| 노드 유형 | 권장 인스턴스 | 이유 | |---------|------------|------| | 마스터 | 온디맨드 | 클러스터 안정성에 필수 | | 코어 | 온디맨드 | 데이터 손실 방지 | | 태스크 | 스팟 인스턴스 | 데이터 저장 없음, 비용 절감 |
서버리스 EMR(EMR Serverless)
클러스터를 직접 구성하지 않고 Spark/Hive 작업을 실행할 수 있는 방식입니다. Glue ETL과 비슷하게 서버리스이지만, 기존 Spark/Hive 코드를 그대로 실행할 수 있다는 장점이 있습니다. Glue와 EMR Serverless의 차이: Glue는 AWS 독자 DynamicFrame API를 제공하고, EMR Serverless는 순수 Spark/Hive 코드를 실행합니다.
시험 핵심 정리
| 키워드 | 선택 서비스/개념 | |--------|----------------| | 서버리스 ETL, Spark 기반, 자동 스케일링 | AWS Glue ETL | | 대규모 커스텀 Hadoop/Spark 처리 | Amazon EMR | | 이미 처리한 데이터 추적, 중복 방지 | Glue 북마크 | | 스키마 불일치 자동 처리 | Glue DynamicFrame | | 코드 없이 ETL 파이프라인 구성 | Glue Studio | | 분석 쿼리 최적화 열 기반 형식 | Parquet | | Hive/EMR 워크로드 열 기반 형식 | ORC | | 스트리밍, 스키마 자주 변경 | Avro | | EMR 비용 절감 | 태스크 노드에 스팟 인스턴스 사용 | | Lambda 15분 초과 ETL 작업 | Glue 또는 EMR로 전환 |
CSV → Parquet 변환은 Athena 쿼리 비용과 성능 모두를 크게 개선하는 DEA-C01 시험의 단골 주제입니다.