Day 2 - 데이터 카탈로그·ETL: AWS Glue와 DataBrew

Glue Data Catalog: 데이터 레이크의 메타데이터 저장소

S3에 객체를 던져 넣는 것만으로는 분석도 학습도 할 수 없다. "이 버킷에 무슨 데이터가, 어떤 스키마로 들어 있는가"를 알아야 Athena로 쿼리하고 SageMaker로 학습할 수 있다.

Glue Data Catalog는 Hive Metastore 호환 메타데이터 저장소다. 데이터 자체가 아니라 데이터에 대한 정보 — 테이블 이름, 컬럼, 타입, S3 위치, 파티션 — 를 저장한다.

Glue Data Catalog 구조:
Database (논리적 그룹)
└─ Table (S3 위치 + 스키마 + 파티션)
   ├─ Columns: customer_id (string), amount (double), ts (timestamp)
   ├─ Location: s3://ml-datalake/curated/transactions/
   ├─ SerDe: parquet
   └─ Partitions: year=2026/month=06, year=2026/month=05, ...

이 카탈로그는 Athena, Redshift Spectrum, EMR, SageMaker, Glue ETL이 공통으로 참조한다. 한 번 등록하면 모든 분석/ML 도구가 같은 스키마를 본다.

Glue Data Catalog는 Apache Hive의 Metastore를 계승한 개념이다. Hive는 2009년 Facebook이 HDFS 위에서 SQL을 쓰기 위해 만든 시스템인데, 핵심 발상이 "데이터(HDFS 파일)와 스키마(Metastore)를 분리"하는 것이었다. 이 분리가 곧 schema-on-read다. 데이터를 쓸 때 스키마를 강제하는 전통 DB(schema-on-write)와 달리, 데이터 레이크는 일단 원본을 저장하고 읽을 때 스키마를 적용한다. 덕분에 다양한 포맷·소스의 데이터를 유연하게 수용할 수 있다.

Glue Crawler: 스키마 자동 추론

S3에 수천 개의 파일이 있을 때 일일이 테이블을 정의하는 건 비현실적이다. Glue Crawler가 S3(또는 JDBC 소스)를 스캔해 스키마를 자동 추론하고 카탈로그에 테이블을 만든다.

크롤러의 동작:

1. 지정한 S3 경로를 스캔
2. 파일 포맷 감지(Parquet/CSV/JSON 등)
3. 컬럼과 타입 추론(classifier 사용)
4. 키=값 디렉터리를 파티션으로 인식
5. Data Catalog에 테이블 생성/업데이트

import boto3
 
glue = boto3.client("glue")
 
glue.create_crawler(
    Name="transactions-crawler",
    Role="arn:aws:iam::123456789012:role/GlueCrawlerRole",
    DatabaseName="ml_datalake",
    Targets={"S3Targets": [{"Path": "s3://ml-datalake/curated/transactions/"}]},
    Schedule="cron(0 2 * * ? *)",  # 매일 02:00 UTC
)
glue.start_crawler(Name="transactions-crawler")

크롤러는 같은 폴더에 스키마가 다른 파일들이 섞여 있으면 여러 테이블로 쪼개거나 하나로 합치거나 한다. 이 동작은 크롤러 설정의 "schema change policy"와 "grouping behavior"로 제어한다. 시험 함정: 크롤러를 다시 돌렸을 때 새 컬럼이 추가되면 기본적으로 스키마를 업데이트하지만, 컬럼 삭제는 정책에 따라 무시할 수도 있다. 또한 크롤러가 파티션을 매번 풀스캔하지 않게 "crawl new folders only" 옵션을 쓰면 비용이 준다.

새 파티션을 인식시키는 방법은 크롤러만 있는 게 아니다.

⚠️ 함정: "파티션을 추가했는데 Athena가 못 찾는다"는 시나리오에서 무조건 크롤러 재실행을 고르면 비용·시간 면에서 최선이 아닐 수 있다. 스키마 변화 없이 파티션만 늘었다면 MSCK REPAIR TABLE이나 partition projection이 더 가볍다.

Glue ETL Job: 서버리스 데이터 변환

카탈로그가 "무엇이 어디 있는지"라면, Glue ETL Job은 "데이터를 어떻게 변환하는지"다. Apache Spark(또는 Python Shell, Ray) 기반으로 서버리스 실행된다.

핵심 추상화는 DynamicFrame이다. Spark DataFrame과 비슷하지만, 스키마가 일정하지 않은 반정형 데이터를 다루는 데 강하다(ResolveChoice로 타입 충돌 해결 등).

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext
 
glueContext = GlueContext(SparkContext.getOrCreate())
 
# 카탈로그에서 읽기
dyf = glueContext.create_dynamic_frame.from_catalog(
    database="ml_datalake", table_name="raw_transactions"
)
 
# 결측치 제거 + 컬럼 선택 (정제)
cleaned = dyf.drop_nulls().select_fields(["customer_id", "amount", "ts"])
 
# Parquet으로 Curated 존에 쓰기 (파티셔닝)
glueContext.write_dynamic_frame.from_options(
    frame=cleaned,
    connection_type="s3",
    connection_options={
        "path": "s3://ml-datalake/curated/transactions/",
        "partitionKeys": ["year", "month"],
    },
    format="parquet",
)

Glue Job의 과금 단위는 DPU(Data Processing Unit) — 4 vCPU + 16GB 메모리 — 이고, 실행 시간에 비례한다. 서버리스라 클러스터 프로비저닝이 없다.

Glue ETL의 세 가지 실행 타입 — 데이터 크기가 선택을 가른다.

작은 데이터에 Spark Job을 쓰면 클러스터 시작 오버헤드 때문에 느리고 비싸다. 시험에서 "수 MB의 작은 변환"이면 Python Shell이 더 적합하다.

ETL(Extract-Transform-Load)과 ELT(Extract-Load-Transform)의 차이를 알아 둘 필요가 있다. 전통 ETL은 변환을 먼저 하고 데이터웨어하우스에 적재한다. 클라우드 데이터 레이크에서는 일단 Raw로 적재(Load)한 뒤 변환(Transform)하는 ELT가 흔하다. S3가 싸고, 컴퓨트를 분리할 수 있기 때문이다. Glue는 둘 다 지원하지만, 데이터 레이크 맥락에서는 ELT 패턴이 자주 쓰인다.

Glue DataBrew: 노코드 데이터 준비

데이터 사이언티스트가 Spark 코드를 쓰지 않고 시각적으로 데이터를 정제·변환하고 싶을 때 Glue DataBrew를 쓴다.

• 250개 이상의 사전 정의 변환: 결측치 처리, 이상치 제거, 원-핫 인코딩, 정규화, 날짜 파싱 등.
• 데이터 프로파일링: 컬럼별 분포, 결측 비율, 상관관계, 이상치를 자동 리포트.
• 레시피(recipe): 적용한 변환 단계를 저장해 재사용·스케줄링.
• 코드 없이 GUI로 작업하고, 결과를 S3에 출력.

DataBrew의 진짜 가치는 ML 전처리에서의 데이터 프로파일링이다. 모델을 만들기 전 "이 컬럼의 결측률이 40%다", "이 피처는 타깃과 상관이 0이다" 같은 사실을 코드 없이 빠르게 발견할 수 있다. 이는 Day 3에서 다룰 EDA(탐색적 데이터 분석)와 직결된다.

전체 그림: 수집 → 카탈로그 → 변환

S3 Raw 존 (JSON/CSV)
   │
   ├─ Glue Crawler ──→ Glue Data Catalog (스키마 등록)
   │                        │
   │                        └──> Athena / Redshift Spectrum / EMR / SageMaker 공유
   │
   ├─ Glue ETL Job ──→ 정제·변환 (DynamicFrame, Spark)
   │                     또는
   ├─ Glue DataBrew ──→ 노코드 정제·프로파일링
   │
   ▼
S3 Curated 존 (Parquet, 파티셔닝)
   │
   ▼
Athena / Redshift / SageMaker (Day 3, 학습)

도구 선택 요약

Glue 비용·성능을 결정하는 것들

Glue는 서버리스지만 공짜가 아니다. DPU 수 × 실행 시간이 요금이므로, 잘못 설정하면 조용히 비싸진다.

• 작은 데이터에 Spark Job을 쓰면 클러스터 기동 오버헤드가 실제 처리 시간보다 길어진다.
• 출력이 수만 개의 작은 파일로 쪼개지면 이후 Athena·학습 단계가 느려진다. 적정 크기로 합치는 것이 좋다.

Crawler 운영에서 자주 겪는 일

⚠️ 함정: 크롤러는 "한 번 돌리면 끝"이 아니다. 데이터가 계속 들어오는 레이크에서는 스케줄로 주기 실행하거나, 파티션만 늘어나는 경우 더 가벼운 수단으로 갈아타는 판단이 필요하다.

ETL 설계 체크리스트

다음 글에서는 이렇게 준비된 데이터를 Athena와 Redshift로 쿼리하고, EDA(탐색적 데이터 분석)의 기초를 본다.

📖 용어

• 데이터 카탈로그 : 어떤 테이블이 어디에 어떤 스키마로 있는지 적어둔 메타데이터 장부. 데이터 자체는 없다.
• Hive Metastore : 데이터와 스키마를 분리해 관리하는 고전적 메타데이터 저장소. Glue Catalog의 원형.
• schema-on-read : 저장할 땐 원본 그대로 두고 읽는 시점에 스키마를 입히는 방식. 데이터 레이크의 기본.
• Crawler : 저장소를 훑어 파일 포맷·컬럼·파티션을 추론하고 카탈로그에 테이블을 만들어주는 도구.
• SerDe : 파일의 바이트를 행·컬럼으로 읽고 쓰는 방법을 정의한 직렬화/역직렬화 규칙.
• DynamicFrame : Glue가 제공하는 데이터 구조. 스키마가 들쭉날쭉한 반정형 데이터를 다루는 데 강하다.
• DPU(Data Processing Unit) : Glue의 과금·성능 단위. 4 vCPU + 16GB 메모리 한 묶음.
• ETL vs ELT : 변환 후 적재냐, 적재 후 변환이냐. 클라우드 데이터 레이크는 보통 ELT를 쓴다.
• 레시피(recipe) : DataBrew에서 적용한 변환 단계를 저장해 재사용·스케줄링하는 단위.
• 파티션 프로젝션(partition projection) : 경로 규칙을 미리 정의해 파티션을 스캔 없이 계산하게 하는 설정.