Icerberg 정리

Q·2025년 3월 29일

Iceberg

목록 보기
1/14

Iceberg Spec — Overview & Terminology

Overview

Iceberg 테이블 스펙은 다음과 같은 목적과 기본 특징을 갖습니다:

  • 대규모, 느리게 변하는 파일들의 모음을 분산 파일 시스템 또는 키-값 저장소에 테이블 형태로 관리하기 위해 설계됨. oai_citation:0‡Iceberg

  • 포맷 버전(format version) 관리:

    • 버전 1, 2, 3은 커뮤니티에서 완료되어 채택됨. oai_citation:1‡Iceberg
    • 버전 4는 개발 중이며 아직 공식 채택되지 않음. oai_citation:2‡Iceberg
    • 포맷 버전 번호는 forward-compatibility를 깨는 새로운 기능이 추가될 때 증가함 (이전 reader들이 새 기능을 읽지 못할 수 있는 경우) oai_citation:3‡Iceberg
    • 새 기능을 지원하지 않는 엔진을 위해, 오래된 포맷 버전을 계속 사용할 수 있음. oai_citation:4‡Iceberg

  • 각 버전의 주요 추가 기능:

    • Version 1: 분석용 데이터 테이블 관리, 불변(immutable) 파일 형식(Parquet, Avro, ORC) 사용. oai_citation:5‡Iceberg
    • Version 2: row-level deletes (행 단위 삭제/업데이트) 추가. 기존 데이터를 삭제 파일(delete file)로 표현 가능. oai_citation:6‡Iceberg
    • Version 3: 확장된 타입 (나노초 timestamp, variant, geometry, geography 등), 컬럼 기본(default) 값 지원, 멀티 아규먼트 partition/sort transforms, row lineage, 바이너리 deletion vectors, 테이블 암호화 키 등. oai_citation:7‡Iceberg

  • 주요 목표 (Goals) 요약:

    1. 직렬화 가능한 격리성(Serializable isolation): 읽기는 commit된 스냅샷만 보고, 동시 쓰기 시 부분적 변화가 보이지 않음. oai_citation:8‡Iceberg
    2. 속도(Speed): 스캔 계획(scan planning) 시 파일 수나 파티션 수(n)에 비례하는 호출이 아니라 O(1) remote call 위주. oai_citation:9‡Iceberg
    3. 확장성(Scale): job planning은 클라이언트 측에서 가능하게, 중앙 메타데이터 스토어가 병목이 되지 않도록. oai_citation:10‡Iceberg
    4. 진화(Evolution): 스키마, 파티션 사양(spec) 진화 가능. nested 구조에서도 컬럼 추가/제거/순서 변경/이름 변경 가능. oai_citation:11‡Iceberg
    5. 신뢰 가능한 데이터 타입(Dependable types): 기본 타입(core types)의 정의가 명확해야 하고 예측 가능해야 함. oai_citation:12‡Iceberg
    6. 저장 분리(Storage separation): 파티셔닝은 테이블 설정(configuration)이고, 읽기는 데이터 값(data values) 기반 조건(predicate)으로 계획되어야 함. 파티션 값(partition values)이 물리적 디렉터리 구조에 강하게 종속되어서는 안 됨. oai_citation:13‡Iceberg
    7. 포맷(Formats): 데이터 파일 포맷(read-/write-optimized)가 동일한 스키마 & 타입 진화 규칙을 따름. oai_citation:14‡Iceberg

Terminology

아래는 Iceberg Spec에서 자주 쓰이는 용어들 및 정의입니다:

  • Table
    데이터 파일(data files) + 메타데이터(metadata files) + 스냅샷(snapshot) 등을 포함하는 단위. 테이블을 통해 분석 엔진이 일관된 뷰(view)를 가질 수 있도록 함. oai_citation:15‡Iceberg

  • Snapshot
    테이블의 특정 시점 시 상태. 테이블의 모든 데이터 파일이 어떤 상태인지, 어떤 manifest가 포함되는지 등을 정의함. 읽기 시점(read) 조회, 변경 추적, 타임 트래블(time travel) 지원. oai_citation:16‡Iceberg

  • Manifest
    스냅샷이 참조하는 데이터 파일들의 메타정보(파일 경로, 파티션 값, 통계 등)를 담은 파일. 여러 manifest 파일이 하나의 스냅샷을 구성함. oai_citation:17‡Iceberg

  • Manifest List
    특정 스냅샷이 포함하는 모든 manifest 파일을 모아 놓은 목록(metadata 파일). 스냅샷 하나의 “목차(table of contents)” 역할. oai_citation:18‡Iceberg

  • Partition Spec
    테이블 데이터를 어떻게 파티셔닝(partitioning)할지 정의하는 규격. 소스 컬럼(source column) + 변환(transform) 조합. 예: date(ts) 같은 변환. oai_citation:19‡Iceberg

  • Partition Tuple
    각 데이터 파일(data file)의 파티션(patition tuple) 값들의 구조체(struct). 파티션 사양대로 변환된 값들을 저장. 동일 파일 내 모든 행(row)은 동일한 partition tuple 값을 가짐. oai_citation:20‡Iceberg

  • Snapshot Log (history table)
    테이블의 현재 snapshot이 시간에 따라 어떻게 바뀌었는지 기록한 로그. 시간(timestamp)과 snapshot ID의 쌍(pair)들로 구성됨. 메타데이터(metadata)의 snapshot-log 필드에 저장됨. oai_citation:21‡Iceberg

Iceberg Spec — Manifests & Manifest Lists

Manifests

  • 정의: Iceberg의 매니페스트(manifest) 파일은 테이블의 데이터 파일 또는 삭제 파일(delete files)에 대한 메타데이터를 추적하는 역할을 한다.
  • 목적: 스캔 계획(scan planning)을 빠르게 하도록, 데이터 파일의 경계(bound), 통계(metrics), 파티션 정보 등을 저장한다.

Manifest Lists

스냅샷(snapshot)은 여러 개의 매니페스트 파일을 포함할 수 있고, 이 매니페스트들을 manifest list 라는 별도의 파일에서 관리한다.

  • 역할:
    • 각 매니페스트 파일에 대한 경로와 메타데이터를 추적.
    • 스냅샷 단위로 파일 변경 사항을 기록.
    • 스캔 시 전체 매니페스트 파일을 읽지 않고도 요약 정보를 통해 최적화 가능.

Manifest List 파일 구조

v1v2v3필드명 (ID, Name)타입설명
requiredrequiredrequired500 manifest_pathstring매니페스트 파일 경로
requiredrequiredrequired501 manifest_lengthlong매니페스트 파일의 크기 (바이트 단위)
requiredrequiredrequired502 partition_spec_idint매니페스트가 참조하는 파티션 스펙 ID
requiredrequiredrequired503 added_snapshot_idlong매니페스트가 추가된 스냅샷 ID
requiredrequired515 sequence_numberlong매니페스트가 테이블에 추가된 시점의 시퀀스 번호
requiredrequired516 min_sequence_numberlong매니페스트에 포함된 모든 라이브 데이터/삭제 파일의 최소 시퀀스 번호
requiredrequiredrequired517 contentint매니페스트 유형: 0 = 데이터 파일, 1 = 삭제 파일
optionalrequiredrequired504 added_files_countintADDED 상태인 파일 개수
optionalrequiredrequired505 existing_files_countintEXISTING 상태인 파일 개수
optionalrequiredrequired506 deleted_files_countintDELETED 상태인 파일 개수
optionalrequiredrequired512 added_rows_countlong추가된 파일들의 행 수 총합
optionalrequiredrequired513 existing_rows_countlong기존 파일들의 행 수 총합
optionalrequiredrequired514 deleted_rows_countlong삭제된 파일들의 행 수 총합
optionaloptionaloptional507 partitionslist<field_summary>파티션 필드별 요약 정보
optionaloptionaloptional519 key_metadatabinary암호화 키 메타데이터
optional520 first_row_idlongADDED된 행들의 첫 _row_id 값

Field Summary 구조

v1v2필드명 (ID, Name)타입설명
requiredrequired509 contains_nullbooleannull 값을 가진 파티션 포함 여부
optionaloptional518 contains_nanbooleanNaN 값을 가진 파티션 포함 여부
optionaloptional510 lower_boundbytes파티션 필드의 최소(non-null, non-NaN) 값
optionaloptional511 upper_boundbytes파티션 필드의 최대(non-null, non-NaN) 값

주의사항

  • Lower/Upper bound는 Iceberg 직렬화 포맷(Appendix D) 규칙에 따라 bytes로 저장됨.
  • 부동소수점 값에서 -0.0과 +0.0 구분 필수.

Manifest 관리 특징

  • 새로운 스냅샷이 생성될 때마다 새로운 manifest list 파일이 작성됨.
  • Appends(데이터 추가)는 새로운 매니페스트를 추가하는 방식으로 처리 → 전체 manifest 파일을 다시 쓰지 않아 효율적.
  • 대규모 테이블은 여러 매니페스트로 나뉘어 저장되어 병렬 처리 최적화.
  • 파티션 스펙이 진화(evolution)해도, 각 매니페스트는 자신이 작성될 당시의 스펙을 유지 → 쿼리 시 자동 변환.

Iceberg Spec — Scan Planning

Scan Planning은 쿼리할 때 어떤 데이터 파일(data file), 삭제(delete) 파일, 매니페스트(manifest) 등을 읽을지 결정하는 과정이에요.

기본 원리 (Spec 기준)

  • Snapshot의 manifest 파일들을 읽어서 스캔해야 할 파일들을 가려냄.
  • 상태가 DELETED인 데이터/삭제 항목(entry)은 실제 스캔에는 포함 안 됨.
  • Manifest List에는 여러 manifest 정보가 있고, 이 중 partition 통계(partition stats), 파일 수(file counts) 등의 요약 정보(metadata)를 저장함. 이 요약 정보 덕분에 모든 manifest를 읽지 않고도 일부를 제외(skip)할 수 있음.

필터링 단계

쿼리가 들어왔을 때 Scan Planning은 다음 단계를 거쳐요:

  1. Partition Predicate 변환

    • 쿼리의 row-level 조건(row predicate)을 파티션 값(partition value)에 대한 조건(partition predicate)으로 바꿈.
    • 예: 테이블에 ts_day = day(ts) 파티션이 있고 쿼리가 ts > X라면, partition predicate은 ts_day >= day(X) 같은 식으로.

  2. Manifest List 단계 필터링

    • Manifest List에서 저장된 partition field들의 lower bound / upper bound, partition spec, file 상태(added, existing, deleted) 등의 요약 정보로 먼저 manifest 단위 필터링
    • 요약 정보로 이 manifest 안에 파일 중에서 쿼리 조건에 맞을 가능성이 있는 파일 여부 판단

  3. Manifest 단계 필터링

    • 실제 manifest 파일 열어서, 각 데이터 파일의 partition tuple + 컬럼 단위 통계(column-level stats: null count, value count, lower/upper bounds 등) 확인
    • 이 정보로 쿼리 조건과 맞지 않는 파일들은 제거 (prune)

  4. Delete 파일 / Deletion Vector 적용 여부 결정

    • 선택된 데이터 파일들 중, 쿼리 조건에 맞는 삭제 파일(delete 파일) 또는 deletion vector가 있는지 판단
    • 적용 대상인지 여부: 파일 경로(file_path) 일치, partition 일치, sequence number 비교 등 (Spec에 정의됨)

Delete 파일 적용 범위 (Scope Rules)

삭제 파일이나 deletion vector를 데이터 파일에 적용해야 할 경우 다음 조건들을 봐요:

  • Deletion Vector:

    • 데이터 파일의 file_path == deletion vector의 referenced_data_file
    • 데이터 파일의 data sequence number ≤ deletion vector의 sequence number
    • 둘의 partition spec + partition 값(partition tuple) 동일

  • Position Delete 파일:

    • referenced_data_file (있다면) 및 file_path가 동일
    • 데이터 파일의 sequence number ≤ delete 파일의 sequence number
    • partition도 동일

  • Equality Delete 파일:

    • delete 파일의 sequence number > 데이터 파일의 sequence number
    • partition spec/partition 값 일치 또는 delete 파일이 unpartitioned spec이면 글로벌하게 적용 가능

기타 중요한 사항

  • Manifest 리스트(manifest list) 및 요약 정보 덕분에 많은 manifest 파일 읽는 비용 절감 가능
  • Partition 통계 + 컬럼 통계 + lower/upper bound들을 잘 설계하면 성능이 훨씬 향상됨
  • 쿼리에서 사용되는 필터(predicate)가 partition 필드 + non-partition 필드 혼합인 경우, partition 필터 먼저 적용 → 그 후 컬럼 통계 필터 순으로 적용하는 게 일반적임
  • Spec에서는 “inclusive projection”이라는 개념도 나와요: partition predicate이 “이 파일 안에 쿼리 조건을 만족하는 행(row)이 하나라도 있을 가능성”이 있는지를 허용하는 방식 → 일부 불필요한 파일까지 포함할 수 있지만, 전체 스캔 정확도를 지키는 방식임

퍼포먼스 문서 추가 참고사항

  • Iceberg 문서 Performance 항목에 따르면, 스캔 계획(scan planning)은 한번의 노드(node)에서 메타데이터 필터링만으로도 수행 가능하다는 점 강조됨. oai_citation:0‡Iceberg
  • Manifest list + partition value ranges를 사용해 manifest들을 먼저 필터(메타데이터만 보고) → 실제 manifest 내부 데이터 파일들 조사 → 이 단계 덕분에 latency & I/O 비용 절약 가능함. oai_citation:1‡Iceberg
  • 컬럼별 lower/upper bounds, null counts 등 통계(metrics)가 클수록 효과가 좋음. 특히 대형 테이블에서 수십/수백 기가바이트 이상의 데이터가 있을 때 manifest-level pruning이 매우 중요한 역할 함. oai_citation:2‡Iceberg

Delete Formats

Iceberg v2부터는 row-level deletes(행 단위 삭제)가 지원돼요.
v3에서는 Deletion Vector(DV)가 추가되고, Position Delete는 deprecated 되었어요.

삭제 포맷 종류

  1. Deletion Vectors (DV, v3 추가)
    • 특정 데이터 파일의 삭제된 행(row position)을 bitmap으로 관리
    • 효율적: Position Delete보다 실행 시 빠름
    • 각 데이터 파일에 대해 최대 하나의 DV만 허용
    • DV는 Puffin 파일 내부에 blob 형태(deletion-vector-v1)로 저장
    • 저장 시:
      • file_path: 데이터 파일의 경로
      • content_offset: DV blob 시작 위치
      • content_size_in_bytes: DV blob 전체 길이
    • DV가 존재하면 동일한 데이터 파일의 기존 Position Delete들은 무시 가능
  1. Position Delete Files (v2, v3에서 deprecated)
    • 파일 경로(file_path) + 행 위치(pos, 0부터 시작)로 삭제 행을 지정
    • 선택적으로 삭제된 행의 값(row struct) 포함 가능
    • Schema: 
      2147483546 file_path string   # 삭제 대상 데이터 파일 경로
2147483545 pos       long     # 삭제된 행의 위치
2147483544 row       struct<> # 삭제된 행 값 (선택)
    • 정렬 필요:
      • file_path → pos 순으로 정렬 (스캔 시 최적화)
    • v3에서는 새로 작성 불가, 기존 Position Delete는 DV로 변환 필요
  1. Equality Delete Files
    • 특정 컬럼 값이 일치하는 모든 행 삭제
    • equality_ids: 삭제 조건으로 쓰이는 컬럼 ID들
    • Schema는 테이블의 컬럼 일부를 포함할 수 있음
    • Null 값 허용: col IS NULL 조건처럼 동작
    • 조건은 컬럼 값 동일 → 행 삭제
    • 예시:
      • 테이블:
        id | category  | name
---|-----------|------
 1 | marsupial | Koala
 2 | toy       | Teddy
 3 | NULL      | Grizzly
 4 | NULL      | Polar
      • Delete id=3 → equality_ids=[1]
      • Delete id=4 AND category IS NULL → equality_ids=[1,2]

Delete File 공통 특성

  • Delete 파일도 일반 데이터 파일과 동일하게 Iceberg Data File 포맷 규칙을 따름
  • 따라서:
    • Avro / Parquet / ORC 등 Iceberg가 지원하는 포맷 사용 가능
    • 컬럼 ID 기반으로 필드 매핑
    • Manifest에 기록되어 추적됨
  • Delete 파일에도 데이터 파일과 동일하게 통계(metrics) 기록 가능
    • value count, null count, lower/upper bound 등
    • 이 통계를 사용해 불필요한 delete 파일도 pruning 가능

v2 vs v3 차이

  • v2
    • Position Delete + Equality Delete 지원
    • DV 없음
  • v3
    • DV 추가
    • Position Delete deprecated (새로 쓰면 안 됨)
    • DV는 같은 데이터 파일에 대해 하나만 가능
    • DV가 있으면 기존 Position Delete 무시 가능

요약

  • Equality Delete: 조건 기반 삭제 (col=value)
  • Position Delete: 행 위치 기반 삭제 (file+pos) → v3에서 deprecated
  • Deletion Vector: 효율적인 bitmap 삭제 방식, v3에서 추가

Table Metadata

Iceberg의 테이블 메타데이터는 JSON 파일로 저장되며,
각 변경(commit) 시마다 새로운 메타데이터 파일이 생성돼 원자적(atomic)으로 교체됨.
이 과정을 통해 테이블의 선형적 버전 히스토리를 보장하고, 동시에 커밋 충돌도 방지함.

Table Metadata Fields

버전필드설명
v1/v2/v3format-version테이블 포맷 버전 (1 또는 2, 3). 지원 불가능한 버전일 경우 예외 발생
v2/v3table-uuid테이블 UUID. 생성 시 부여되며, 변경 불가
v1/v2/v3location테이블 기본 경로. 데이터 파일, manifest, 메타데이터 파일 저장 위치
v2/v3last-sequence-number테이블 내 가장 큰 시퀀스 번호 (스냅샷 순서 추적용)
v1/v2/v3last-updated-ms마지막 업데이트 시각 (epoch ms)
v1/v2/v3last-column-id마지막으로 할당된 컬럼 ID
v1 (deprecated)schema현재 스키마 (단일 값, v2부터는 schemas 사용)
v2/v3schemas모든 스키마 목록 (schema-id 포함)
v2/v3current-schema-id현재 사용 중인 스키마 ID
v1 (deprecated)partition-spec현재 파티션 스펙 (단일 값)
v2/v3partition-specs모든 파티션 스펙 목록
v2/v3default-spec-id기본 사용 파티션 스펙 ID
v2/v3last-partition-id마지막으로 할당된 파티션 필드 ID
v1/v2/v3properties테이블 속성 (예: commit.retry.num-retries)
v2/v3current-snapshot-id현재 스냅샷 ID (main branch의 최신)
v2/v3snapshots유효한 스냅샷 리스트
v2/v3snapshot-log스냅샷 변경 이력 (timestamp + snapshot-id)
v2/v3metadata-log메타데이터 파일 변경 이력
v2/v3sort-orders정렬 순서 목록
v2/v3default-sort-order-id기본 정렬 순서 ID
v2/v3refs스냅샷 참조 (branches, tags)
v3statistics테이블 통계 파일 목록 (선택적)
v3partition-statistics파티션 통계 파일 목록 (선택적)
v3next-row-id다음에 할당될 row ID (Row Lineage용)
v3encryption-keys암호화 키 정보

Table Statistics

  • 통계 파일은 Puffin 포맷 사용
  • 필수 아님, 리더(reader)는 무시 가능
  • 필드:
    • snapshot-id: 스냅샷 ID
    • statistics-path: 통계 파일 경로
    • file-size-in-bytes: 통계 파일 크기
    • file-footer-size-in-bytes: Footer 크기
    • blob-metadata: 통계 블롭 정보
      • type: Blob 타입
      • snapshot-id, sequence-number: 생성된 시점
      • fields: 통계 계산에 사용된 필드 ID
      • properties: 추가 메타데이터

Partition Statistics

  • 각 파티션 튜플별 통계 저장
  • 스냅샷 당 최대 하나의 파티션 통계 파일 가능
  • 파일 형식: 데이터 파일 포맷(Parquet, ORC 등)
  • 필수 아님, 리더는 무시 가능
  • 스키마:
    • partition: 파티션 값 튜플
    • spec_id: 파티션 스펙 ID
    • data_record_count: 데이터 행 수
    • data_file_count: 데이터 파일 개수
    • total_data_file_size_in_bytes: 데이터 파일 총 크기
    • position_delete_record_count: position delete 기록 수
    • equality_delete_record_count: equality delete 기록 수
    • dv_count: deletion vector 개수
    • total_record_count: 삭제 적용 후 전체 레코드 수
    • last_updated_at: 마지막 업데이트 시각
    • last_updated_snapshot_id: 업데이트한 스냅샷 ID

주의: total_record_count는 equality delete나 v2 position delete가 있으면 정확히 알 수 없어서 NULL일 수 있음.
deletion vector만 있는 경우에는 계산 가능.

Encryption Keys

  • 테이블 암호화 키 목록 저장 가능
  • 스키마:
    • key-id: 키 식별자
    • encrypted-key-metadata: 암호화된 키 메타데이터 (base64)
    • encrypted-by-id: (선택) 키를 암호화한 상위 키 ID
    • properties: 추가 메타데이터

Row ID 관리

  • next-row-id는 반드시 현재 테이블에서 사용된 모든 row-id보다 커야 함
  • 새 스냅샷 생성 시:
    • added_rows_count + existing_rows_count 합산해 next-row-id 갱신
  • 안전한 방법:

Commit Conflict Resolution and Retry

Iceberg는 원자적 커밋(atomic commit) 모델을 사용하기 때문에
동시에 두 개의 커밋이 발생하면 충돌(conflict)이 생길 수 있음.
이 경우, 하나의 커밋만 성공하고 나머지는 실패 → 실패한 커밋은 새로운 메타데이터 버전으로 재시도(retry) 가능.

Retry 규칙

  • Append 연산

    • 조건 없음
    • 항상 새로운 버전에 적용 가능

  • Replace 연산

    • 삭제하려는 파일이 아직 테이블에 존재하는지 검증 필요
    • 예시:
      • 포맷 변경 (Avro → Parquet)
      • Compaction (여러 파일 → 하나의 파일)

  • Delete 연산

    • 특정 파일 삭제 시 → 해당 파일이 여전히 테이블에 있는지 확인 필요
    • 조건 기반 삭제 (예: WHERE timestamp < X)는 항상 재적용 가능

  • Schema 업데이트 & Partition spec 변경

    • 현재 스키마가 base 버전에서 변경되지 않았는지 확인 필요

File System Tables (Deprecated)

⚠️ v4에서 제거 예정.
객체 스토리지나 로컬 파일 시스템에서는 안전하지 않음.

  • HDFS 같은 파일 시스템에서 원자적 rename으로 커밋 구현
  • 저장 규칙:
    • 메타데이터 경로: <table-location>/metadata/v<V>.metadata.json
  • 커밋 절차:
    1. 현재 메타데이터 V 읽기
    2. V 기반 새 메타데이터 작성
    3. <random-uuid>.metadata.json 파일로 저장
    4. 해당 파일을 v<V+1>.metadata.json으로 rename
    5. rename 성공 → 커밋 성공
    6. rename 실패 → 다시 시도

Metastore Tables

  • 메타스토어(DB)에 테이블의 메타데이터 포인터를 저장하고 check-and-put으로 갱신
  • 커밋 절차:
    1. 현재 메타데이터 기반 새 버전 V+1 생성
    2. <V+1>-<random-uuid>.metadata.json 파일로 저장
    3. 메타스토어에서 포인터를 V → V+1로 교체 (check-and-put)
    4. 성공 시 → 커밋 완료
    5. 실패 시 → 다른 writer가 이미 V+1 생성 → 다시 시도

Delete Formats

Iceberg는 row-level delete를 지원 (v2 이상).

  • v2: Position deletes, Equality deletes
  • v3: Deletion vectors(DVs) 추가
  • v1: row-level delete 지원 없음

Delete 종류

  • Deletion vectors (DV) (v3)

    • 단일 데이터 파일 내에서 row position bitmap으로 삭제 표시
    • Puffin blob (deletion-vector-v1) 사용
    • 장점: Position delete 파일보다 효율적
    • 규칙:
      • 스냅샷당 데이터 파일별 최대 1개의 DV
      • 새로운 DV는 기존 position delete를 반드시 대체해야 함

  • Position delete files (v2, deprecated in v3)

    • (file_path, pos)로 삭제된 행 지정
    • 선택적으로 삭제된 행(row) 값 포함 가능
    • 정렬 규칙:
      • file_path → pos 순으로 정렬
      • 스캔 시 필터 최적화 가능

  • Equality delete files

    • 한 개 이상의 컬럼 값으로 삭제 행 지정
    • 예: id = 3, category IS NULL
    • null 매칭 지원 (col IS NULL)
    • delete column이 나중에 드롭돼도 기존 equality delete는 유지됨

Delete File Stats

  • Delete 파일도 manifest에 기록되며, Data 파일과 동일한 통계 구조 사용
  • 활용:
    • 삭제 파일도 row metrics를 저장
    • 불필요한 delete 파일 스캔 방지

요약

  • 커밋 충돌 시 대부분 재시도 가능 (조건 확인 필요)
  • 파일 시스템 기반 커밋은 deprecated, 메타스토어 기반 방식 권장
  • Delete 포맷:
    • v2: Position deletes + Equality deletes
    • v3: Deletion vectors 추가 (더 효율적)

Iceberg Spec — Schema Evolution

개요

Iceberg는 테이블의 스키마(schema)를 쉽고 안전하게 진화(evolution)시킬 수 있도록 설계되어 있어요.
스키마 변경은 대부분 메타데이터(metadata) 수준에서 이루어지고, 데이터 파일을 다시 쓰지 않아도 되는 경우가 많습니다. oai_citation:0‡Iceberg

지원되는 스키마 진화 종류

Iceberg가 지원하는 스키마 변경 유형은 다음과 같고, nested 구조 (struct 내부)도 가능해요. oai_citation:1‡Iceberg

변경 타입설명
Add새 컬럼 추가 (또는 nested struct 안에 새 필드) oai_citation:2‡Iceberg
Drop기존 컬럼 또는 struct 안의 필드 제거 oai_citation:3‡Iceberg
Rename기존 컬럼/필드 이름 변경 (nested struct 포함) oai_citation:4‡Iceberg
Reorder컬럼/필드의 순서 변경 (예: struct 내, 또는 전체) oai_citation:5‡Iceberg
Type promotion / Update컬럼 타입 넓히기(widening) 등, struct 내부, map key/value, list element 등에서도 지원됨. 예: int → long, float → double, decimal 정밀도 늘리기 등. oai_citation:6‡AWS Documentation

정확성(Correctness) 보장

스키마 진화를 통해도 기존 데이터가 영향을 받지 않고, 예기치 않은 side-effect가 없도록 다음을 보장함: oai_citation:7‡Iceberg

  1. 새로 추가된 컬럼은 기존 컬럼의 값을 읽지 않음
  2. 컬럼을 삭제(drop)해도 다른 컬럼 값에는 영향 없음
  3. 컬럼 타입 변경(type promotion) 또는 필드 업데이트 시에도 다른 컬럼 값에는 영향 없음
  4. 컬럼/필드 순서 변경(reorder) 시에도 이름(name)으로 매핑되므로 값의 의미(컬럼 + 이름)가 보존됨 oai_citation:8‡Iceberg

기술적 세부사항 / 제약

  • Iceberg는 컬럼 ID (field-id) 기반으로 컬럼을 추적. 이름(name)은 변경 가능하지만 컬럼 ID가 유지됨으로써 진화 시 정합성 유지됨. oai_citation:9‡Iceberg
  • Map 키(map key) 타입의 경우, struct 필드를 추가하거나 제거(drop)할 때 “equality” 연산(equality of map key) 결과가 변경되는 일이 발생하면 허용하지 않음. oai_citation:10‡Iceberg
  • 스키마 진화는 “메타데이터 변경(metadata-only)”으로 이루어지므로, 기존 데이터 파일(data files)을 새 형식으로 다시 쓰는(rewrite) 비용이 들지 않음. oai_citation:11‡Iceberg

관련 진화 (Partition / Sort Order 진화)

  • Partition Spec 진화: 파티션 스펙(partition spec)을 바꿀 수 있음. 예: 기존에는 day(ts), 나중엔 hour(ts) 같은 변경. 기존 데이터를 가진 매니페스트들은 기존 파티션 스펙으로 계속 유지됨. 새 쓰는 데이터(new writes)만 새 스펙 적용됨. oai_citation:12‡Iceberg
  • Sort Order 진화: 정렬 순서(sort order)도 변경 가능. 기존 데이터는 기존 순서 유지됨. 새로 쓰는 데이터가 새 기본(sort order) 사용하거나 정렬 안함(unsorted) 선택 가능함. oai_citation:13‡Iceberg

예시 사용 (Athena / ALTER TABLE 등)

예: Amazon Athena에서는 아래와 같은 DDL 문으로 진화 가능함: oai_citation:14‡AWS Documentation

ALTER TABLE my_table ADD COLUMN new_col STRING;
ALTER TABLE my_table DROP COLUMN old_col;
ALTER TABLE my_table RENAME COLUMN colA TO colB;
ALTER TABLE my_table CHANGE COLUMN colX TYPE BIGINT;  -- 타입 넓히기
profile
Q
Data Engineer
다음 포스트

Iceberg (partition, scheme evolution)

0개의 댓글