Medallion Architecture란?

Medallion Architecture는 데이터 레이크 기반 환경에서 대용량 데이터를 계층적으로 정제하고 품질을 향상시키기 위한 설계 패턴이다.

Bronze → Silver → Gold 3계층으로 구성되며, 각각은 데이터 품질, 정제 수준, 활용 목적에 따라 명확히 분리된다.

이 구조는 다음과 같은 문제를 해결하기 위해 등장하였다:

• 원시 로그(raw log)를 직접 분석에 쓰기에는 품질, 구조, 오류 제어가 부족한 경우가 많음
• 정제된 데이터를 다양한 팀이나 파이프라인에서 재사용하기 어려움
• 데이터가 저장되었더라도, 어떤 품질 수준까지 처리되었는지 추적이 어려움

따라서 아래와 같은 목적에 적합하다:

• 데이터 레이크 기반의 분석 및 정제 파이프라인 구성
• 머신러닝 피처 추출/학습용 테이블 설계
• KPI, 리포트, 대시보드 등 비즈니스 활용을 위한 계층적 데이터 구조 설계

주로 Databricks 및 Apache Spark 기반의 Delta Lake 환경에서 사용되며,
Delta Lake의 ACID 트랜잭션, Time Travel, MERGE 기능은 Medallion 구조를 안정적으로 지원하는 핵심 기술 요소다.

---

1. Bronze / Silver / Gold 계층 설명

1.1 Bronze Layer: 원시 데이터 저장

• 목적: 수집된 데이터를 가공 없이 그대로 저장 (raw ingestion)
• 데이터 소스: Kafka, CDC 로그, 이벤트 스트림, API 등
• 특징
  • 스키마 제약 없음
  • 오류 데이터도 허용하여 로스리스 수집
  • 재처리 및 감사(log replay)를 위한 원본 보존

{
  "user_id": 123,
  "event": "click",
  "timestamp": "2023-07-01T12:00:00Z"
}

---

1.2 Silver Layer: 정제 및 표준화 계층

• 목적: 스키마 적용, 품질 검사, 참조 데이터 조인을 통해 의미 있는 분석 단위로 변환
• 처리 내용
  • 결측치 및 오류 처리
  • 조인 및 유효성 검증
  • 파싱, 포맷 정규화

SELECT 
  u.user_id, 
  u.gender, 
  e.event, 
  TO_TIMESTAMP(e.timestamp) AS event_time
FROM bronze.user_events e
JOIN silver.user_profiles u
  ON e.user_id = u.user_id
WHERE e.event IS NOT NULL

---

1.3 Gold Layer: 집계 및 비즈니스 모델

• 목적: KPI, 리포팅, 머신러닝 피처 등으로 활용 가능한 최종 형태 제공
• 처리 내용
  • 일/주/월 단위 집계
  • 피벗, KPI 산출
  • 피처 엔지니어링

SELECT 
  user_id,
  COUNT(*) AS total_clicks,
  COUNT(DISTINCT DATE(event_time)) AS active_days
FROM silver.cleaned_user_events
GROUP BY user_id

---

2. 계층 구조와 SQL 네이밍의 관계

Medallion Architecture에서 사용하는 Bronze / Silver / Gold 계층은
실제 구현 시 테이블이나 디렉터리의 논리적 네임스페이스(schema) 또는 디렉토리 prefix로 사용되는 것이 일반적이다.

예제에서 사용한 silver.user_profiles, bronze.user_events 같은 테이블 명은
실제로는 아래와 같은 의미로 쓰이며, 각 계층을 명확히 식별할 수 있도록 도와준다.

---

2.1 테이블/디렉터리 네이밍 예시

• bronze.user_events → Bronze 계층에 저장된 원시 이벤트 로그 테이블
• silver.user_profiles → Silver 계층의 정제된 사용자 프로필 데이터
• gold.kpi_metrics → Gold 계층의 KPI 집계 결과 테이블

이는 단지 명명 규칙(naming convention)일 뿐이며, 물리적으로 강제되는 것은 아니다.
하지만 계층별 데이터 품질 수준을 명확히 관리하고, 유지보수 및 관측성을 높이기 위한 실무적 표준으로 널리 사용된다.

---

2.2 디렉터리 기반 구조 예시

데이터 레이크에서의 저장 구조 예시:

/datalake
  ├─ /bronze
  │   └─ user_events.parquet
  ├─ /silver
  │   └─ cleaned_user_events.parquet
  └─ /gold
      └─ kpi_daily_metrics.parquet

SQL 처리 엔진(Spark, Databricks 등)에서는 디렉터리를 테이블로 매핑하거나,
스키마 단위(bronze, silver, gold)로 카탈로그를 구성하여 다음과 같이 쿼리할 수 있다:

SELECT * FROM silver.cleaned_user_events

---

2.3 논리적 계층과 SQL 예제 관계 요약

표현	의미	Medallion 계층
bronze.user_events	원시 로그 저장 테이블 (raw ingestion)	🟫 Bronze
silver.user_profiles	정제된 사용자 프로필 데이터	🥈 Silver
gold.kpi_metrics	집계된 KPI 리포팅 테이블	🥇 Gold

이처럼 SQL 예제에서 사용된 bronze. 또는 silver. 접두어는 Medallion Architecture의 계층 구조를 반영한 명명 관례고,
Delta Lake 기반의 실무 파이프라인에서 자주 사용된다.

---

📌 실제 구현 팁

• 디렉터리 구조, DB schema, catalog naming을 계층 기준으로 나누면 관리가 쉬움
• 계층별로 다른 권한, 다른 스토리지 정책, 다른 거버넌스를 적용할 수 있음
• silver → gold로 갈수록 품질, 의미, SLA가 높아지는 구조로 설계해야 유지보수와 협업이 쉬움

---

3. Delta Lake 기반 구현 전략

3.1. Delta Format

• Apache Parquet 기반에 ACID 트랜잭션, 버전 관리, 머지 지원 기능을 추가한 포맷
• 동시성 제어, 스키마 검증이 가능

---

3.2. 핵심 기능

기능	설명
Time Travel	특정 시점의 데이터를 조회 (버전 관리)
Schema Enforcement	컬럼 타입, 필드 누락 등 스키마 오류 방지
MERGE (UPSERT)	조건 기반 데이터 병합 (CDC, SCD 처리)

---

3.3. 예시: CDC 기반 UPSERT

MERGE INTO silver.customers AS target
USING bronze.customer_cdc AS source
ON target.customer_id = source.customer_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

---

3.4. 예시: Time Travel

SELECT * 
FROM silver.transactions
VERSION AS OF 10