341. 스키마 온 리드 (Schema-on-read) - 데이터 레이크/NoSQL의 조회 시점 스키마 적용

💡 핵심 인사이트 스키마 온 리드(Schema-on-Read)는 "데이터를 원본 그대로 저장하고, 데이터를 읽거나 분석하는 시점에 스키마를 적용하는" 접근 방식입니다. 스키마 온 라이트가 데이터를 저장할 때 **사전에 구조를 검증**한다면, 스키마 온 리드는 데이터를 **그냥 저장하고, 나중에 읽을 때 구조를 정의**합니다. 이는 "다양하고 예측 불가능한 데이터 소스를 빠르게 수집"하면서, "분석 시점에 필요한 형태대로 데이터를 해석"할 수 있게 해줍니다. 그러나 **데이터 품질 관리가 부실하면 데이터 늪(Data Swamp)이 될 위험**이 있습니다.

Ⅰ. 스키마 온 리드의 탄생 배경:大数据의 도래

전통적인 스키마 온 라이트(Schema-on-Write) 방식은 **저장 시점에 스키마가 완전히 정의**되어야 합니다. 그러나 현대 기업은 다음과 같은 도전에 직면합니다:

SNS, IoT 센서, 웹 로그 등 비정형/반정형 데이터의 폭발적 증가
데이터 수집 전에 분석 방식을 알 수 없는未知의 데이터
새로운 데이터 소스가 빠르게 등장하고 사라지는 환경
데이터 과학가의 ad-hoc 분석 및 ML 모델 실험 환경

스키마 온 리드는 이러한 불확실성과 다양성에 대응하기 위해 탄생했습니다.

[스키마 온 리드의 처리 흐름]

데이터 소스 (다양한 형태)
  │
  ├── JSON 로그 ─────────────────────┐
  ├── CSV 파일 ──────────────────────┼── 원시 그대로 저장
  ├── 이미지 ────────────────────────┼── (ETL/변환 없음)
  ├── 센서 타임시리즈 ────────────────┤
  └── 마이크로서비스 이벤트 ──────────┘
           │
           ▼
┌─────────────────────────────────────┐
│     원시 데이터 Pool (저장소)          │
│     - S3, GCS, Azure Blob 등        │
│     - 파일 형태 그대로 저장            │
│     /Raw/weblogs/2024/01/access.log │
│     /Raw/iot/sensor_2024.parquet    │
│     /Raw/crm/export_2024.json       │
└─────────────────────────────────────┘
           │
           │ 분석/읽기 시점에 스키마 적용
           ▼
┌─────────────────────────────────────┐
│     분석 도구별 다양한 스키마 적용       │
│                                     │
│  [Python/Pandas]                    │
│  df = pd.read_parquet('/Raw/...')  │
│  df['timestamp'] = pd.to_datetime()│
│                                     │
│  [Spark]                            │
│  df = spark.read.json('/Raw/...')  │
│  df.select('id', 'value', ...)     │
│                                     │
│  [BI 도구]                          │
│  SELECT * FROM raw_data             │
│  WHERE CAST(json::timestamp ...)    │
└─────────────────────────────────────┘

Ⅱ. 스키마 온 리드의 핵심 메커니즘: 유연한 데이터 저장과 해석

스키마 온 리드에서 데이터는 형태 그대로 저장됩니다. 여기서 "형태 그대로"의 의미는:

저장 시점:

데이터의 원본 포맷(JSON, CSV, Parquet, Avro, 이미지 등)을 그대로 유지
어떤 스키마 변환이나 검증도 수행하지 않음
데이터를 파일을为单位로 객체 스토리지에 저장
메타데이터(파일명, 생성 시간, 크기 등)만 인덱싱

읽기 시점:

분석가 또는 애플리케이션이 스키마를 정의
해당 스키마에 맞춰 데이터를 파싱/변환
필요에 따라 여러 스키마를同一 데이터에 적용 가능

[스키마 온 리드의 유연성 예시]

원시 JSON 데이터:
{
  "event": "purchase",
  "user_id": "U12345",
  "timestamp": "2024-01-15T10:30:00Z",
  "items": [
    {"product": "laptop", "qty": 1, "price": 1500},
    {"product": "mouse", "qty": 2, "price": 25}
  ],
  "metadata": {"browser": "Chrome", "ip": "192.168.1.1"}
}

스키마 A (마케팅 분석용):
┌──────────┬──────────┬──────────────┐
│ user_id  │ 시간(일)  │ total_amount │
├──────────┼──────────┼──────────────┤
│ U12345   │ 20240115 │ 1550         │
└──────────┴──────────┴──────────────┘

스키마 B (제품 분석용):
┌──────────┬──────────┬──────┐
│ product  │ quantity │ user │
├──────────┼──────────┼──────┤
│ laptop   │ 1        │ U123│
│ mouse    │ 2        │ U123│
└──────────┴──────────┴──────┘

스키마 C (기술 로그 분석용):
┌──────────┬──────────────┐
│ user_id  │ browser      │
├──────────┼──────────────┤
│ U12345   │ Chrome       │
└──────────┴──────────────┘

→ 동일 원본 데이터에서 다양한 스키마로 분석 가능

Ⅲ. 스키마 온 리드를 지원하는 데이터 포맷

스키마 온 리드는 특정 데이터 포맷과 기술을 활용합니다.

반정형 데이터 포맷:

1. Apache Parquet

칼럼 기반(columnar) 저장 포맷
자체 스키마를 내장(Schema-on-Read，支持嵌套数据结构)
압축 효율이 높고,列単位 필터링에 최적
분석 환경(Apache Spark, Hive, Presto 등)에서 널리 사용

2. Apache Avro

로우 기반(row-based) 직렬화 포맷
데이터와 함께 스키마가 저장(Protobuf보다 유연)
바이너리 형식으로 효율적
Kafka 등에서 메시지 직렬화로 주로 사용

3. JSON / JSON Lines

반정형 데이터의 대표 포맷
인간이 읽기 쉬우며, 웹 API에서 표준
JSON Lines(NDJSON): 한 줄에 하나의 JSON 오브젝트
스키마 검증이 필요하면 JSON Schema 별도 적용

[Parquet vs JSON 비교]

Parquet (列指向, 分析에 유리):
┌─────────────────────────────────────────────┐
│ name ┌──────┐ age ┌──────┐ country ┌──────┐│
│ Tom  │ 1001 │  28 │ 1002 │ USA     │ 1003 ││
│ Jane │ 1004 │  35 │ 1006 │ Korea   │ 1008 ││
└─────────────────────────────────────────────┘
  → 특정 열(age)만 읽을 때 I/O 절약

JSON (行指向,灵活性에 유리):
{"name": "Tom", "age": 28, "country": "USA"}
{"name": "Jane", "age": 35, "country": "Korea"}
{"name": "Bob", "country": "USA"}
  → 필드가 누락될 수 있음 (age: undefined)

Ⅳ. 스키마 온 리드의 장점과 단점

장점:

1.极高的 유연성 데이터 소스나 분석 방식이 사전 정의되지 않아도 됩니다. "모르겠어, 일단 다 수집해두자"가 가능합니다. 새로운 데이터 소스 추가는 단순히 파일을 추가하는 것으로完了.

2. 빠른 데이터 수집 ETL/변환 과정이 없으므로, **저장소에 그대로 적재**만 하면 됩니다. 이는 데이터 수집 속도를 극적으로 빠르게 합니다.

3. 다양한 분석 가능 同一 데이터에 대해 여러 스키마를 적용하여 다양한 관점에서 분석할 수 있습니다. "마케팅용으로 한번, 기술 분석용으로 한번"도 가능합니다.

4. 반정형/비정형 데이터 친화적 JSON, 이미지, 로그 등의 사전 구조화하기 어려운 데이터를 있는 그대로 저장할 수 있습니다.

단점:

1. 데이터 품질 위험 저장 시 검증이 없으므로, **잘못된 데이터도 그대로 저장**됩니다. "유효하지 않은 이메일, 음수인 수량, NULL인 필수 필드"가 쌓일 수 있습니다.

2. 데이터 늪(Data Swamp) 위험 관리되지 않으면, 어떤 데이터가 있는지조차 알기 어려운 상황이 발생할 수 있습니다. 메타데이터 카탈로그 없이는 데이터 발견(Data Discovery)이 매우 어렵습니다.

3. 읽기 시 처리 부담 분석할 때마다 **데이터 파싱과 스키마 매핑**을 수행해야 하므로, 저장소에서 데이터를 읽는 시점의 오버헤드가 증가합니다.

4. 성능 최적화 어려움 저장 시점에 데이터 구조를 알지 못하므로, 어떤 인덱스나 압축을 적용해야 할지 결정하기 어렵습니다.

Ⅴ. 스키마 온 리드의 실제 적용과 📢 비유

주요 적용 환경:

데이터 레이크: AWS S3 + Lake Formation, Azure Data Lake Storage, Google Cloud Dataplex
반정형数据分析: Apache Spark, Databricks, Presto/Trino
이벤트 스트리밍: Apache Kafka + Schema Registry (적용 시점에서는 스키마 온 리드)

데이터 레이크에서의 스키마 온 리드: 데이터 레이크에서 스키마 온 리드를 효과적으로 사용하려면 메타데이터 카탈로그가 필수적입니다.

AWS Glue Data Catalog: S3에 저장된 Parquet/JSON 파일의 스키마를 자동으로 추출하고 인덱싱
Apache Hive Metastore: Hadoop 환경에서 데이터의 스키마와 위치 정보를 중앙 관리
DataHub, Amundsen: 메타데이터 검색과 데이터 계보(Lineage) 추적 지원

스키마 진화(Schema Evolution): 데이터 구조가 시간이 지나며 변경될 때(_v1 → v2), 스키마 온 리드는 이 변경을 유연하게 처리합니다. Parquet는 새 필드 추가, nullable 필드 처리 등을 지원하여, "기존 분석을 깨뜨리지 않으면서 새로운 필드 활용"이 가능합니다.

📢 섹션 요약 비유: 스키마 온 리드는 **"음식 저장소에 비유"**할 수 있습니다. 스키마 온 라이트가 "음식을 납품받을 때마다 영양 성분, 재료, 유통 기한을事前 검증하고, 검증된 것만 창고에 넣는" 것이라면, 스키마 온 리드는 "음식을 일단 냉동고에 통째로 넣고, 요리할 때마다 필요한 재료를 그때그때 꺼내서 사용하는" 것입니다. 매우 유연하지만, "무슨 재료가 있는지조차 잊어버리거나, 상한 재료를 발견하지 못할" 위험이 있습니다. 따라서 음식을入れる前に (카탈로그에) "무슨食材가 있는지, 어디에 있는지"를 반드시 기록해두어야 합니다. 이것이 데이터 레이크에서 메타데이터 카탈로그가 중요한 이유입니다.