[analytics] AWS Glue
여기저기 흩어진 데이터를 긁어모아 형태를 맞추는 지겨운 작업. 서버 없이 자동으로 처리하는 Glue ETL.
One-Line Summary
Glue는 서버 없이 데이터를 추출·변환·적재(ETL) 하고, 데이터가 어디에 어떤 스키마로 있는지 중앙 카탈로그(Data Catalog) 로 관리해주는 완전관리형 서비스다. 시험에서는 서버리스 ETL / 스키마 자동 발견(Crawler) / Data Catalog가 Athena·Redshift Spectrum·EMR의 공용 메타데이터 라는 점이 핵심이다. "ETL인데 클러스터 운영은 싫다"면 Glue다.
Why It Exists
데이터 레이크(S3)에 파일이 쌓여도, 그 데이터의 스키마(컬럼·타입)를 알고, 정제·변환해 분석 가능한 형태로 만드는 작업(ETL) 이 필요하다. 이를 위해 Spark 클러스터를 직접 세우고 스키마를 손으로 정의하는 건 부담이 크다.
Glue는 스키마 발견과 ETL을 서버리스로 대신한다.
S3의 원시 데이터
-> Glue Crawler가 스캔 -> 스키마 추론 -> Glue Data Catalog에 테이블 등록
-> Glue ETL Job(Spark)이 정제·변환 -> S3/Redshift 등으로 적재
-> Athena/Redshift Spectrum/EMR가 Data Catalog를 보고 바로 쿼리
시험 감각:
"서버리스 ETL / 데이터 카탈로그 / 스키마 자동 발견" = Glue.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
ETL | Extract, Transform, Load | 데이터를 추출·변환·적재하는 과정 |
Data Catalog | Glue Data Catalog | 테이블·스키마 메타데이터를 담는 중앙 저장소 |
Crawler | Glue Crawler | 데이터 소스를 스캔해 스키마를 추론하고 카탈로그에 등록 |
Glue Job | Glue ETL Job | Spark/Python으로 데이터를 변환하는 서버리스 작업 |
Glue Studio | Glue Studio | ETL 잡을 시각적으로 만드는 인터페이스 |
Glue Data Catalog — 왜 중요한가 (빈출)
Data Catalog는 "어떤 데이터가 어디에 어떤 스키마로 있는지" 를 담은 중앙 메타데이터 저장소다. 핵심은 이걸 여러 분석 서비스가 공유한다는 점이다.
| 사용 서비스 | 활용 |
|---|---|
| Athena | 카탈로그의 테이블 정의로 S3를 SQL 쿼리 |
| Redshift Spectrum | 카탈로그를 참조해 S3 데이터를 조회 |
| EMR | Hive metastore 대체로 카탈로그 사용 |
시험 감각:
"여러 분석 서비스가 공용으로 쓸 스키마/메타데이터 저장소" = Glue Data Catalog.
Crawler — 스키마 자동 발견
Crawler는 S3·RDS·DynamoDB 등을 스캔해 컬럼·타입·파티션을 자동 추론하고 카탈로그에 테이블로 등록한다. 스키마를 손으로 정의할 필요가 없다.
반정형 로그(JSON/CSV) in S3
-> Crawler 실행 -> 컬럼/타입/파티션 자동 인식 -> Catalog 테이블 생성/갱신
시험 감각:
"스키마를 모르는/자주 바뀌는 데이터를 자동으로 카탈로그화" = Crawler.
Glue vs EMR (핵심 비교, 빈출)
| 구분 | Glue | EMR |
|---|---|---|
| 모델 | 서버리스 ETL (클러스터 관리 없음) | 관리형 클러스터(Hadoop/Spark), 노드 관리 필요 |
| 운영 부담 | 최소 | 상대적으로 큼(세밀한 제어 가능) |
| 적합 | 간헐적/이벤트성 ETL, 카탈로그 중심 | 대규모·지속적 빅데이터 처리, 프레임워크 세밀 제어 |
| 비용 통제 | 사용한 만큼(잡 실행 시간) | Spot/트랜지언트 클러스터로 최적화 |
시험 감각:
"운영 최소·서버리스 ETL" = Glue. "대규모·Hadoop 생태계·클러스터 제어" = EMR.
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 서버리스 ETL이면 되는데 EMR 클러스터 구축 | 운영 부담 큼 → 간헐적/이벤트성 ETL은 Glue |
| S3를 SQL로 조회하려고 Glue Job 작성 | 조회는 Athena(Glue는 카탈로그/ETL 담당) |
| 스키마를 직접 다 정의 | Crawler로 자동 발견 가능 |
| 실시간 스트림 처리를 Glue 배치로 | 실시간은 Flink(Glue는 배치 ETL 성격) |
| 메타데이터 저장소를 서비스마다 따로 | Data Catalog 하나로 공유 |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "serverless ETL / no infrastructure to manage" | Glue |
| "central metadata / data catalog for analytics" | Glue Data Catalog |
| "automatically discover schema / crawl data" | Glue Crawler |
| "prepare/transform data in a data lake" | Glue ETL Job |
| "shared schema for Athena and Redshift Spectrum" | Glue Data Catalog |
| "large-scale Hadoop/Spark with cluster control" | Glue 아님 → EMR |
Memory Sentence
Glue는 서버리스 ETL + 중앙 Data Catalog다. Crawler가 스키마를 자동 발견해 카탈로그에 올리고, Athena·Redshift Spectrum·EMR이 그 카탈로그를 공유한다. 운영 최소·간헐적 ETL이면 Glue, 대규모·클러스터 제어가 필요하면 EMR.
References
댓글
아직 댓글이 없습니다.