Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> **Season 5 Ep 1** — Season 4가 "AI 제품의 축"이었다면 Season 5는 **"AI 아래 흐르는 데이터의 축"**. 첫 에피소드는 가장 극적으로 변한 영역 — **레이크하우스**.

Prologue — "2024년은 Iceberg의 해였다"

2020–2023년까지 데이터 업계의 가장 뜨거운 논쟁은 **"Open Table Format 3대장"** — Apache Iceberg, Delta Lake, Apache Hudi — 중 무엇이 표준이 되는가였다.

2024년 두 사건이 결론을 냈다:

1. **Snowflake가 Iceberg 네이티브 지원 + 자체 카탈로그(Polaris) 오픈소스화** (2024 Summit)

2. **Databricks가 Tabular(Iceberg 창립자들의 회사)를 \$1B+ 인수**

Databricks는 Delta 창시자. Tabular는 Iceberg 창시자들(Ryan Blue, Dan Weeks)의 회사. 이 인수는 **"Delta와 Iceberg는 사실상 같은 것이 되어야 한다"**는 선언이었다. 2024–2025년 Databricks는 Delta UniForm을 통해 Delta를 Iceberg로 읽게 만들었다.

2025년 현재, **Iceberg가 사실상의 오픈 테이블 포맷 표준**이 되었고, Delta·Hudi는 Iceberg와의 상호운용성을 추구한다. 이 글은 그 현실을 전제로, 실무자가 알아야 할 모든 것을 정리한다.

1장 · 레이크하우스란 무엇인가

1.1 3세대 데이터 아키텍처

- **1세대(1980s–2000s)**: Data Warehouse (Teradata, Oracle) — 구조화·고비용

- **2세대(2010s)**: Data Lake (Hadoop/S3 + Parquet) — 저렴·자유롭지만 ACID·스키마 없음

- **3세대(2020s)**: Lakehouse — Lake의 저렴함 + Warehouse의 ACID·성능

1.2 Lakehouse의 핵심

- **오브젝트 스토리지**(S3/GCS/ADLS) + **오픈 파일 포맷**(Parquet/ORC)

- **Open Table Format**이 위에 메타데이터를 얹어 ACID, 스키마 진화, 타임트래블 제공

- 쿼리 엔진(Spark/Trino/Flink/DuckDB/Snowflake/BigQuery)이 동일 데이터를 공유

1.3 왜 레이크하우스인가

- 데이터 중복 제거(Warehouse + Lake 이중 운영 종료)

- BI · ML · 스트리밍이 **같은 테이블** 사용

- 벤더 락인 감소(오픈 포맷·오픈 카탈로그)

- 비용 절감(압축·파티션 진화·zstd·ZSTD zlib 대체)

2장 · Iceberg, Delta, Hudi 아키텍처 비교

2.1 공통 요소

세 포맷 모두:

- Parquet/ORC 데이터 파일 + JSON/Avro 메타데이터

- Snapshot 기반 ACID

- Schema evolution, Time travel, Partition pruning

- Z-order/Sort-based clustering

2.2 Apache Iceberg

- 2017 Netflix에서 출발, 2018 Apache incubator

- **Manifest 파일** 2층 구조(metadata.json → manifest list → manifest → data files)

- **Hidden partitioning** — 쿼리에 파티션 컬럼 명시 불필요

- **Partition evolution** — 파티션 전략을 사후 변경 가능

- **Branch/Tag** — Git 같은 분기·태그

- 카탈로그 추상화: REST, Hive, Glue, Nessie, Polaris, Unity 등

2.3 Delta Lake

- 2019 Databricks에서 출발

- **Transaction log (\_delta\_log/)** — JSON + Parquet checkpoint

- Databricks 생태계 최적화

- **Liquid clustering**(2024) — 파티션 없이 자동 클러스터링

- **UniForm**(2024) — Delta를 Iceberg로 노출 가능(메타데이터 변환)

2.4 Apache Hudi

- 2017 Uber에서 출발

- **Copy-on-Write(COW)** vs **Merge-on-Read(MOR)** 선택 가능

- 스트리밍·업서트에 강점(CDC 파이프라인)

- 인덱스(Bloom, Record key) 내장

- 시장 점유율은 Iceberg/Delta에 뒤지지만 CDC 워크로드에서 여전히 경쟁력

2.5 비교표

|------|---------|-------|------|

| 표준화 | 높음(업계 표준) | 높음(Databricks + UniForm) | 중간 |

| 카탈로그 다양성 | 최고 | Unity 중심 | 중간 |

| Hidden partitioning | O | X(Liquid로 대체) | X |

| 스트리밍 | 발전 중 | 강함 | 매우 강함 |

| CDC/Upsert | 지원 | 지원 | 최강 |

| 벤더 중립성 | 최고 | 중간 | 높음 |

| 2025 모멘텀 | 최강 | Iceberg 호환 중심 | 안정 |

2.6 선택 가이드

- **일반 BI/ML + 벤더 중립**: Iceberg

- **Databricks 전용 + 최대 성능**: Delta

- **CDC 스트리밍 중심**: Hudi 또는 Iceberg + Flink

- **혼재된 팀**: Iceberg(Delta UniForm으로 Databricks도 수용)

3장 · Parquet·ORC·Puffin — 파일 레벨 진실

3.1 Parquet

- 컬럼형, Dremel 논문 기반

- 압축(Snappy/Zstd/Gzip/LZ4), 인코딩(Dictionary/RLE/Delta)

- Row group + Page 구조

- Predicate pushdown, Column pruning

3.2 ORC

- Hive 생태계에서 출발

- Stripe 단위, 인덱스 내장

- Parquet 대비 BI 워크로드 일부 우위, 생태계 규모는 Parquet 우세

3.3 Puffin(Iceberg 3.0)

- Iceberg 전용 사이드카 포맷

- 통계·인덱스·ML 벡터 저장

- **Blob 기반** — 유연한 확장

3.4 실무 팁

- 2025년 거의 모든 신규 프로젝트는 **Parquet + Zstd**

- Zstd level은 3–6이 CPU 대비 최적

- Row group size 128–256MB, Page size 1MB 기준

- Dictionary encoding이 컬럼 크기의 60–90%를 좌우

4장 · 카탈로그 전쟁

4.1 왜 카탈로그가 중요한가

- 테이블 위치·스키마·스냅샷을 **중앙 관리**

- 권한·감사·멀티엔진 접근

- Iceberg는 카탈로그 API가 표준화돼 있어 카탈로그 교체 가능

4.2 주요 카탈로그

- **AWS Glue Data Catalog**: AWS 생태계, Iceberg/Delta/Hudi 모두 지원

- **Snowflake Polaris (2024 오픈소스)**: REST 표준, 외부 엔진 접근

- **Databricks Unity Catalog**: Databricks 생태계, 2024 오픈소스화(Unity Catalog OSS)

- **Project Nessie**: Git 같은 브랜치·태그, Iceberg 특화

- **Apache Gravitino**: 메타데이터 연합(federation), 2024 부상

- **Tabular(현 Databricks)**: Iceberg REST 카탈로그 기준 구현

4.3 2024–2025 방향

- **Iceberg REST Catalog**가 표준 인터페이스로 자리잡음

- Polaris와 Unity Catalog OSS가 서로 호환성 강조하며 경쟁

- 엔터프라이즈는 **카탈로그 연합**(여러 카탈로그 통합)으로 이동

4.4 카탈로그 고르기

- AWS 중심: Glue 또는 Polaris(S3 통합)

- Databricks 중심: Unity Catalog

- 벤더 중립 + 고급 기능: Polaris 또는 Nessie

- 다중 엔진·다중 벤더: REST 표준이면 어떤 카탈로그도 OK

5장 · 쿼리 엔진 생태계

5.1 2025 주요 엔진

- **Snowflake**: Iceberg External Table + Native 지원, 세계 최대 DWH 중 하나

- **Databricks SQL**: Delta + Iceberg UniForm

- **BigQuery**: Iceberg External, BigLake

- **Trino/Presto**: 오픈, Iceberg 최고 성능 중 하나

- **Apache Spark**: 범용 배치·ML

- **DuckDB**: 단일 노드, Iceberg 읽기 2024 확장

- **ClickHouse**: OLAP 초고속, Iceberg 읽기 지원 확대

- **Apache Flink**: 스트리밍·CDC

- **StarRocks / Doris**: MPP OLAP, Iceberg 활발

5.2 엔진별 강점

| 엔진 | 강점 | 약점 |

|------|------|------|

| Snowflake | 관리 편함, ACID 강함 | 가격, Closed |

| Databricks | ML 통합, Delta 최적화 | 가격, Lock-in |

| Trino | 오픈, 멀티소스 | 운영 복잡 |

| DuckDB | 싱글 노드 최강 | 스케일 한계 |

| ClickHouse | OLAP 속도 | SQL 호환성 |

| Flink | 스트리밍 | 학습 곡선 |

5.3 "Multi-engine on one lakehouse" 패턴

- ETL: Spark

- BI: Trino 또는 Snowflake

- 실험·분석: DuckDB

- 스트리밍: Flink

- ML: Databricks 또는 Spark + Ray

하나의 Iceberg 테이블을 여러 엔진이 공유하는 것이 2025년의 지배적 패턴.

6장 · 성능 튜닝 — 실무 10대 원칙

6.1 파티션 전략

- 기본: 날짜(월/일)로 파티션

- 고카디널리티 컬럼은 **파티션 금지**(작은 파일 폭증)

- Hidden partitioning(Iceberg): 함수 기반(year, month, bucket)

6.2 Z-order / Liquid clustering

- 다차원 쿼리 패턴일 때 유용

- Z-order: Iceberg/Delta 모두

- Liquid(Delta 2024): 자동, 파티션 불필요

6.3 파일 크기

- 타겟 128MB–1GB

- 작은 파일 폭증은 성능 1순위 문제

- Compaction 주기적 실행

6.4 Compaction

- Bin-packing(기본)

- Sort-based(쿼리 빈도 높은 컬럼 기준)

- Z-order(다차원)

6.5 Vacuum / Snapshot expiration

- 오래된 스냅샷·데이터 파일 제거

- 비용·성능 동시 개선

- 기본 보존 7–30일, 규제에 따라 조정

6.6 Metadata 관리

- Manifest list 너무 커지면 쿼리 플래닝 느려짐

- 주기적 `rewrite_manifests` (Iceberg)

- Checkpoint 생성(Delta)

6.7 통계(Statistics)

- NDV(Number of Distinct Values), Min/Max, Null count

- Puffin(Iceberg)에 저장

- Cost-based optimizer 성능 핵심

6.8 스키마 진화

- Add/Drop/Rename 안전하게

- 컬럼 ID 기반(Iceberg/Delta)으로 이름 변경도 무중단

- 타입 변경은 호환 방향만(Int → Long 등)

6.9 Predicate pushdown

- WHERE 조건을 엔진 → 포맷까지 전달

- 파티션 pruning + Row group 스킵

- 쿼리 패턴에 맞춰 파티션·Sort 키 설정

6.10 대용량 Upsert

- MERGE INTO 활용

- Copy-on-Write vs Merge-on-Read 선택

- Hudi는 Record key 기반 인덱스로 빠른 upsert

7장 · 스트리밍과 CDC

7.1 배치 vs 스트리밍의 경계 약화

- 2025년 Lakehouse는 배치·스트리밍 **같은 테이블**에 쓸 수 있음

- Iceberg + Flink: 실시간 append + 쿼리 가능

- Delta + Structured Streaming: Databricks 표준

7.2 CDC 패턴

- MySQL/Postgres → Debezium → Kafka → Flink → Iceberg

- 또는 Fivetran·Airbyte → Iceberg 직접

- Upsert 처리: Iceberg v2 row-level delete + MERGE

7.3 지연 목표

- Near-realtime: 1–5분

- Micro-batch: 10–60초

- 진짜 실시간: 스트리밍 OLTP(Kafka) + 분석은 별도 rollup

7.4 실무 조언

- "스트리밍 = 모든 걸 실시간"은 비용 폭탄

- SLA 기반으로 테이블별 지연 목표 설정

- 대부분의 BI는 **15분–1시간 지연**이면 충분

8장 · 거버넌스 · 보안

8.1 테이블 레벨 권한

- Iceberg REST + 카탈로그 기반 RBAC

- Snowflake/Databricks는 카탈로그에서 통합 관리

- Ranger/Open Policy Agent(OPA) 통합 가능

8.2 컬럼·행 레벨 보안

- Masking, Row-level filter

- Unity Catalog / Snowflake Dynamic Data Masking 지원

- Iceberg 자체보다는 엔진·카탈로그 계층에서 주로 처리

8.3 데이터 계보(Lineage)

- OpenLineage 표준

- Marquez, DataHub, Atlan, Collibra

- "어느 소스가 이 지표를 만드는가"를 자동 추적

8.4 감사(Audit)

- 모든 DDL/DML 로그

- 누가 언제 어떤 스냅샷을 읽었는가

- 금융·의료 규제 대응

8.5 PII·암호화

- Column-level 암호화(Parquet Modular Encryption)

- S3/GCS 서버측 암호화는 기본

- Tokenization으로 PII 대체(분석 가능성 유지)

9장 · 마이그레이션 전략

9.1 Hive → Iceberg

- In-place migration: 메타데이터만 변환 (데이터 복사 없이)

- Iceberg `migrate` 프로시저(Spark) 또는 Tabular/Polaris 도구

- 주의: 기존 파티션 구조 그대로 유지하거나 재구성

9.2 Delta → Iceberg (UniForm)

- Databricks UniForm 활성화 → Delta가 Iceberg 메타도 생성

- 양방향 읽기 가능, 외부 엔진 접근 용이

- Delta 고유 기능(Liquid clustering 등)은 Iceberg 측에서 미보임

9.3 Snowflake 네이티브 → Iceberg External

- Iceberg External Table로 Snowflake 내부 데이터 덤프

- 쿼리 엔진 다양화 가능, 일부 기능(Time Travel 등)은 내부 테이블 대비 제한

- 비용·성능 비교 후 결정

9.4 Hudi → Iceberg

- 스트리밍 워크로드 특성상 직전 마이그레이션은 드묾

- 새 테이블은 Iceberg로, 기존은 Hudi 유지하는 하이브리드 흔함

9.5 마이그레이션 체크리스트

- 백업·롤백 계획

- 파티션 전략 재검토

- 쿼리 엔진·BI 툴 호환성 확인

- 비용 시뮬레이션

- 단계별 이관(샤드·기간별)

10장 · 비용 최적화

10.1 스토리지

- Parquet Zstd 압축(일반 대비 30–50% 절감)

- 오래된 데이터는 Glacier/Archive로 이동

- Snapshot expiration 주기화

10.2 컴퓨트

- Spot/Preemptible 인스턴스(배치)

- Autoscale with warm pool(지연 줄이기)

- 작은 쿼리는 DuckDB로 오프로드

10.3 네트워크

- 같은 리전 내 처리

- S3 Transfer Acceleration 필요 시만

- Cross-region 복제는 꼭 필요한 경우만

10.4 쿼리 비용

- BI 대시보드는 프리컴퓨트(Materialized view)

- 반복 ad-hoc은 결과 캐시

- 사용자별·팀별 쿼터 설정

10.5 실제 절감 사례 범위

- 레이크하우스 전환으로 **스토리지 30–50%**, **쿼리 비용 20–40%** 절감 보고 사례 흔함

- 규모가 클수록 효과 큼

11장 · AI·ML 통합

11.1 Feature Store로서의 Lakehouse

- Feast, Tecton이 Iceberg·Delta 지원 확대

- 배치 피처 + 온라인 스토어(Redis/DynamoDB) 조합

- Online-offline skew 관리가 핵심

11.2 벡터·임베딩 저장

- Iceberg v3 / Puffin에 벡터 저장 실험

- 전용 벡터 DB(Pinecone, Weaviate, Milvus) 대비 정확도 낮지만 비용·통합 우위

- 2025년 하이브리드가 흔함

11.3 ML 파이프라인

- 원본 → Silver → Gold(Medallion 패턴)

- Gold 테이블을 ML 학습·추론에 사용

- 학습·평가 데이터 버전: Iceberg tag/branch 활용

11.4 LLM·RAG

- 회사 문서 → Chunk → 임베딩 → Iceberg 테이블(메타+벡터)

- Iceberg 시간여행으로 RAG 결과 재현 가능

- 인증·권한을 카탈로그에서 중앙 관리

12장 · 한국 기업의 레이크하우스

12.1 현황

- 금융·통신·대기업: Warehouse(Teradata/Oracle) + Lake(Hadoop/HDFS) 이중 운영

- 2022–2024 Databricks·Snowflake 도입 가속

- 2024–2025 Iceberg 기반 자체 구축도 증가

12.2 의사결정 고려사항

- **규제·망분리**: 금융·공공은 온프레/사내 VPC 필수

- **인건비**: 관리형 서비스 vs 자체 운영

- **기존 DW와 공존**: 즉시 대체보다 데이터 영역별 단계 도입

- **한국어 생태계**: 카탈로그·BI 한국어 메타 지원

12.3 벤더·파트너

- 국내 클라우드(NHN Cloud, KT Cloud, Naver Cloud) + 오브젝트 스토리지

- 국내 SI·컨설팅: LG CNS, 삼성 SDS, SK C&C, 베스핀글로벌 등 레이크하우스 프랙티스

- 스타트업: Superb AI(MLOps), Upstage(LLM·Document AI) 등 파트너십

12.4 실무 난관

- 대용량 레거시 DW 이관 비용

- 한국어 컬럼명·데이터 규칙(한자·영문 혼재)

- 감사·접근 통제의 까다로움(금융감독원·개인정보위)

- 내부 인력 확보(데이터 엔지니어 부족)

13장 · 안티패턴 10선

13.1 포맷 혼용 남발

Iceberg, Delta, Hudi를 모두 도입 → 운영 비용·학습 곡선 폭증.

13.2 파티션 과잉

고카디널리티(사용자ID 등)로 파티션 → 작은 파일 수백만.

13.3 Compaction 미설정

파일 쌓이다가 쿼리 10배 느려짐.

13.4 Snapshot 영원 보관

스토리지 비용 폭증, 메타데이터 비대.

13.5 카탈로그 없이 Lake 운영

"파일 있으면 테이블" → 일관성 없음, 감사 불가.

13.6 스키마 강제 변경

Drop + Add → 컬럼 ID 깨짐, 타임트래블 깨짐.

13.7 스트리밍 무조건 실시간

필요하지 않은데 kinesis/kafka → 비용 낭비.

13.8 모든 데이터 Gold로

Bronze/Silver/Gold 계층 없음 → 비용·품질 동시 저하.

13.9 엔진 한 개에 종속

Snowflake/Databricks 한 벤더 락인 → 협상력 상실.

13.10 거버넌스 후순위

PII·감사·계보 무시 → 감사 실패·사고.

14장 · 체크리스트 — 레이크하우스 런칭 전 12가지

- [ ] 테이블 포맷 선택 근거 문서화(Iceberg 기본, 이유 있는 경우만 Delta/Hudi)

- [ ] 카탈로그 선택(Glue/Polaris/Unity/Nessie) + 권한 전략

- [ ] 파일 포맷·압축·크기 정책(Parquet + Zstd, 128MB–1GB)

- [ ] 파티션 전략 + Z-order/Liquid 여부

- [ ] Compaction·Vacuum 자동화

- [ ] Snapshot retention 정책

- [ ] Medallion 계층(Bronze/Silver/Gold) 정의

- [ ] 쿼리 엔진 라인업(BI·ML·스트리밍·ad-hoc)

- [ ] 스트리밍 SLA별 아키텍처

- [ ] 거버넌스(RBAC, 마스킹, 계보, 감사)

- [ ] 비용 대시보드(스토리지·컴퓨트·쿼리)

- [ ] 마이그레이션 경로와 롤백 플랜

15장 · 다음 글 예고 — Season 5 Ep 2: "스트리밍 vs 배치의 재정의"

레이크하우스가 정리됐으니, 다음은 **데이터가 얼마나 빠르게 흐를 수 있는가**의 재정의.

- Lambda vs Kappa 아키텍처의 2025년 버전

- Flink, Spark Structured Streaming, Kafka Streams, Materialize, RisingWave

- Change Data Capture(CDC) 심화: Debezium, Fivetran, Airbyte

- Iceberg v3의 row-level delete와 실시간 upsert

- Streaming SQL (ksqlDB, Flink SQL, RisingWave)

- 실시간 Feature Store

- 관측성·디버깅(Flink CEP, Kafka lag)

- 비용·지연 트레이드오프

- 한국 기업 실시간 아키텍처(금융 거래·커머스·게임)

- "진짜 실시간"이 필요한 케이스와 아닌 케이스 구분

**"모든 데이터를 실시간으로"는 2020년의 약속, 2025년은 실용주의의 시대.**

다음 글에서 만나자.

> **요약**: 2024년 Snowflake의 Iceberg 네이티브 지원과 Databricks의 Tabular 인수로 **Open Table Format 전쟁은 Iceberg의 사실상 승리로 종결**. 2025년 실무자는 Iceberg를 기본으로 하되, Databricks 전용 최대 성능이 필요하면 Delta, CDC 스트리밍 중심이면 Hudi를 고려한다. 카탈로그(Glue/Polaris/Unity/Nessie)는 REST 표준 덕에 교체 가능하고, 쿼리 엔진은 하나의 테이블을 여러 엔진이 공유하는 "Multi-engine on one lakehouse" 패턴이 지배적. **"레이크하우스 = 오픈 포맷 + 오픈 카탈로그 + 다양한 엔진"** — 이 세 축이 2025년 데이터 플랫폼의 기반이 됐다.