Iceberg

4단계 메타데이터 계층

Iceberg의 메타데이터는 트리 구조로 쌓인다. 최상위에는 metadata.json 파일이 있고, 여기에 테이블 스키마(들), 파티션 스펙(들), 정렬 순서, 그리고 스냅샷 목록과 '현재 스냅샷'을 가리키는 포인터가 들어 있다.

각 스냅샷은 테이블의 특정 시점 상태를 나타내며, 하나의 매니페스트 리스트(manifest list, Avro 파일)를 가리킨다. 매니페스트 리스트는 그 스냅샷을 구성하는 매니페스트 파일들의 목록이며, 각 매니페스트 파일에 대해서도 파티션 값의 범위 같은 요약 통계를 함께 들고 있어 상위 레벨에서부터 가지치기(pruning)가 가능하다.

매니페스트 파일(manifest file)은 실제 데이터 파일 목록을 담고 있으며, 파일별로 파티션 값, 컬럼 단위 통계(min, max, null count), 파일 크기 등을 기록한다. 즉 원문이 요약한 '메타데이터 파일 → 스냅샷 → 매니페스트 리스트 → 매니페스트 파일'이라는 4단계는 정확한 설명이며, 각 단계마다 통계 기반 가지치기가 겹겹이 일어난다는 점이 중요하다.

파일 리스팅 없이 쿼리 플래닝하기

S3처럼 객체 스토리지의 LIST 연산은 파일 수가 많아질수록 느려진다. 만약 테이블 상태를 알기 위해 디렉터리를 매번 리스팅해야 한다면, 파일이 10만 개를 넘는 테이블에서는 이 자체가 쿼리 플래닝의 병목이 된다.

Iceberg는 모든 데이터 파일의 경로를 매니페스트 파일에 명시적으로 기록해 두기 때문에, 쿼리 엔진은 스토리지에 LIST를 요청할 필요 없이 메타데이터 트리만 읽고 정확히 어떤 파일을 스캔할지 결정할 수 있다. 이는 Iceberg가 자주 내세우는 구조적 강점이며, 파티션(가로) 수가 많아질 때뿐 아니라 스냅샷(세로, 버전) 수가 많아질 때도 상대적으로 안정적으로 확장된다.

구체적 성능 수치와 스펙 버전 — 정정

정정 — 원문은 '50만 개 파일 테이블에서 Iceberg 플래닝은 2-5초, Delta의 로그 리플레이는 8-15초', '메타데이터가 시간당 커밋 12개월 누적 시 2-4GB' 같은 구체적인 숫자를 제시한다. 이 수치들은 측정 환경(파일 크기, 클러스터 사양, 카탈로그 종류, 캐싱 여부)이 전혀 명시되지 않은 블로그 저자 개인의 관찰담이다. 흥미롭게도 이 블로그 자체가 서두에서 '출처가 불분명한 벤더 벤치마크를 조심하라'고 경고하면서도, 정작 본문에서는 출처 없는 구체적 수치를 그대로 제시하는 모순을 보인다. 방향성(메타데이터 기반 플래닝이 파일 수가 많을 때 유리하다)은 구조적으로 타당하지만, 특정 초 단위 숫자를 암기하거나 다른 환경에 그대로 적용하면 안 된다.

또한 원문은 Iceberg의 스펙 버전 변화를 전혀 언급하지 않는다. Iceberg는 v1(기본 스냅샷 기반 테이블), v2(행 단위 삭제 지원 — merge-on-read의 기반)를 거쳐, 2025년 커뮤니티에서 v3 스펙이 확정되었다. v3는 삭제 벡터(deletion vector, 기존 positional delete 파일보다 더 효율적인 비트맵 기반 삭제 표현), 행 계보 추적(row lineage), variant/geometry/geography 타입, 컬럼 기본값(default value) 확장 등을 추가한다. 이런 버전별 변화는 실무에서 '왜 우리 엔진이 아직 이 기능을 지원하지 않는가'를 판단할 때 중요한 근거가 된다.