[iceberg] 2025년 아이스버그의 한계 요약 (Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025)

 

https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025 | Apache Iceberg Practical Limitations in 2025

 

chatgpt 요약

 

Quesma의 블로그 글 "Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025"에서는 Apache Iceberg의 실용적인 한계점들을 다루고 있습니다. 주요 내용을 요약하면 다음과 같습니다:(quesma.com)

---

1. 소규모 데이터 환경에서의 비효율성

Apache Iceberg는 Netflix에서 페타바이트 규모의 대규모 데이터를 처리하기 위해 설계되었습니다. 그러나 현재 많은 조직들은 100GB 미만의 데이터 웨어하우스를 운영하고 있으며, 핵심 데이터셋은 수 기가바이트에 불과한 경우가 많습니다. 이러한 소규모 환경에서는 Iceberg의 복잡한 메타데이터 구조와 간접 계층이 오히려 비효율을 초래할 수 있습니다.(위키백과)

---

2. 쓰기 작업 시 메타데이터 오버헤드

Iceberg에서 단일 행을 업데이트할 때도 새로운 Parquet 파일, 매니페스트 파일, 매니페스트 리스트 파일, 테이블 메타데이터 JSON 등 네 개의 블롭 저장소 쓰기 작업이 필요합니다. 이러한 작업은 각각 수백 밀리초가 소요되어, PostgreSQL과 같은 전통적인 데이터베이스에서는 수 밀리초 내에 완료되는 작업이 Iceberg에서는 수 초가 걸릴 수 있습니다.(quesma.com)

---

3. 정기적인 컴팩션 필요

쓰기 작업이 누적되면 "파일 폭발(file explosion)" 현상이 발생하여 쿼리 성능이 저하됩니다. 이를 방지하기 위해서는 데이터 및 메타데이터 파일을 정기적으로 컴팩션해야 합니다. 그러나 현재 Iceberg 구현체는 자동 컴팩션 기능이 부족하여, 사용자가 직접 Spark나 Athena를 통해 OPTIMIZE 작업을 수행해야 하며, 이는 추가적인 비용과 복잡성을 초래합니다.(quesma.com)

---

4. 생태계의 단편화

Iceberg는 언어에 구애받지 않는 사양을 지향하지만, 실제로는 대부분의 프로덕션 코드가 Java 기반으로 실행됩니다. Python(PyIceberg), Rust, Go 등의 포트는 아직 Java 구현체에 비해 여러 릴리스를 뒤처져 있으며, 컴팩션 서비스와 같은 부가 도구도 부족한 상황입니다.

---

5. 향후 개선 사항

Iceberg의 공동 창립자인 Ryan Blue는 단일 파일 커밋(single-file commit)을 Iceberg Spec V4의 목표로 언급했지만, 2025년 5월 현재 이는 아직 개념적인 단계에 머물러 있습니다.(quesma.com)

---

이 블로그 글은 Apache Iceberg의 강력한 기능에도 불구하고, 소규모 데이터 환경에서는 오히려 복잡성과 비효율을 초래할 수 있음을 강조합니다. 따라서 조직의 데이터 규모와 요구 사항에 따라 Iceberg의 도입을 신중히 고려해야 하며, 특히 소규모 데이터셋을 다루는 경우에는 기존의 간단한 형식을 유지하는 것이 더 효율적일 수 있습니다.(Medium)

전체 글은 아래 링크에서 확인하실 수 있습니다:

👉 Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025

Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025 | Apache Iceberg Practical Limitations in 2025

 

Gemini 요약

• 제공해주신 웹페이지는 2025년 아파치 아이스버그(Apache Iceberg)의 실제적인 한계점들에 대해 설명하고 있습니다. 주요 내용은 다음과 같습니다:
• 빅데이터 우선 설계, 스몰데이터 사용성 개선 필요: 아이스버그는 본래 페타바이트 규모의 느리게 변화하는 데이터셋을 위해 설계되었기 때문에, 더 작은 규모의 데이터셋을 다루는 조직에게는 불편함이 있을 수 있습니다.
  쓰기 증폭 후 메타데이터 오버헤드: 아이스버그에서 업데이트는 여러 번의 쓰기 작업을 포함하며, 이는 포스트그레스(Postgres)와 같은 시스템에 비해 느릴 수 있습니다. 이 문제는 업데이트가 많을수록 악화되어 성능 유지를 위해 압축(compaction) 작업이 필요합니다.
• 압축 및 유지보수 비용: 데이터 및 메타데이터 파일의 정기적인 압축은 성능을 회복하는 데 필수적이지만, 복잡성, 지연, 비용을 추가합니다.
• 단편화되고 불완전한 생태계: 아이스버그 명세는 특정 언어에 구애받지 않지만, 대부분의 프로덕션 코드는 여전히 자바 스택에 의존하고 있습니다. 다른 언어로의 새로운 포팅은 JVM 참조 구현에 비해 뒤쳐져 있습니다. 또한 일부 쿼리 엔진은 쓰기 지원이 부족하거나 아이스버그 사용 시 성능 격차가 발생할 수 있습니다.
• 비정형 데이터, 넓은 테이블: 아이스버그는 잘 정의된 스키마에 가장 적합하며, 비정형 데이터와 넓은 테이블(컬럼이 매우 많은 테이블)에는 한계가 있습니다.
• 거버넌스 및 보안은 대부분 범위 밖: 아이스버그는 데이터 거버넌스나 보안 정책을 직접 처리하지 않으므로, 상위 계층에서 구현해야 합니다.
• 제한된 쓰기 동시성: 아이스버그의 동시성 모델은 분당 커밋 수를 제한하므로 OLTP(온라인 트랜잭션 처리) 스타일의 워크로드에는 적합하지 않습니다.
• 제한된 실시간 기능: 아이스버그는 즉각적인 가시성보다 원자적 배치 트랜잭션을 우선시하므로 실시간 또는 거의 실시간 데이터가 필요한 사용 사례에는 덜 적합합니다.
• 데이터 반출 비용: 클라우드에서 데이터를 옮기는 데 드는 높은 비용은 특정 공급업체에 머무르게 하는 유인이 될 수 있으며, 이는 아이스버그의 이식성이라는 장점을 제한할 수 있습니다.