Why We Moved from Hive-Style Data Lakes to Apache Iceberg?
Author: Naidu Rongali | Source: Medium | Published: 2026-06-11
한 줄 요약
Hive-style 데이터 레이크(디렉토리 기반 파티션)에서 Apache Iceberg(메타데이터 아키텍처)로 이전한 이유를 7가지 문제와 그 해결로 정리 — Iceberg는 Parquet 대체가 아니라 데이터를 관리하는 방식의 근본적 차이.
핵심 주장/내용
- 4년 전엔 Iceberg 생태계가 미성숙해 custom 대안 사용. AWS의 Iceberg 지원 확대 + S3 Tables(Iceberg 기반 관리형) 출시가 tipping point
- Iceberg ≠ Parquet 대체: 여전히 Parquet로 저장. 혁신은 데이터 파일 위의 메타데이터 레이어(스키마, 파티션 정의, snapshot 이력, 파일 통계, 위치). Glue Catalog는 current metadata 파일 포인터만 저장 → metadata.json → snapshot → manifest list → manifest files → Parquet
- 7가지 문제 해결:
- 디렉토리 기반 file discovery(50,000 파일 = 50 S3 LIST) → manifest의 file-level 통계로 pruning(파일 열지 않고)
- Hive 파티션이 폴더 구조에 결합 → 파티션을 메타데이터에 분리(S3는 dumb store)
- 파티션 진화가 대량 rewrite 요구 → 메타데이터에 spec ID 저장(구 파일 그대로, 신 파일만 새 spec)
- reader가 partial write 관찰 → snapshot 기반 atomic commit
- fragile 스키마 진화 → column ID(이름·위치 아닌 영구 정수 ID)로 매칭, 구 파일 rewrite 없이 add/drop/rename
- 데이터 레이크가 append 전용 → row-level mutation: Copy-on-Write(영향 파일만 rewrite, read 빠름) vs Merge-on-Read(delete file 분리, write 빠름)
- time travel 없음 → 매 commit이 snapshot
- Iceberg가 도입하는 새 부담: small files 문제, 메타데이터 오버헤드 → compaction·manifest compaction·snapshot expiration·orphan cleanup 필요. AWS Glue 최적화 / S3 Tables가 운영 부담 완화(control vs simplicity)
주요 수치 / 사실
- 50,000 파일 ÷ 1,000 keys/request = 50 LIST 요청(Hive)
- CoW: 1,000 파일 중 3개 영향 시 3개만 rewrite
- 트레이드오프 테이블: Self-Managed(control 高/effort 高) → Glue Maintenance(중간) → S3 Tables(control 低/effort 低)
관련 위키
Source: 원문 보기