데이터가 많아질수록 "이 데이터가 어디 있지? 어떤 형식이었지?"라는 질문이 자주 생깁니다. 수만 개의 파일이 S3에 흩어져 있을 때 매번 직접 열어보는 것은 불가능합니다. AWS Glue Data Catalog는 이 문제를 해결하는 중앙 메타데이터 저장소입니다. 실제 데이터를 복사하는 것이 아니라, 데이터에 대한 정보(메타데이터)만 모아두는 일종의 데이터 지도입니다. DEA-C01 시험에서 카탈로그 관련 문제는 "데이터를 어떻게 찾고 관리하는가"를 묻는 핵심 영역입니다.
Glue Data Catalog란 무엇인가
도서관을 생각해보세요. 책이 수만 권 있어도 색인 카드가 있으면 어떤 책이 어느 책장 몇 번째 칸에 있는지 즉시 찾을 수 있습니다. Glue Data Catalog가 바로 이 색인 카드 역할을 합니다.
Glue Data Catalog는 실제 데이터(S3의 파일들)를 움직이지 않습니다. 대신 다음 정보를 기록합니다.
데이터가 어디에 있는가 (S3 경로, RDS 엔드포인트 등) 데이터가 어떤 형식인가 (CSV, Parquet, JSON 등) 어떤 열(컬럼)이 있고 각 열의 데이터 타입은 무엇인가 파티션은 어떻게 나뉘어 있는가
이 정보를 메타데이터라고 부릅니다. 카탈로그는 메타데이터만 저장하고, 실제 데이터는 원래 위치에 그대로 있습니다.
데이터베이스와 테이블 개념
Glue Data Catalog 안의 구조는 전통적인 데이터베이스와 비슷하게 생겼습니다.
데이터베이스는 관련 테이블들을 묶는 논리적 그룹입니다. 예를 들어 "sales_db"라는 데이터베이스 안에 "orders", "customers", "products" 같은 테이블들을 넣을 수 있습니다.
테이블은 실제 데이터의 스키마(구조)와 위치를 정의합니다. 테이블 정의에는 다음이 포함됩니다.
| 항목 | 예시 | 역할 | |------|------|------| | 위치 | s3://my-bucket/orders/ | 실제 데이터 파일이 있는 S3 경로 | | 형식 | Parquet | 파일 포맷 | | 컬럼 | order_id (int), amount (double) | 열 이름과 타입 | | 파티션 키 | year, month | 데이터 분할 기준 |
중요한 점은 이 테이블이 "가상 테이블"이라는 것입니다. 실제로 데이터를 담고 있지 않고, 데이터가 어디에 어떻게 있는지를 설명하는 정의서입니다.
Athena, Redshift Spectrum, EMR과의 통합
Glue Data Catalog의 가장 큰 장점은 여러 서비스가 같은 메타데이터를 공유한다는 것입니다. 마치 도서관의 색인 카드를 여러 사람이 동시에 볼 수 있는 것처럼요.
예를 들어 S3에 저장된 주문 데이터를 분석하고 싶다면:
Athena: SQL 쿼리로 즉시 분석 (서버리스, 추가 설정 없음) Redshift Spectrum: Redshift에서 외부 테이블로 S3 데이터 조회 EMR: Spark나 Hive로 대규모 처리
세 서비스 모두 Glue Data Catalog의 같은 테이블 정의를 바라봅니다. 한 번 카탈로그에 등록하면 어느 서비스에서든 동일한 스키마 정보를 활용할 수 있습니다. 같은 데이터를 세 번 등록할 필요가 없습니다.
Glue 크롤러 — 자동 탐정
카탈로그에 메타데이터를 직접 입력하는 것은 번거롭습니다. 특히 파일이 매일 새로 쌓이거나 스키마가 바뀌는 경우에는 더욱 그렇습니다. Glue 크롤러는 이 작업을 자동화합니다.
크롤러는 데이터 소스를 스스로 탐색하는 자동 탐정입니다. S3 버킷, RDS 데이터베이스, DynamoDB 테이블 등을 지정하면 크롤러가 알아서 들어가 스키마를 파악하고 카탈로그에 등록합니다.
크롤러의 주요 기능:
스케줄 실행: 매시간, 매일, 매주처럼 정기적으로 크롤링을 예약할 수 있습니다. 새로 추가된 데이터나 변경된 스키마를 자동으로 감지합니다. 분류자(Classifier): 파일을 보고 어떤 형식인지 자동으로 판별합니다. CSV인지 JSON인지 Parquet인지 사람이 알려주지 않아도 됩니다. 기본 분류자로 처리 안 되는 형식은 커스텀 분류자를 만들 수 있습니다. 파티션 감지: S3 폴더 구조가 year=2026/month=03/day=15처럼 되어 있으면 크롤러가 이를 자동으로 파티션으로 인식하고 카탈로그에 등록합니다.
크롤러 실행 흐름을 단계별로 보면:
지정된 S3 경로(또는 다른 소스)를 스캔 파일 형식과 구조 파악 (분류자 사용) 기존 카탈로그 테이블과 비교 새 테이블이면 생성, 기존 테이블이면 스키마 변경 사항 업데이트 새 파티션이 있으면 카탈로그에 추가
파티션 동기화 — 세 가지 방법
파티션이란 데이터를 특정 기준으로 나눠 저장하는 방식입니다. 예를 들어 로그 데이터를 날짜별 폴더에 저장하면 특정 날짜의 데이터만 빠르게 읽을 수 있습니다.
문제는 S3에 새 파티션 폴더가 생겨도 카탈로그가 자동으로 알지 못한다는 것입니다. 누군가 카탈로그에 "이 새 폴더도 데이터야"라고 알려줘야 합니다. 이것이 파티션 동기화입니다.
방법 1 — 크롤러 재실행: 가장 간단한 방법입니다. 크롤러를 다시 돌리면 새 파티션을 감지해서 카탈로그에 추가합니다. 하지만 크롤러가 전체 소스를 다시 스캔하므로 시간이 걸립니다. 파티션이 드물게 추가되는 환경에 적합합니다.
방법 2 — MSCK REPAIR TABLE: Athena에서 실행하는 SQL 명령어입니다.
Hive 호환 방식(key=value 폴더 구조)으로 파티션이 저장된 경우 이 명령어 하나로 새 파티션을 카탈로그에 동기화할 수 있습니다. 크롤러보다 빠르고 간단하지만, Hive 형식 폴더 구조가 아니면 작동하지 않습니다.
방법 3 — BatchCreatePartition API: Glue API를 코드로 직접 호출하는 방법입니다. 파티션 정보를 직접 지정해서 카탈로그에 한꺼번에 추가합니다. 속도가 가장 빠르고, 매시간 수천 개의 새 파티션이 생기는 대용량 환경에 적합합니다. Lambda 함수나 Glue 작업에서 자동화할 수 있습니다.
| 방법 | 속도 | 적합한 상황 | |------|------|------------| | 크롤러 재실행 | 느림 | 파티션 추가가 드문 경우 | | MSCK REPAIR TABLE | 중간 | Hive 형식, 수동 동기화 | | BatchCreatePartition API | 빠름 | 대량 파티션이 자주 추가되는 경우 |
Hive 메타스토어 대체
EMR(Elastic MapReduce)은 오픈소스 Hadoop/Spark 기반 서비스입니다. 전통적으로 EMR은 자체 Hive 메타스토어를 사용해 스키마 정보를 관리했습니다. 문제는 EMR 클러스터를 종료하면 이 메타스토어 정보도 사라진다는 것입니다.
Glue Data Catalog를 EMR의 Hive 메타스토어로 대체하면 다음 장점이 생깁니다.
클러스터를 종료해도 메타데이터가 유지됩니다 EMR, Athena, Redshift Spectrum이 모두 같은 메타데이터를 공유합니다 각 서비스에서 따로 테이블을 등록할 필요가 없습니다
설정은 EMR 클러스터 생성 시 "Glue Data Catalog를 메타스토어로 사용" 옵션을 켜면 됩니다. 이후 Hive나 Spark SQL에서 테이블을 만들면 자동으로 Glue 카탈로그에 등록됩니다.
시험 핵심 정리
"중앙 메타데이터 저장소가 필요하다" → Glue Data Catalog "데이터 스키마를 자동으로 발견하고 등록" → Glue 크롤러 "S3 새 파티션을 빠르게 대량으로 등록" → BatchCreatePartition API "Athena에서 수동으로 파티션 동기화" → MSCK REPAIR TABLE "EMR과 Athena가 같은 메타데이터를 공유" → Glue Data Catalog를 Hive 메타스토어로 사용 "파일 형식을 자동으로 판별" → 크롤러 분류자(Classifier) 카탈로그는 데이터 자체가 아닌 메타데이터(위치, 스키마, 파티션 정보)만 저장함