실시간 분석 파이프라인 구축 - 02. Iceberg 주요 기능 소개

Iceberg의 주요 기능을 소개하고 Delta-lake, Hudi와 비교하여 소개합니다.

이전에 설치한 Docker Compose에는 Iceberg의 예시 실행 Jupyter 노트북도 함께 포함되어 있습니다. 해당 파일을 기반으로 실습하며 설명하겠습니다.(https://jongwho.tistory.com/37)

 

Spark 실행 시작

from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("Jupyter").getOrCreate()

spark

-- 테이블 생성
CREATE DATABASE IF NOT EXISTS nyc

 

데이터 로드 및 테이블 생성

df = spark.read.parquet("/home/iceberg/data/yellow_tripdata_2021-04.parquet")
df.write.saveAsTable("nyc.taxis")

PySpark를 사용한 테이블 데이터 확인

df.show(n=10, truncate=False, vertical=True)

컬럼 및 값 예시

 

 

🔑 Iceberg의 주요 기능

1. ✅ 스키마 진화(Schema Evolution)

Iceberg는 기존 데이터를 변경하지 않고도 테이블의 스키마를 유연하게 변경할 수 있습니다.

• 컬럼 추가, 이름 변경, 순서 변경이 모두 안전하게 가능
• 내부적으로 field ID를 사용해, 순서와 무관하게 데이터를 인식

📌 예시:

-- 컬럼 변경
ALTER TABLE nyc.taxis RENAME COLUMN fare_amount TO fare
ALTER TABLE nyc.taxis RENAME COLUMN trip_distance TO distance

-- 코멘트 추가
ALTER TABLE nyc.taxis ALTER COLUMN distance COMMENT 'The elapsed trip distance in miles reported by the taximeter.'

-- 타입 변경
ALTER TABLE nyc.taxis ALTER COLUMN distance TYPE double;

-- 컬럼의 순서 변경: 테이블 조회 시 표시되는 컬럼의 위치를 변경합니다. distance 뒤에 fare 컬럼을 보여줍니다.
ALTER TABLE nyc.taxis ALTER COLUMN distance AFTER fare;

-- 컬럼 추가: 기존 HDFS와 다르게 컬럼을 추가해도 nulㅣ 값으로 우선 추가됩니다.
ALTER TABLE nyc.taxis
ADD COLUMN fare_per_distance_unit float AFTER distance

-- 추가한 컬럼에 값을 설정합니다.
UPDATE nyc.taxis
SET fare_per_distance_unit = fare/distance

 

 

🧠 왜 중요한가요?
기존 Hive 테이블은 스키마 변경 시 전체 데이터를 재작성하거나 불안정한 동작을 유발할 수 있지만,
Iceberg는 명시적 메타데이터 관리로 데이터 정합성을 유지하며 스키마 변경을 지원합니다.

 

2. 🧭 Time Travel

Iceberg는 이전 시점의 데이터를 그대로 조회할 수 있는 기능을 제공합니다.
모든 데이터 변경은 스냅샷 단위로 기록되며, 특정 snapshot ID 또는 timestamp로 이전 상태를 조회할 수 있습니다.

📌 예시:

-- 테이블의 히스토리 조회
SELECT * FROM nyc.taxis.history

 

fare_per_distance_unit 컬럼을 추가하여 스냅샷이 생긴것을 확인할 수 있습니다.

 

 

original_snapshot = df.head().snapshot_id
spark.sql(f"CALL system.rollback_to_snapshot('nyc.taxis', {original_snapshot})")
original_snapshot

원본 Snapshot id(259~)로 원복하고 데이터를 확인해보면 fare_per_distance_unit 데이터가 없는 것을 확인할 수 있습니다.

 

🔍 Iceberg Snapshot이 생성되는 조건은?

• 테이블에 데이터 변경(삽입, 수정, 삭제)이 발생할 때마다 새로운 스냅샷이 생성됩니다.
  예를 들어, 테이블에 새로운 행을 추가하거나 기존 데이터를 수정 또는 삭제하는 DML 작업이 실행되면 Iceberg는 자동으로 새로운 스냅샷을 만들어 해당 시점의 테이블 상태를 기록합니다.
• 스냅샷은 Iceberg의 commit 작업이 발생할 때마다 생성됩니다.
  데이터가 테이블에 반영되는 commit 시점마다 테이블의 전체 상태를 나타내는 스냅샷이 만들어집니다. 이 commit에는 단순한 데이터 삽입뿐 아니라, overwrite, delete, update 등 모든 데이터 변경 작업이 포함됩니다.
• 스냅샷은 테이블 메타데이터의 변경(예: 스키마 변경, 파티션 변경)에도 생성될 수 있습니다.
  스키마 변경이나 파티션 구조 변경 등 테이블 구조에 영향을 주는 작업도 새로운 스냅샷을 생성하는 트리거가 됩니다(일반적으로 메타데이터 commit이 발생하는 경우).

🧠 활용 예시

• 잘못된 업데이트 복구
• 히스토리 비교
• 시점 기반 분석 (과거 상태 분석)

3. 📂 자동 파티셔닝 (Hidden Partitioning)

Iceberg는 사용자가 직접 파티셔닝 디렉토리를 신경 쓰지 않아도 되도록 설계되었습니다. 파티션을 테이블 정의에만 선언하면 내부적으로 자동으로 파티션 디렉토리를 관리해줍니다.

📌 예시:

ALTER TABLE nyc.taxis
ADD PARTITION FIELD VendorID

 

🧠 장점

• 사용자는 파티셔닝을 의식하지 않고 SQL만으로 작업 가능
• 복잡한 디렉토리 설계 없이도 쿼리 성능 최적화 가능
• 파티션 컬럼이 변경되어도 이전 파티션이 무효화되지 않음

4. 🔄 ACID 트랜잭션 완벽 지원

Iceberg는 모든 데이터 조작을 스냅샷 기반의 트랜잭션 단위로 처리합니다. 여러 작업이 동시에 이루어져도 충돌 없이 안전하게 병합됩니다.

🧠 실무에서 중요한 이유

• 배치 & 스트리밍 파이프라인을 동시에 운영할 때 충돌 없음
• Spark, Flink, Trino 등 다양한 엔진에서 안전하게 병렬 작업 가능

5. 🧱 스냅샷(Snapshot) 기반 메타데이터 관리

Iceberg는 변경이 일어날 때마다 스냅샷을 생성하고, 모든 테이블의 상태는 메타데이터 파일로 관리됩니다.

SELECT snapshot_id, manifest_list
FROM nyc.taxis.snapshots

minio에 존재하는 snap-xx 데이터

💡 스냅샷 구성 요소:

• metadata.json: 테이블 구조, 스냅샷 목록
• manifest list: 어떤 manifest 파일이 포함되었는지
• manifest file: 어떤 데이터 파일이 어떤 파티션에 있는지

🧠 왜 이게 중요할까?

• 테이블을 재작성하지 않고도 버저닝과 롤백 가능
• 테이블 상태를 경량화된 메타데이터로만 관리 가능
• 객체 스토리지 환경(S3, GCS 등)에 최적화

6. 🚀 멀티 엔진 호환성

Iceberg는 다양한 엔진에서 동일한 테이블 포맷을 공유할 수 있도록 설계되었습니다.

• Spark
• Trino / Presto
• Flink
• Hive (일부 제한적)

🧠 하나의 테이블을 여러 엔진에서 병렬로 접근할 수 있다는 점은 데이터 파이프라인 아키텍처를 훨씬 유연하게 만들어줍니다.

7. 📉 쿼리 최적화 기능: Pruning & Pushdown

Iceberg는 쿼리 성능을 높이기 위한 다양한 기능을 내장하고 있습니다:

• Column Pruning: 필요한 컬럼만 읽음
• Partition Pruning: 조건에 따라 파티션 스캔 최소화
• Predicate Pushdown: 쿼리 조건을 스토리지 레벨로 전달

이러한 최적화는 내부의 파일 수준 메타데이터 덕분에 가능합니다.

🔁 Iceberg vs Delta Lake vs Hudi 비교

기능IcebergDelta LakeHudi

 

	Iceberg	Delta-Lake	Hudi
ACID 트랜잭션	✅	✅	✅
Time Travel	✅	✅	제한적
Schema Evolution	✅ (안정적)	✅	✅
파티셔닝 추상화	✅ (자동 파티셔닝)	❌	❌
멀티엔진 지원	✅ (Spark, Trino, Flink 등)	Spark 중심	Flink 중심
스냅샷 메타데이터	✅ (독립적 구조)	제한적	제한적
실시간 스트리밍 적합성	✅	❌	✅