[Iceberg] why Iceberg?
들어가며: 하둡에서 클라우드로, 무대의 변화
결론부터 말하자면, Iceberg는 “클라우드 환경에서 대규모 데이터를 DB처럼 안전하고 빠르게 다루기 위해” 탄생했습니다.
과거 데이터 플랫폼의 무대는 하둡(HDFS)이었지만, 점차 클라우드 객체 스토리지(S3, GCS)로 중심이 이동했습니다. 이 과정에서 기존의 강자였던 Hive(하이브)는 구조적인 한계에 부딪히게 되었고, 이를 해결하기 위해 Iceberg가 등장하게 되었습니다.
구체적으로 발생하던 문제는 다음과 같이 대표적으로 3가지가 존재합니다.
- 클라우드 스토리지는 파일 시스템이 아니다. 하둡(HDFS) 시절에는 파일 리스팅(
ls) 작업이 빨랐습니다. 하지만 S3와 같은 오브젝트 스토리지에서 파일 리스팅은 매우 느린 작업입니다. 데이터가 페타바이트(PB) 단위로 커지면, 쿼리 실행 시 데이터를 ‘읽는 시간’보다 파일을 ‘찾는 시간(Listing)’이 더 오래 걸리는 배보다 배꼽이 더 큰 상황이 발생합니다.- Hive: 디렉토리를 뒤져서 파일을 찾음 (느림)
- Iceberg: 메타데이터에 파일 위치를 미리 기록해둠 (빠름)
- 데이터의 신뢰성 보장 (ACID 트랜잭션)
데이터 레이크는 수많은 파이프라인과 사용자가 동시에 데이터를 쓰고 읽는 공간입니다. 하지만 Hive는 트랜잭션(ACID)을 완벽하게 지원하지 않습니다.
이로 인해 데이터를 쓰고 있는 도중에 조회를 하면 쓰다 만 불완전한 데이터가 조회되거나, 작업 실패 시 더미 데이터(Garbage)가 남아 결과의 정합성을 해치는 문제가 심각했습니다.
이제 데이터 레이크에서도 DB처럼 “성공(Commit) 아니면 실패”를 완벽하게 보장하는 포맷이 필수적이게 되었습니다. - 유연한 스키마 변경 (Schema Evolution)
비즈니스 환경은 끊임없이 변하고, 이에 따라 테이블의 컬럼명을 바꾸거나 타입, 순서를 변경해야 할 일이 잦습니다.
Hive에서 스키마 변경은 그야말로 ‘대공사’입니다. 실제 데이터 파일(CSV, Parquet)과 메타스토어의 스키마가 강하게 결합되어 있어, 스키마를 바꾸려면 데이터를 전체 다시 쓰거나(Rewrite), 불일치로 인해 쿼리가 깨지는 위험을 감수해야 했습니다.
Iceberg는 데이터 파일을 건드리지 않고 메타데이터 수정만으로 스키마를 완벽하게 변경할 수 있는 유연성이 필요했습니다.
실제 데이터 조회 방식의 차이
앞서 말씀드린 이유들로 인해, 엔진이 실제로 데이터를 찾아가는 과정은 다음과 같이 완전히 다릅니다.
1. Hive (기존 방식): “일단 폴더부터 뒤져보자”
하이브는 데이터가 저장된 디렉토리(위치)가 곧 테이블이라고 판단합니다. 따라서 특정 날짜의 데이터를 찾기 위해 해당 폴더에 있는 모든 파일 목록을 조회(Listing)해야 하며, 파일이 많을수록 이 과정에서 심각한 병목이 발생합니다.
2. Iceberg (새로운 방식): “장부에서 정확한 파일만 뽑자”
아이스버그는 메타데이터(장부)에 모든 파일의 목록과 통계 정보가 이미 기록되어 있습니다. 느린 스토리지 리스팅(ls)을 할 필요 없이, 메타데이터 파일만 읽어서 필요한 데이터 파일의 정확한 주소(path)를 바로 알아냅니다.
실제로 왜 더 빠를까?
위도우 탐색기나 맥 파인더에서 열면 파일이 바로 보이지만, 클라우드 스토리지(S3, GCS)의 경우는 완전히 다르게 됩니다.
가장 큰 차이는 파일을 조회하는 API의 작동 방식입니다.
1. Hive의 방식: “끝없는 네트워크 왕복
AWS S3의 ListObjects API는 한 번 요청에 최대 1,000개의 파일 목록만 돌려줍니다(Pagination).
만약 데이터가 100,000개의 파일로 쪼개져 있다면,
- Hive는 전체 목록을 얻기 위해 S3에 최소 100번의 API 요청을 연속으로 보내야 합니다.
- 이 과정은 단순한 컴퓨터 연산이 아니라, 인터넷을 타고 데이터를 주고받는 네트워크 I/O 작업입니다.
- 결국 데이터를 읽기도 전에, 파일을 찾는 데에만 수 초에서 수십 초가 소요되는 병목이 발생합니다.
2. Iceberg의 방식: “메모리에서 끝내는 조회”
반면, Iceberg는 S3의 느린 리스팅 기능(ls)을 전혀 사용하지 않습니다.
- Iceberg는 처음에 ‘매니페스트 파일(Manifest File)’이라는 메타데이터 파일만 S3에서 가져옵니다.
- 이 파일 안에는 10만 개 파일의 전체 경로가 이미 텍스트로 정리되어 있습니다.
- 엔진은 이 정보를 메모리(RAM)에 로드합니다.
- 이제 파일 위치를 찾는 작업은 네트워크가 아닌 로컬 메모리에서 수행되므로, 수 밀리초(ms) 내에 파일 목록 확보가 끝납니다.
| 구분 | Hive (S3 Listing) | Iceberg (Manifest Read) |
|---|---|---|
| 작동 방식 | S3 API 반복 호출 (Loop) | 메타데이터 파일 1회 로드 |
| 주요 비용 | Network I/O (느림) | Memory Access (빠름) |
| 10만 개 조회 시 | API 요청 100회+ | API 요청 최소화 (메타데이터만) |
| 속도 | 수 초 ~ 수십 초 (느림) | 수 밀리초 (매우 빠름) |