왜 탄상했나?

기존 parquet 형식의 스토리지 포맷이 스토리지에 저장될 때 일반적으로 년월/일 디렉토리를 가진다. 일자 단위로 수억개씩 파일이 쌓이면 일자별로 스토리지에 조회를 하거나 파일이 변경될 때 성능 병목지점이 되기도 하고 조회가 불가능한 문제들이 생겼습니다.

기존 구조

S3 list 호출로 병목 현상 발생 가능성 높음.

flowchart LR

    subgraph Legacy["기존 데이터 레이크 구조"]
        direction TB

        QE1["쿼리 엔진 예 Spark Presto"]
        HMS["하이브 메타스토어 파티션 정보"]
        S3L["S3 버킷 파티션 디렉토리"]

        QE1 -->|1 파티션 정보 조회| HMS
        QE1 -->|2 파티션별 파일 목록 요청| S3L
        S3L -->|3 매우 많은 파일 목록 반환| QE1
        QE1 -->|4 모든 파일을 읽어 처리| S3L
    end

    NOTE_L["문제점 작은 파일 다수 생성<br/>파티션별 S3 파일 목록 조회로 병목 발생"]
    QE1 --- NOTE_L

개선된 구조

기존 구조의 S3 list 호출 병목을 해소했고,

읽어야하는 파일만 자동 선택됨.

스냅샷 기반으로 ACID, Time Travel 가능

Spark, Flink 등 일관된 읽기 가능

작은 파일 다수 생성되는 문제도 메타데이터 레벨에서 완화 가능.

flowchart LR

    subgraph Iceberg["Iceberg 데이터 레이크 구조"]
        direction TB

        QE2["쿼리 엔진 예 Spark Flink Trino"]
        CATALOG["Iceberg 카탈로그 메타데이터"]
        META["Iceberg 스냅샷 메타데이터"]
        S3I["S3 버킷 데이터 파일"]

        QE2 -->|1 테이블 스냅샷 조회| CATALOG
        CATALOG -->|2 최신 스냅샷 정보 전달| META
        QE2 -->|3 메타데이터 통계 읽기| META
        META -->|4 필요한 파일만 선택됨| QE2
        QE2 -->|5 필요한 파일만 읽기| S3I
    end

    NOTE_R["장점 S3 파일 목록 조회 없음<br/>스냅샷과 통계 기반 파일 최소 조회"]
    QE2 --- NOTE_R

요약 : 기존 레이크는 파일을 직접 뒤지고(I/O 폭증), Iceberg는 메타데이터로 필요한 파일만 찾아간다(효율적).