data lake 은 어떻게 동작할까?

Data warehouse → Data lake → Lakehouse 의 진화. "S3 에 Parquet 파일 무더기" 라는 단순함이 ACID + 분석 query 까지 지원하는 modern platform 으로. Iceberg / Delta / Hudi 의 등장 + Trino / DuckDB 의 성숙으로 가능. 이 가이드는 그 layer 의 메커니즘을 정리한다.

Warehouse vs Lake vs Lakehouse

Data Warehouse (전통):
- 정형 데이터 (table, schema)
- proprietary storage (Teradata, Oracle DW)
- schema-on-write
- 예: Snowflake, BigQuery, Redshift
- 강점: 빠른 SQL, ACID, BI 친화
- 약점: 비정형 (JSON, log, image) 처리 어려움, 비쌈

Data Lake (2010s):
- 모든 데이터 그대로 (CSV, JSON, Parquet, image, video)
- cheap object storage (S3, GCS, ADLS)
- schema-on-read
- 강점: 매우 저렴, 유연
- 약점: ACID 없음, SQL 느림, "data swamp" 위험

Lakehouse (2020+):
- Lake 의 cheap storage + Warehouse 의 ACID + SQL
- 핵심 = open table format (Iceberg / Delta / Hudi)
- 예: Databricks, AWS Athena + Iceberg
- "둘의 좋은 점만" — modern 표준 추세

S3 + Parquet — Lake 의 기본

Storage layer:
- S3 / GCS / Azure Blob — object storage, $20-25 / TB / month
- 거의 무한 scale, durable (11-9s)

File format:
- CSV — 단순, 사람 가독. 큰 데이터에 비효율.
- JSON — 유연. parsing 비쌈, 압축 약함.
- Avro — schema 박힘 + row-oriented. streaming 에 자주.
- Parquet — columnar + heavy compression. analytics 의 default.
- ORC — Parquet 와 비슷, Hive 진영 강함.

Parquet 의 columnar 장점:
  user_id | name   | email     | created_at
  --------|--------|-----------|------------
  1       | Alice  | a@x.com   | 2026-01-01
  2       | Bob    | b@y.com   | 2026-01-02
  ...

  → 각 column 을 별도 chunk 로 저장 + 각 column 별 compression
  → "SELECT name FROM users" 시 name column 만 read, 다른 column skip
  → row-oriented (CSV) 대비 10-100× 빠름

→ Parquet 가 modern data lake 의 사실상 표준.

Open Table Format — Lakehouse 의 핵심

Plain Parquet 의 문제:
- ACID 없음 — concurrent write 시 corruption
- DELETE / UPDATE 어려움 (Parquet 는 immutable)
- snapshot / time travel 못 함
- file 수 폭증 (수백만 small files)

Open table format 의 답:
- metadata layer 가 "어떤 Parquet 가 현재 table 인가" 추적
- snapshot 별 metadata → time travel
- ACID transaction
- compaction (작은 file 모아 큰 file 로)
- schema evolution

3 대 format:

Iceberg (Netflix, 2017):
- Apache 표준, vendor-neutral
- snapshot + manifest + Avro metadata
- 거의 모든 query engine 지원 (Trino, Spark, Flink, Snowflake, BigQuery)

Delta Lake (Databricks, 2017):
- Databricks 가 주도, OSS
- _delta_log/ 디렉토리에 JSON metadata
- Spark / Databricks 와 최적

Hudi (Uber, 2017):
- streaming workload 강함 (upsert)
- Copy-on-Write + Merge-on-Read 두 모드

→ Iceberg 가 vendor-neutral 로 가장 채택률 ↑.
   Databricks 면 Delta, streaming 위주면 Hudi.

Schema-on-Read

Lake 의 핵심 특성 — write 시 schema 강제 X.

저장:
  s3://lake/events/year=2026/month=05/day=27/file_001.parquet
  s3://lake/logs/app=api/...
  s3://lake/raw/api_response_dump.json
  s3://lake/users/users.csv

read 시점에 schema 명시:
  CREATE EXTERNAL TABLE events (
    user_id INT, event_type STRING, ts TIMESTAMP
  )
  LOCATION 's3://lake/events/'
  STORED AS PARQUET;

장점:
- 일단 적재 — 나중에 어떤 schema 든 OK
- 새 column 도 자동 활용
- 데이터 source 변경 시 lake 그대로

단점:
- garbage 누적 — schema 안 박힌 raw 데이터 무한 적재 → swamp
- query 가 느려질 수 있음 (parsing 시점에 변환)
- data lineage / quality 안 보장

→ Lakehouse (open table format) 이 schema-on-write 의 일부 장점 되찾음.

Partitioning — query 가속

s3://lake/events/year=2026/month=05/day=27/ 같은 디렉토리 구조.

query:
  SELECT * FROM events
  WHERE event_date BETWEEN '2026-05-01' AND '2026-05-31'

→ engine 이 month=05 의 partition 만 scan, 다른 month 무시
→ scan cost 30× 감소 (1 년 → 1 월)

함정:
- 너무 fine-grained partition (예: hour 별) → 너무 작은 file 수백만 개
- 너무 coarse → partition pruning 효과 X
- 일반적: date column 의 day 단위

modern (open table format):
- partition 정보가 metadata 에 박힘 (S3 prefix 의존 X)
- hidden partitioning (Iceberg) — partition column 의 transform 자동

Query Engine

Engine	특징
Trino (Presto)	분산, 다중 source (lake + DB + Kafka) JOIN, SQL 표준
Spark SQL	Databricks 의 기반, ETL + ML 통합
DuckDB	single-node embedded, 작은 dataset 매우 빠름
Athena (AWS)	Trino managed, S3 직접 query, pay-per-query
BigQuery	warehouse + lake (external tables on GCS)
ClickHouse	OLAP DB, S3 외부 table 지원, sub-second query

흔한 함정

"data lake = S3 에 파일 던지기" — metadata / catalog 없으면 "data swamp". AWS Glue / Hive Metastore / Iceberg catalog 필수.
small file problem — streaming write 가 5분 마다 작은 Parquet → 백만 개. compaction 필요.
schema evolution 후 옛 file 깨짐 — column 삭제 또는 type 변경 시 옛 Parquet 의 schema 와 충돌. open table format 의 schema evolution rule 따르기.
partition 안 함 — full table scan 매번. 큰 dataset 의 partition 필수.
concurrent write 의 race — plain Parquet 에 여러 process 가 write → corrupted manifest. open table format 의 ACID 사용.

마무리

Data lake 의 진화 — S3 + Parquet 의 저렴함 + Iceberg/Delta 의 ACID = lakehouse. Snowflake / BigQuery 같은 proprietary 의 비싸진 cost 가 lakehouse 의 채택을 가속.

실용 — modern 시작은 S3 + Parquet + Iceberg + Trino. Databricks 면 Delta + Spark. 분석 query 만 필요하면 Snowflake / BigQuery 의 편의 가치도 큼 — trade-off (편의 vs cost).