Iceberg 스키마 진화와 시간여행, Hive와 겹쳐보기

스키마가 바뀔 때마다 테이블을 통째로 다시 써야 할까?

결론부터: Iceberg는 스키마·파티션 변경을 메타데이터 갱신으로 처리해 파일 재작성을 없애지만, 조회 범위가 좁을 때는 매니페스트 플래닝 오버헤드 때문에 오히려 Hive보다 느려질 수 있다. 신선도가 중요한 CDC·업서트 경로에서는 Iceberg 쪽 손이, 정적이고 좁은 범위 배치 리포트에서는 Hive 방식이 여전히 유효하다. 결국 선택은 "재처리 비용을 줄일 것인가, 플래닝 오버헤드를 감수할 것인가"의 문제다.

• 스키마·파티션 변경: Iceberg는 메타데이터만 갱신, Hive는 파티션 구조가 바뀌면 재적재가 필요한 경우가 많다.
• 시간여행: Iceberg는 스냅샷 ID·타임스탬프로 즉시 조회 가능, Hive는 별도 버전 관리 계층을 붙여야 한다.
• 1년 범위 쿼리에서는 Iceberg가 Hive 대비 약 40% 단축(39.42초 vs 65.74초)됐지만, 1개월 범위에서는 Iceberg가 오히려 느렸다(10.07초 vs 8.10초).
• 큰 스캔 범위·긴 보관 구간일수록 파일 스킵 효과로 Iceberg의 이점이 커지는 경향이 있다.

컬럼을 추가하거나 이름을 바꾸면 실제로 무엇이 다시 쓰이는가?

Iceberg는 데이터 파일을 건드리지 않는다. 컬럼 추가·이름 변경·타입 변경은 스키마 ID 매핑을 갱신하는 메타데이터 작업으로 끝난다. 기존 Parquet/ORC 파일은 그대로 남고, 새로 쓰는 파일부터 새 스키마가 적용된다. Hive 계열 정적 테이블은 파티션 스키마가 컬럼 구조와 물리적으로 엮여 있어, 구조 변경 시 전체 재적재나 별도 마이그레이션 잡이 뒤따르는 경우가 흔하다.

파티션 전략을 바꾸면 이미 쌓인 데이터는 어떻게 되는가?

Iceberg는 파티션 진화도 메타데이터 레벨 작업으로 처리한다. 새 파티션 스펙은 이후 쓰이는 데이터에만 적용되고, 과거 파일은 이전 스펙 그대로 남아 하나의 테이블 안에서 두 스펙이 공존한다. Hive는 파티션 컬럼을 바꾸면 디렉터리 구조 자체가 달라지므로, 보통 전체 데이터를 새 구조로 다시 적재해야 한다.

특정 시점의 테이블 상태를 다시 보려면 무엇이 필요한가?

Iceberg는 별도 인프라 없이 스냅샷 기반으로 과거 시점 조회가 가능하다. 감사·디버깅·롤백 목적으로 특정 스냅샷 ID나 타임스탬프를 지정하면 그 시점의 파일 목록이 그대로 복원된다. Hive 정적 테이블에는 이 기능이 내장돼 있지 않아, 별도 백업 테이블이나 버전 태깅 규칙을 팀이 직접 설계해야 한다.

조회 범위가 좁을 때와 넓을 때 성능은 어떻게 갈리는가?

넓은 범위에서는 Iceberg가 유리하지만, 좁은 범위에서는 매니페스트를 열어 파일 목록을 계획하는 비용이 상대적으로 커진다. 아래는 실측 사례다.

같은 계열 자료에서는 메타데이터 기반 파일 스킵으로 240개 파일 중 5개만 스캔해 I/O를 크게 줄인 사례도 제시되지만, 재현 조건이 명확히 공개되지 않아 참고 수준으로만 다룬다.

전환 비용은 실제로 무엇을 요구하는가?

기존 Hive 테이블을 Iceberg로 옮기는 작업은 데이터 재작성 없이도 메타데이터 부트스트랩(마이그레이션 프로시저 실행)과 카탈로그 등록이 필요하다. 여기에 더해 좁은 범위 대시보드 쿼리가 매니페스트 오버헤드로 느려지지 않는지 별도 검증이 필요하고, 업서트·삭제 워크로드라면 v2 스펙의 row-level delete 지원 여부와 엔진 버전 호환성도 확인 대상이다. 2026년 기준으로도 이 검증 단계는 생략하기 어렵다.

판단 기준

스키마가 고정돼 있고 조회 범위가 좁은 배치 리포트 경로라면 Hive 정적 테이블을 유지해도 손해가 크지 않다. 반대로 스키마·파티션이 자주 바뀌고 스트리밍·CDC 업서트가 있으며 조회 범위가 넓은 경로라면 Iceberg가 재처리 비용을 줄인다. 둘 중 어느 쪽이 항상 옳은 것은 아니고, 조회 범위 분포와 스키마 변경 빈도를 먼저 측정한 뒤 결정할 문제다.

핵심 정리

• Iceberg는 스키마·파티션 변경을 메타데이터 갱신으로 처리해 파일 재작성을 없앤다.
• 시간여행은 Iceberg의 스냅샷 구조에 기본 내장돼 있고, Hive는 별도 버전 관리 계층이 필요하다.
• 1년 범위 쿼리에서 Iceberg가 약 40% 빨랐지만, 1개월 범위에서는 매니페스트 오버헤드로 더 느렸다.
• 전환 시에는 메타데이터 부트스트랩, 카탈로그 등록, 좁은 범위 쿼리 성능 검증이 함께 필요하다.
• 선택 기준은 조회 범위 분포와 스키마 변경 빈도이지, 어느 한쪽의 절대 우위가 아니다.

더 알아보기

데이터 파이프라인 아키텍처: 배치·스트리밍·신선도의 설계 축 — 이 주제의 종합 가이드