Apache Iceberg는 대규모 데이터 세트를 효율적으로 관리하고 처리하기 위한 오픈 소스 테이블 형식이다. Apache Iceberg는 전통적인 RDBMS(Relational Database Management System)를 대체하는 기술이 아니라, 데이터 레이크 환경에서 테이블 관리를 최적화하는 기술이다. Apache Iceberg는 HDFS, S3 같은 데이터 레이크에 저장된 파일을 RDBMS처럼 테이블 단위로 관리할 수 있도록 해준다. 전통적인 데이터 레이크는 파일 시스템 수준에서 데이터를 관리하는 반면, Iceberg는 데이터를 테이블처럼 다룰 수 있도록 하는 계층을 추가한다. Iceberg가 없으면 데이터 레이크는 단순한 파일 저장소이다. Iceberg는 여기에 트랜잭션, 스키마 진화, 시간 여행(Time Travel, 특정 시점으로 데이블 롤백) 등의 기능을 추가하여 RDBMS와 유사한 방식으로 다룰 수 있게 한다.
스키마 진화(Schema Evolution) 는기존 데이터를 유지하면서 테이블의 스키마(구조)를 변경할 수 있는 기능이다. 즉, 데이터를 삭제하거나 변환하지 않고도 새로운 열을 추가하거나, 이름을 변경하는 등의 작업을 수행할 수 있다.
시간 여행(Time Travel) 이란, 과거 특정 시점의 데이터 상태를 그대로 조회하거나 복원할 수 있는 기능이다. 즉, 데이터가 변경되었더라도 Iceberg 테이블을 이전 상태로 되돌리거나, 특정 시점의 데이터를 다시 조회할 수 있다.
단독 사용이 불가하니 Spark, Flink, Trino 같은 데이터 처리 엔진과 결합하여 사용해야 하며, 기존 RDBMS를 대체하기보다는 데이터 레이크 및 빅데이터 분석을 최적화하는 역할을 한다. RDBMS에는 핵심 트랜잭션 데이터를 저장하고, Iceberg에는 대용량 분석 데이터를 저장하는 방식이다. Iceberg는 데이터 자체를 저장하는 시스템이 아니라, 데이터를 효율적으로 관리할 수 있도록 도와주는 메타데이터 계층 기술이므로, Spark, Flink 같은 대규모 데이터 처리 엔진뿐만 아니라 Rust, Java 같은 일반 프로그래밍 언어에서도 Iceberg 테이블을 읽고 쓸 수 있다. Iceberg는 다양한 엔진(Spark, Flink, Trino, Presto 등)에서 사용되지만, 버전이나 포맷이 다를 경우 충돌 가능성이 있다. v1과 v2 두 가지 포맷 버전이 있으며, 기본적으로 최신 기능을 사용하려면 v2로 설정하는 것이 좋다.
Iceberg는 S3, HDFS 같은 오브젝트 스토리지에서 데이터를 관리하기 때문에, 기반 스토리지의 성능이 Iceberg의 성능에 직접적인 영향을 미칠 수 있다.
이러한 문제를 최소화하기 위해 여러 가지 최적화 기법을 제공한다.
| 주요 이슈 | 설명 |
|---|---|
| 파일 크기 최적화 (Small Files) | 작은 파일이 많으면 메타데이터 부하 증가 및 성능 저하 발생 |
| 데이터 스캔 범위 (Pruning) | Iceberg의 파티션/스냅샷 기능이 비효율적으로 동작하면 불필요한 데이터 스캔 발생 |
| Object Storage Latency | S3는 네트워크 기반 스토리지이므로, 지연 시간이 높은 경우 쿼리 성능 저하 가능 |
| Metadata Operation 비용 | Iceberg는 많은 메타데이터(Manifest, Snapshot)를 다루므로, HDFS NameNode 부하 증가 가능 |
| Compaction (데이터 파일 병합) 비용 | 소규모 파일이 많으면 Compaction 작업이 필요하며, 리소스를 많이 소모할 수 있음 |
| 스냅샷 증가로 인한 성능 저하 | 스냅샷이 많아질수록 조회 성능이 저하될 가능성이 있음 (정기적인 스냅샷 정리 필요) |
| S3 List Operation 비용 | S3에서 파일 목록을 가져오는 작업(ListObjects)이 많으면 API 호출 비용과 지연 시간 증가 |
| 클러스터 리소스 사용량 | Spark/Flink에서 많은 Iceberg 테이블을 다룰 경우 CPU/메모리 사용량이 증가할 수 있음 |
| Write Amplification | Iceberg의 업데이트/삭제 작업이 다수의 파일 재작성(rewrite)을 유발하여 성능 저하 가능 |
| 파일 포맷 최적화 | Iceberg는 Parquet, ORC, Avro 포맷을 사용하므로, 포맷에 따른 성능 차이가 발생 가능 |
write.target-file-size-bytes 설정 조정 rewrite_data_files 명령어를 활용하여 파일 병합 자동화 기술에 밝은 개발자가 더 적합하지만, 운영자의 데이터 관리 경험도 필요하다.
즉, 개발자와 운영자의 역할을 결합한 데이터 엔지니어(Data Engineer) 또는 데이터 플랫폼 운영자(DataOps)가 가장 적합하다.
Iceberg를 제대로 운영하려면 개발자 + 운영자 역량을 모두 갖춘 데이터 관리자가 필요하다.
| 비교 항목 | Iceberg 운영 (데이터 레이크) | RDBMS DBA (전통적 데이터베이스) |
|---|---|---|
| 데이터 저장 방식 | S3, HDFS, GCS 같은 오브젝트 스토리지 사용 | 로컬 디스크 또는 SAN/NAS 기반 스토리지 사용 |
| 테이블 포맷 | Iceberg, Delta Lake, Hudi 등 파일 기반 테이블 | MySQL, PostgreSQL, Oracle 등 전통적 테이블 |
| 트랜잭션 처리 | Snapshot Isolation (Multi-Version 방식) | ACID 트랜잭션 (즉시 커밋 기반) |
| 스키마 변경 (Schema Evolution) | 컬럼 추가/삭제, 타입 변경이 유연함 | 제약 조건이 많고, 다운타임이 필요할 수도 있음 |
| 데이터 업데이트 | Copy-on-Write (COW) 또는 Merge-on-Read (MOR) 방식 | 직접 업데이트 (UPDATE, DELETE) |
| 데이터 쿼리 엔진 | Spark, Flink, Trino, Presto, Athena | MySQL, PostgreSQL, Oracle, MSSQL |
| 인덱싱 방식 | Partitioning, Z-ordering, Bloom Filter 활용 | B-Tree, Hash Index, Full-Text Index 등 |
| 백업 & 복구 | 스냅샷 기반 롤백 (rollback_to_snapshot) | WAL(Write-Ahead Logging), Point-in-Time Recovery |
| 데이터 관리 | 주기적인 Compaction 및 GC 필요 | 자동 Vacuum 또는 테이블 유지 관리 |
| 운영 도구 | Trino, Presto, DBeaver, Spark UI | MySQL Workbench, pgAdmin, SQL Developer |
| 운영자가 수행하는 작업 | 스토리지 최적화, 쿼리 성능 튜닝, 데이터 청소(Compaction) | 인덱스 튜닝, 쿼리 최적화, 데이터 백업 관리 |
| 적용 사례 | 대규모 데이터 레이크 (Data Lakehouse) | OLTP 및 소규모 데이터베이스 |
| 대표적인 사용처 | Netflix, AWS, Snowflake, Databricks | 은행, ERP 시스템, 트랜잭션 중심 애플리케이션 |
운영자가 Iceberg 테이블을 SQL로 조회하려면 Trino, Athena, DBeaver 같은 툴을 사용해야 한다.
Trino는 Iceberg 테이블을 SQL로 조회할 수 있는 강력한 쿼리 엔진이다.
SELECT * FROM iceberg.default.users WHERE created_at >= '2024-01-01';