[Spark] Apache Iceberg

Apache Iceberg

Apache Iceberg는 아파치 재단의 오픈 소스 테이블 포맷(table format) 프로젝트임.

대규모 데이터 레이크에서 테이블 단위의 관리와 ACID(원자성, 일관성, 격리성, 내구성) 트랜잭션을 안정적으로 지원하기 위해 설계됨.

Iceberg는 기존에 많이 쓰이던 Hadoop/Hive 테이블 포맷이 갖는 문제점(예: 수많은 작은 파일이 생기는 문제, 스키마 진화와 파티셔닝의 유연성 부족, 트랜잭션 동시성 문제 등)을 해결하고자 도입됨.

특히 Spark, Trino, Flink, Presto 등 다양한 엔진과의 연동이 활발하며, 데이터 레이크 상에서 DW(데이터 웨어하우스)에 준하는 기능을 제공하는 것을 목표로 하고 있음.

 

Iceberg의 핵심 설계 목표

1. 정확한 스냅샷/버저닝(Snapshot & Versioning)

Iceberg는 테이블을 ‘스냅샷’ 단위로 추적함.

새로운 데이터가 커밋되면 새로운 스냅샷이 생성되고, 이전 스냅샷들은 그대로 유지되므로 시점 복구(time travel)나 롤백이 가능함.

이를 통해 데이터 레이크 환경에서도 ACID에 준하는 일관성과 트랜잭션 보장을 받음.

 

2. 메타데이터 계층의 확장성

테이블에 대한 모든 메타데이터를 ‘메타데이터 파일(Manifest, Manifest List 등)’에 저장하고, 파일 이름 혹은 경로를 통한 구별 대신 매니페스트 리스트를 통해 파티셔닝 및 파일 상태를 관리함.

수십억 건의 레코드(또는 수십만 개의 파일)를 관리하더라도 메타데이터 구조를 효율적으로 설계하여 성능에 영향을 최소화함.

 

3. 유연하고 효율적인 파티셔닝

Iceberg는 “Hidden Partitioning” 개념을 통해 파티션 열을 명시적으로 드러내지 않고도 내부적으로 최적화된 파티셔닝 스키마를 유지할 수 있음.

또한, 스냅샷 기반 설계로 인해 파티션 구조를 변경하더라도 과거 데이터와 충돌 없이 자연스럽게 스키마와 메타데이터를 확장·진화할 수 있음.

 

4. ACID 트랜잭션 보장

고성능 분산 스토리지(HDFS, S3, ADLS 등) 위에서 동시(Concurrent) 작업이 수행되어도, Iceberg는 원자적 커밋을 유지함.

Optimistic Concurrency Control 방식을 통해 여러 작업자가 동시에 테이블을 읽고 쓰는 경우에도 충돌을 최소화하며, 충돌 발생 시 재시도나 롤백이 가능함.

 

5. Open Table Format

프로토콜이 개방되어 있으므로 Spark, Flink, Trino, Presto 등 다양한 엔진이 Iceberg 테이블을 인식하고 직접 읽고 쓸 수 있음.

ORC, Parquet, Avro 등 다양한 파일 포맷을 지원하고, 확장성을 가지는 스키마 진화를 지원함.

 

아키텍처 상세

1. 메타데이터 구조

Iceberg 테이블은 크게 다음과 같은 메타데이터 계층을 갖음.

 

1-1. 메타데이터 파일(Table Metadata File)

Iceberg 테이블의 전체 정보를 관리하는 JSON 파일임.

테이블의 스냅샷 리스트, 현재 활성 스냅샷의 ID, 스키마 버전, 파티션 스펙 등 중요한 전역 정보를 포함함.

새 스냅샷이 추가될 때마다 이 JSON 파일이 새 버전으로 기록됨.

 

1-2. 스냅샷(Snapshot)

스냅샷 ID, 생성 시각, 참조 중인 매니페스트 리스트 경로, 이전 스냅샷 ID 등을 포함함.

한 스냅샷은 여러 개의 매니페스트 리스트를 가리킬 수 있고, 각 스냅샷은 ‘불변(Immutable)’이므로 변경되지 않으며, 버저닝이 가능해짐.

 

1-3. 매니페스트 리스트(Manifest List)

해당 스냅샷에 속한 여러 매니페스트 파일들을 가리키는 리스트임.

매니페스트마다 어떤 파티션 범위의 데이터를 담고 있는지, 어떤 파일(예: Parquet 파일)을 참조하는지 등이 요약되어 있음.

 

1-4. 매니페스트(Manifest) 파일

물리적인 데이터 파일(Parquet, ORC 등)의 목록을 저장함.

각 데이터 파일의 파티션 정보, 파일 크기, 레코드 수, min/max 통계 등을 포함하고 있음.

이러한 통계 정보 덕분에 Iceberg는 프룬(prune) 작업으로 불필요한 파일 스캔을 줄일 수 있음.

 

1-5. 데이터 파일(Data Files)

실제 페이로드(테이블의 레코드들)를 저장하는 파일임.

Iceberg는 일반적으로 컬럼형 포맷(Parquet, ORC, Avro 등)을 사용함.

 

이러한 계층 구조 덕분에 테이블의 모든 버전 히스토리에 대해 관리할 수 있으며, 특정 시점의 스냅샷을 참조하여 시점 기반 질의(time travel query)를 수행할 수 있음.

 

2. 커밋/트랜잭션 과정

Iceberg에서는 새로운 데이터를 테이블에 추가하거나 스키마를 변경하는 등 테이블 상태가 변경되는 시점에 “트랜잭션”으로 묶어 커밋이 발생함.

커밋 과정은 크게 다음과 같음.

 

2-1. 새로운 스냅샷 생성

새로운 매니페스트 혹은 매니페스트 리스트를 작성하고, 해당 스냅샷을 가리키는 아이디(ID)와 함께 스냅샷 객체를 생성함.

 

2-2. Optimistic Concurrency Control (낙관적 동시성 제어)

실제로 병렬 작업이 있을 때, 동시에 커밋이 일어나면 마지막에 Commit하는 트랜잭션이 실패하거나(충돌 발생 시) 재시도하도록 함.

커밋 시점에 “현재 테이블 메타데이터 파일”의 최신 버전을 기반으로 예상이 맞는지(=중간에 다른 커밋이 변경하지 않았는지) 비교하고, 다르면 재시도 또는 충돌 처리를 수행함.

 

2-3. 원자적 갱신

커밋이 완료되면 테이블 메타데이터 파일의 버전이 새롭게 갱신되어, 활성 스냅샷(가장 최신 버전)이 바뀜.

메타데이터 파일 갱신(업데이트)은 하나의 원자적(atomic) 작업으로 처리되어, 도중에 실패가 발생하면 재시도하거나 롤백을 진행함.

 

이러한 과정으로 여러 엔진이 동일한 테이블에 대해 동시에 작업하더라도 데이터 정합성과 일관성을 보장할 수 있음.

 

주요 기능

1. 스키마 진화(Schema Evolution)

Iceberg는 기존 Hive 테이블 등에서 어렵거나 제한적으로만 가능하던 스키마 진화를 유연하고 안정적으로 지원함.

예를 들어, 컬럼 추가, 컬럼 이름 변경, 컬럼 삭제 등 스키마 변경이 과거 데이터와 호환되도록 처리됨.

(단, 컬럼 타입 변경 등은 호환성이 제한될 수 있음).

이러한 진화를 할 때도 별도의 테이블 재생성 없이 Iceberg의 메타데이터 계층만 업데이트하기 때문에 속도가 매우 빠르고, 다운타임이 적음.

 

2. 파티셔닝 전략

Iceberg는 물리 파티션(날짜별, 범위별, 버킷별 등)을 정의하는 대신, 파티션 스펙(Partition Spec)을 통해 추상화된 파티션 규칙을 저장함.

예를 들어, PARTITION BY days(ts) 처럼 타임스탬프에서 날짜만 추출하는 함수를 적용할 수 있으며, 나아가 hidden partitioning으로 사용자가 별도로 파티션 컬럼을 생성할 필요 없이 Iceberg가 내부적으로 관리할 수 있음.

이러한 전략은 파티션 스캔 범위 프룬(pruning)을 효율적으로 하도록 돕고, 파티션 스키마를 변경하더라도 과거 스냅샷을 깨뜨리지 않음.

 

3. Merge-on-Read / Copy-on-Write

Iceberg 자체는 Merge-on-Read(MOR)와 Copy-on-Write(COW) 기법을 모두 지원할 수 있도록 설계되어 있음.

Copy-on-Write: 새로운 파티션(파일)을 다시 작성하여 교체하는 방식으로, 쌓이는 작은 파일을 주기적으로 컴팩션(compaction)해서 관리함.

Merge-on-Read: 즉각적으로 작은 단위의 델타 파일(또는 delete 파일)을 작성하고 쿼리 시점에서 데이터 파일과 합쳐서 조회함.

Iceberg는 “Equality Delete”, “Position Delete” 등의 메커니즘을 통해 일부 레코드만 삭제 또는 업데이트하는 연산도 지원함.

 

4. 시점 복구(Time Travel)

Iceberg는 모든 스냅샷 히스토리를 관리하므로, 특정 시점에 대한 스냅샷 ID로 쿼리를 실행하면 과거 상태를 그대로 조회할 수 있음.

SELECT ... FROM table FOR SYSTEM_TIME AS OF ... 또는 특정 스냅샷 ID를 지정하는 식으로 각 엔진에서 지원함.

데이터 품질 보증(Test)이나 버그 트래킹, 감사(Audit) 작업 시 매우 유용함.

 

장단점 및 고려사항

1. 장점

1-1. 메타데이터 성능 최적화

수많은 파일을 가진 대형 테이블에서도 매니페스트-매니페스트 리스트 계층화 덕분에 고성능 쿼리를 수행할 수 있음.

 

1-2. ACID 트랜잭션 보장

데이터 레이크 환경에서 되돌리기(rollback), 동시성, 원자적 커밋 등이 보장됨.

 

1-3. 스키마/파티션 진화의 유연성

복잡한 ETL 워크플로와 비즈니스 요구사항 변화에 대응하기 쉬움.

 

1-4. 엔진 독립성

Iceberg 포맷이 개방되어 있어 Spark, Trino, Presto, Flink, Hive 등 다양한 엔진에서 통합 지원함.

 

1-5. 시점 조회(Time Travel)

과거 데이터 상태를 쉽게 복원하거나 분석할 수 있음.

 

2. 단점 및 주의사항

2-1. 메타데이터/매니페스트 관리 비용

스냅샷, 매니페스트 파일이 쌓이면서 메타데이터가 비대해질 수 있으므로 주기적인 정리(expire_snapshots, clean_orphan_files 등)가 필요함.

 

2-2. 엔진 호환성 버전

Spark나 Trino, Flink 등 엔진별로 Iceberg를 지원하는 버전과 기능 범위가 다를 수 있어, 환경 구성 시 호환성 체크가 필수임.

 

2-3. 쓰기/컴팩션 부하

Merge-on-Read 방식에서 많은 업데이트/삭제가 자주 일어나는 경우, 읽기 시점 병합(merge) 비용이 커질 수 있음.

Copy-on-Write 방식에서는 대규모 rewrite 비용이 발생할 수 있으므로, 워크로드 특성에 맞는 전략이 필요함.

 

2-4. 적절한 파티셔닝 설계 필요

Iceberg가 자동으로 파티션을 관리해주지만, 실제 쿼리 패턴에 맞는 파티셔닝 및 정기적인 최적화가 요구됨.

 

주요 사용 사례 및 연동

1. Spark 환경

Spark 3.0+ 버전부터 Iceberg를 표준 Catalog API로 간편하게 연동할 수 있음.

Spark SQL 구문(CREATE TABLE, INSERT, ALTER TABLE 등)을 그대로 사용하면서, Catalog를 Iceberg로 설정하면 내부적으로 Iceberg의 테이블 포맷이 적용됨.

대규모 배치 처리나 스트리밍 처리 모두 지원 가능하며, spark-sql 콘솔을 통해 과거 스냅샷 쿼리도 가능함.

 

2. Trino(Facebook Presto)

Trino(구 PrestoSQL)는 Iceberg 커넥터를 통해 Iceberg 테이블을 직접 생성, 조회, 관리할 수 있음.

Data Lakehouse 시나리오에서 분석 쿼리 엔진으로 Trino를 활용하는 경우 Iceberg가 메인 테이블 포맷으로 쓰이는 경우가 늘고 있음.

 

3. Flink 환경

Flink의 스트리밍 데이터를 Iceberg 테이블로 실시간 적재 가능하며, Flink SQL로 Iceberg 테이블에 upsert, delete 작업을 수행할 수도 있음.

체계적인 CDC(Change Data Capture) 파이프라인을 구축하는 용도로도 활용될 수 있음.

 

4. Hive 메타스토어 연동

기존 Hive 메타스토어를 사용해 Iceberg 테이블 위치와 스키마 정보를 저장할 수 있음.

그러나 “Hive 테이블 포맷”과 “Iceberg 테이블 포맷”은 다르므로, 변환 혹은 별도 Catalog로 구분하는 것이 일반적임.

 

운영 및 모니터링 팁

1. 스냅샷 만료(Expire Snapshots)

오래된 스냅샷을 일정 주기마다 정리(expireSnapshots)하여 메타데이터와 데이터 파일도 삭제(removeOrphanFiles)해야 스토리지 비용과 목록 조회 성능을 관리할 수 있음.

 

2. 파일 컴팩션(Compaction)

많은 작은 파일이 누적되면 쿼리 성능에 영향을 줄 수 있음.

Iceberg의 Copy-on-Write 방식이나 MERGE 같은 기능을 활용해 큰 파일로 합치는 작업을 정기적으로 수행하는 것이 좋음.

 

3. 메타데이터 캐싱

매니페스트 파일이나 매니페스트 리스트에 대한 캐싱 전략을 잘 구성하면 리스팅 및 프룬 단계의 성능을 크게 높일 수 있음.

 

4. 데이터 레이아웃 최적화

파티셔닝 스펙, 정렬(클러스터링) 컬럼 등을 주기적으로 점검해, 실제 쿼리 패턴이나 필터와 잘 맞는지 모니터링함.

 

정리

Apache Iceberg는 기존의 Hive 테이블 포맷이 가진 한계를 극복하고, 데이터 레이크 환경에서 DW 수준의 ACID 트랜잭션, 시점복구, 스키마 진화 등을 지원하기 위해 고안된 혁신적인 테이블 포맷임.

스냅샷 중심의 메타데이터 설계 덕분에 동시성 제어와 버저닝, 시점 쿼리를 유연하게 처리할 수 있으며, Parquet, ORC, Avro 등 다양한 파일 형식을 지원하여 많은 빅데이터 엔진과도 자연스럽게 연동 가능함.

특히 Spark, Trino, Flink 등에서 기존 SQL 문법과 유사한 방식으로 Iceberg 테이블을 생성·조회할 수 있고, Merge-on-Read/Copy-on-Write 등 다양한 업데이트 기법을 지원하여 범용적인 데이터 레이크하우스(Data Lakehouse) 아키텍처의 핵심으로 자리매김했음.

 

운영 환경에서 Iceberg를 안정적으로 유지·관리하기 위해서는 주기적인 스냅샷 청소와 파일 컴팩션, 메타데이터 최적화, 엔진 호환성 관리 등이 필수적임.

워크로드 특성에 맞춰 적절한 파티셔닝 전략과 트랜잭션 모델(MOR/COW)을 선택함으로써, 대규모 데이터에도 뛰어난 성능과 유연성을 확보할 수 있음.

결국 Apache Iceberg는 클라우드 네이티브 데이터 레이크를 한 단계 발전시켜, 대규모 분석·ETL·BI·머신러닝 워크로드를 통합적으로 처리하는 모던 데이터 아키텍처의 핵심 요소로 부상하고 있음.