Medallion Architecture - 1 — Bronze

 

데이터 레이크의 표준 데이터 품질 관리 패턴. Raw Data(Bronze) → 정제(Silver) → 비즈니스 분석(Gold) 3단계로 데이터를 단계적으로 가공하여 품질과 활용도를 높이는 구조

---

1. Medallion Architecture 개요

데이터 레이크에서 데이터의 품질을 단계적으로 관리하는 표준 패턴.

단계	의미	뉘앙스
Bronze	원천 데이터(원본) 적재	무슨 일이 일어났는가?
Silver	정제/표준화된 데이터	누가, 언제, 무엇을 구매했는가?
Gold	비즈니스/분석용 집계 데이터	이번 시간 매출은 얼마인가?

---

2. 각 단계별 데이터 변화 형태

2.1 Bronze 단계 (Raw Data)

원본(오리지널) 데이터의 형태를 보존하는 단계.

• 파이프라인: 데이터 생성기(발생) → Kinesis → Firehose → S3
• 데이터 형태: 직렬화되어 문자열 형태로 보관 (압축 형태도 가능)
• 포맷: JSON, Parquet. 통상 지저분하고 분석하기 어려운 상태로 들어있음

2.2 Silver 단계 (Clean + Enriched)

데이터 클리닝과 질 향상을 수행하는 단계.

• 배치 처리: Airflow + Athena — 스케줄을 통해 주기성을 가지고 배치 작업 진행. 데이터를 모아두고 특정 시간 단위로 한 번에 처리
• 실시간 처리: Flink, Lambda — 지연시간을 최소화하여 처리. 파이프라인을 직접 연계하는 것이 적절
• 빅데이터 처리: 데이터 규모(테라바이트 이상)에 따라 Airflow + EMR with pySpark — 클러스터에서 분산 구조로 처리

데이터 목표:

• 데이터 클리닝, 필요 정보로 구성
• 불필요한 메타 정보 제거
• 필요 시 계산된 데이터 추가 (파생 컬럼/변수)
• 필요 시 포맷을 Parquet으로 구성하여 열 기반 검색이 편리하게 변경
• 쿼리가 가능한 정제된 테이블 형태로 구성

2.3 Gold 단계 (비즈니스 연계)

특수 목적의 비즈니스 활용을 위한 최종 단계.

• 대시보드용 데이터 구성: 데이터 기반 분석한 대시보드용 데이터 구성 (DS의 작업과 연계)
• 보안/관제용 데이터 구성: 보안/관제에 필요한 대시보드용 데이터 구성
• AI용 데이터 구성: ML/DL/LLM 등에 사용되는 학습용, 검색증강용 데이터 구성 (MLOps, AIOps 연계하여 파이프라인 구성)

사용 서비스:

• Airflow + Athena
• Airflow + OpenSearch → ELK 연계

데이터 상태: 최종 목적에 사용 가능한 형태. 분석이면 의사결정이 되는 수준, AI라면 학습이 가능한 형태.

---

3. 데이터베이스 구성

각 단계별 데이터와 연계되는 데이터베이스를 물리적으로 분리하여 구성.

-- Athena 쿼리 편집기에서 데이터베이스 생성
-- 한 번에 한 개 쿼리만 수행 가능
CREATE DATABASE IF NOT EXISTS de_ai_04_ma_bronze_db;
CREATE DATABASE IF NOT EXISTS de_ai_04_ma_sliver_db;
CREATE DATABASE IF NOT EXISTS de_ai_04_ma_gold_db;

DB 분리의 이점

• 보안: 필요 시 읽기 권한만 부여하거나 접근 자체를 차단 가능 (예: DA, DS에게 Bronze 접근 차단)
• 가독성: 테이블이 많아질 경우 단계별로 분리되어 있어 관리가 용이
• 휴먼 에러 방지: 잘못된 DB에 접근하여 데이터를 삭제하는 등의 실수를 사전에 방지

---

4. Bronze Layer 구현

4.1 목표 및 구조

Raw Data를 보관하는 역할. 데이터가 Flink, Lambda, Airflow+Athena에 전달되기 전 원시적인 데이터 상태.

파이프라인:

데이터 생성기 → Kinesis Data Stream → Firehose → S3

4.2 장점

1. 원본 데이터 백업: Kinesis에서 Flink로 바로 연결하면 Flink 이슈로 데이터를 가져가지 못했을 시 최대 24시간 보관 후 Kinesis에서 삭제 처리됨. S3에 보관하면 이 위험을 제거할 수 있음
2. 비용 절감: S3의 비용 체계는 파일 개수당 비용 청구. 천 개의 파일보다 천 개의 내용을 한 개로 묶어서 파일 한 개로 저장하는 것이 이득. Flink/Athena가 데이터를 가져올 때 I/O가 한 번 발생하느냐, 천 번 발생하느냐의 차이. 내부적으로 API 호출 비용을 감소시킬 수 있음 (이래서 Firehose를 쓰는 것)
3. Small File Problem 해결: 파일을 뭉쳐놓으면 분석 시 Athena, Spark 같은 도구에서 스캔 효율이 극대화됨
4. 압축 효율 극대화: Firehose에서 지정 가능. GZIP(압축 효율 극대화), Snappy(처리 속도 극대화). 스트리밍 용량을 아낄 수 있음
5. 관리 효율성: 파티셔닝(yyyy/mm/dd/hh) 등 데이터를 파티션으로 나눠서 관리 가능. 검색 속도 증가

4.3 단점

1. 실시간성 저하 (Latency 증가): Firehose 구조상 버퍼링의 양/시간을 설정해야 하기 때문에 실시간성이 저하될 수밖에 없음
2. 중복 데이터 발생 가능성: 네트워크 지연, 장애로 인한 재전송 문제가 발생할 수 있음
3. Silver 단계에서 반드시 중복 제거 로직이 필요함

4.4 결론

원데이터는 S3에 적재되며 S3가 Bronze Layer가 됨.

---

5. Firehose 구성 목표

항목	설정값	근거
버퍼 Size	64~128 MiB	Athena 최적화 크기
버퍼 Interval	60~300초	비즈니스 허용 시간 고려
Compression	GZIP 또는 Snappy	GZIP=압축 효율, Snappy=처리 속도
S3 Prefix	파티션 경로 설정	물리적 파티션 구성

S3 Prefix (물리적 파티션)

bronze/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/

파티션 구분

• 물리적 파티션: S3 Prefix — 실제 S3 경로를 년/월/일/시 단위로 분리
• 논리적 파티션: Glue Partition — Athena가 SQL 쿼리 시 인식하는 파티션 키 (year, month, day, hour)
• 두 가지를 함께 설정해야 Athena 최적 성능 달성

---

6. Bronze Layer 구현 절차

Step 1. 데이터 생성기

VSCode에서 multi_process_data_gen.py 실행.

Step 2. Kinesis 구성

• 스트림명: de-ai-04-ap2-kdf-medallion-bronze-stream

Step 3. Firehose 구성

• 스트림명: de-ai-04-an2-adf-medallion-bronze-stream
• Kinesis 소스 연결, S3 대상 설정
• 레코드 형식 변환: Parquet
• AWS Glue 리전: 서울, 데이터베이스: de_ai_04_ma_bronze_db

Glue 테이블 스키마:

[
  { "Name": "event_id",     "Type": "string" },
  { "Name": "event_time",   "Type": "timestamp" },
  { "Name": "source_ip",    "Type": "string" },
  { "Name": "user_agent",   "Type": "string" },
  { "Name": "data",         "Type": "string" },
  { "Name": "ingested_at",  "Type": "timestamp" }
]

논리적 파티션 추가:

Add 버튼 → set as a partition key 클릭 → year, month, day, hour 4개 추가.

S3 설정:

• 버킷: s3://de-ai-04-827913617635-ap-northeast-2-an
• 접두사: medallion/bronze/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/
• 오류 접두사: medallion/bronze/err/

Step 4. S3 확인

• 버킷/medallion/bronze/ 하위로 데이터가 세팅되는지 확인
• 버퍼 크기(128MiB)보다 데이터가 많이 쌓였거나 300초 이후에 저장됨

---

요약

항목	내용
Medallion Architecture	Bronze → Silver → Gold 3단계 데이터 품질 관리 패턴
Bronze	Raw Data 보관. Firehose → S3. 원본 백업 + Small File Problem 해결
Silver	데이터 클리닝/정제. Airflow+Athena(배치) 또는 Flink(실시간)
Gold	비즈니스 분석용 최종 데이터. 대시보드, AI 학습용 등
DB 분리	단계별 DB를 물리적으로 분리하여 보안/가독성/휴먼에러 방지
물리적 파티션	S3 Prefix로 yyyy/MM/dd/HH 경로 분리
논리적 파티션	Glue Partition으로 Athena SQL 쿼리 시 파티션 인식
Firehose 핵심 역할	버퍼링(Small File 방지) + 압축 + 자동 파티셔닝 + 포맷 변환(Parquet)

Medallion Architecture는 데이터 레이크에서 데이터 품질을 단계적으로 관리하는 표준 패턴. Bronze(S3 원본 보관) → Silver(정제/표준화) → Gold(비즈니스 분석) 구조로, 각 단계를 DB로 물리적 분리하여 보안과 운영 효율성을 확보하는 구조