Hive에서 Iceberg로, 빅데이터 테이블 포맷의 진화

빅데이터 환경에서 데이터를 효율적으로 관리하는 방식은 시스템 성능과 비즈니스 의사결정에 직접적인 영향을 미칩니다. 오랫동안 Apache Hive 테이블 포맷이 빅데이터 저장 및 분석의 표준으로 사용되어 왔지만, 최근에는 Netflix가 개발한 Apache Iceberg 테이블 포맷으로의 전환이 빠르게 이루어지고 있죠.

이 글에서는 두 테이블 포맷의 근본적인 차이점과 이러한 기술 선택이 비즈니스에 미치는 영향에 대해 살펴보겠습니다.

데이터 레이크와 테이블 포맷 이해하기

데이터 레이크(Data Lake)는 기업의 모든 원시 데이터를 저장하는 거대한 디지털 저장소입니다. 이러한 환경에서 데이터를 어떻게 구조화하고, 접근하고, 분석할 것인지를 결정하는 테이블 포맷의 선택은 매우 중요하죠. 특히 데이터 규모가 테라바이트, 페타바이트 단위로 증가하면서 기존 테이블 포맷의 한계가 드러나고 있습니다.

빅데이터 테이블 포맷은 단순한 파일 구조가 아닌 비즈니스 의사결정의 핵심 기반이 되는 것이죠. 테이블 포맷의 효율성은 데이터 분석의 속도와 정확성에 직접적인 영향을 미치며, 이는 시장 변화에 얼마나 빠르게 대응할 수 있는지를 결정합니다.

Hive 테이블 포맷: 빅데이터의 시작

Apache Hive는 Facebook(현 Meta)에서 개발한 데이터 웨어하우스 솔루션으로, Hadoop 생태계의 핵심 구성 요소입니다. Hive 테이블 포맷은 SQL과 유사한 HiveQL을 통해 접근할 수 있는 데이터 저장 방식을 제공하며, 복잡한 MapReduce 프로그래밍 없이도 대용량 데이터를 분석할 수 있게 해주었죠.

Hive는 비즈니스 관점에서 큰 혁신이었습니다. 기업들은 별도의 전문 개발자를 고용하지 않고도 SQL에 익숙한 데이터 분석가들이 빅데이터를 분석할 수 있게 되었어요. 이는 마치 엑셀에서 SQL로 업그레이드한 것처럼, 기가바이트 단위를 넘어 테라바이트, 페타바이트 규모의 데이터도 다룰 수 있게 해주었죠.

Hive 테이블 포맷의 구조를 3단계로 나누어 설명해보면, 다음과 같습니다.

• 데이터 저장: 실제 데이터는 HDFS(Hadoop Distributed File System)나 Amazon S3와 같은 분산 파일 시스템에 저장됩니다. 이는 도서관의 수많은 책이 여러 서가에 분류되어 보관되는 것과 유사합니다.
• 메타데이터 관리: 테이블 정보, 컬럼 정보, 파티션 정보 등은 HMS(Hive Metastore Service)라는 중앙 저장소에 보관됩니다. 이는 "어떤 데이터가 어디에 있는지"를 알려주는 카탈로그 역할을 합니다.
• 쿼리 처리: 사용자 쿼리는 HMS에서 메타데이터를 조회한 후, 필요한 데이터 파일을 찾아 처리합니다. 마치 도서관에서 카탈로그를 먼저 확인한 후 해당 위치의 책을 찾아가는 것과 같은 방식입니다.

Hive 테이블 포맷의 한계점

Hive 테이블 포맷은 데이터 규모가 폭발적으로 증가하면서 여러 한계에 직면했습니다.

1. 메타스토어 병목 현상

파티션(데이터를 날짜, 지역 등의 기준으로 나눠 저장하는 단위) 수가 수만 개로 증가하면 HMS에 심각한 부하가 발생합니다. 한 기업에서는 고객 활동 로그 테이블의 파티션 수가 10만 개를 넘어서자 단순히 "지난달 데이터를 보여줘"라는 쿼리도 준비 단계에서만 5분 이상 소요되는 상황이 발생했죠.

이런 지연은 마케팅 팀이 캠페인 성과를 분석하거나, 세일즈 팀이 실시간 판매 데이터를 확인하려 할 때 몇 분씩 기다려야 한다면 업무 효율성이 크게 저하되죠. 고객 데이터를 기반으로 빠른 의사결정이 필요한 경쟁 환경에서, 이는 비즈니스 기회 손실로 직결될 수 있습니다. 실시간 가격 조정이나 재고 관리 같은 시간에 민감한 업무가 크게 영향을 받게 되는 거죠.

2. 데이터 정합성 문제

Hive는 기본적으로 ACID(원자성, 일관성, 고립성, 지속성) 트랜잭션을 완전히 지원하지 않아요. 이로 인해 ETL 작업 실패 시 데이터가 불완전한 상태로 남거나, 동시 작업 시 데이터 충돌이 발생할 수 있습니다.

은행 시스템으로 예를 들어보면, A와 B가 동시에 같은 계좌에서 출금할 때 잔액이 정확히 계산되어야 하는 것처럼, 데이터 시스템도 동시 작업 시 정확성이 보장되어야 합니다. 하지만 Hive에서는 이런 보장이 미흡해 데이터가 중복되거나 일부 손실될 위험이 있습니다.

금융 서비스 회사에서 거래 데이터가 누락되거나 중복된다면 재무 보고서의 정확성이 손상되고, 이는 규제 준수 문제나 감사 실패로 이어질 수 있습니다. 이커머스 기업의 경우, 재고 데이터가 정확하지 않으면 고객이 주문한 상품이 실제로는 재고가 없는 상황이 발생할 수 있으며, 이는 고객 경험 저하와 브랜드 신뢰도 하락으로 이어집니다.

3. 복잡한 파티션 관리

Hive에서 파티셔닝(Partitioning)은 성능을 위해 필수적이지만, 관리가 매우 번거롭습니다. 새 파티션이 생성되면 수동으로 명령어를 실행해 HMS에 등록해야 합니다. 이는 마치 도서관에 새 책장이 추가될 때마다 사서가 직접 카탈로그를 업데이트해야 하는 것과 같습니다.

자동화되지 않은 이 과정은 운영 부담을 크게 늘리고, 사람의 실수로 인한 오류 가능성도 높아집니다. 데이터 엔지니어들은 실제 데이터 분석보다 이러한 관리 작업에 더 많은 시간을 투자하게 되어, 혁신적인 데이터 활용보다는 시스템 유지에 리소스가 소모됩니다.

4. 제한적인 스키마 진화

운영 중인 테이블의 구조(스키마)를 변경하는 작업은 Hive에서 매우 제한적이고 위험합니다. 컬럼 추가는 가능하지만, 이름 변경이나 타입 변경은 기존 데이터와의 호환성 문제를 일으킬 수 있죠.

이는 마치 달리는 기차의 부품을 교체하는 것처럼 까다롭고 위험한 작업입니다. 실수로 스키마를 잘못 변경하면 과거 데이터를 읽을 수 없게 되거나, 분석 결과가 왜곡될 수 있어서 많은 데이터 엔지니어들이 이 작업을 꺼려합니다.

비즈니스가 빠르게 변화하고 새로운 분석 요구사항이 지속적으로 발생하는 환경에서, 이러한 제한은 데이터 활용의 유연성을 크게 저해하고 비즈니스 민첩성을 떨어뜨립니다.

Apache Iceberg: 현대적 테이블 포맷의 등장

Netflix에서 개발한 Apache Iceberg는 Hive 테이블 포맷의 한계를 근본적으로 해결하기 위한 오픈 테이블 포맷입니다. 현재는 Apache 재단의 최상위 프로젝트로 성장했으며, Netflix, Apple, LinkedIn 등 많은 글로벌 기업들이 도입하고 있어요.

Iceberg는 단순한 기술 업그레이드가 아닌 테이블 포맷의 패러다임 전환을 의미하는 것이죠. 초기 도입 비용보다 데이터 유지보수 비용 절감, 의사결정 속도 향상, 데이터 기반 비즈니스 기회 확대 등의 장기적 이점이 훨씬 클 수 있습니다.

1. 스냅샷 기반 버전 관리

Iceberg는 테이블의 모든 변경 사항을 '스냅샷(Snapshot)'으로 관리합니다. 스냅샷은 특정 시점의 테이블 상태를 저장해둔 것으로, 소프트웨어 개발에서 사용하는 Git과 유사한 개념이죠. 데이터가 추가, 수정, 삭제될 때마다 새로운 스냅샷이 생성됩니다. 각 스냅샷은 특정 시점의 테이블 상태를 정확히 나타내며, 불변(Immutable)이죠.

이런 방식 덕분에 "2주 전 데이터는 어땠지?"라고 물어볼 수 있고(Time Travel), 만약 데이터가 잘못 변경되었다면 이전 스냅샷으로 쉽게 되돌릴 수 있습니다(Rollback). 마치 워드 프로세서에서 문서의 이전 버전으로 되돌리는 것처럼 간편하죠.

2. 자체 포함된 메타데이터

Iceberg의 또 다른 핵심 특징은 테이블 메타데이터를 외부 시스템(HMS)에 의존하지 않고, 테이블 데이터와 함께 스토리지에 직접 저장한다는 점입니다. 테이블의 최신 상태는 최상위 메타데이터 파일에 기록되며, 각 스냅샷의 세부 정보는 계층적으로 메타데이터 파일에 저장되죠.

이런 구조는 마치 책 자체에 목차와 색인이 포함되어 있어 외부 카탈로그 없이도 내용을 찾을 수 있는 것과 비슷합니다. 쿼리 엔진은 이 메타데이터 파일들을 통해 필요한 데이터 파일만 정확히 찾아 효율적으로 처리할 수 있게 됩니다.

Iceberg가 Hive를 대체하는 이유

1. 원자적 트랜잭션으로 데이터 정합성 보장

Iceberg는 모든 테이블 변경 작업을 원자적(Atomic)으로 수행합니다. 원자적이란 작업은 '완전히 성공하거나 아예 실행되지 않는' 속성을 의미하죠. 변경 작업이 완료되면 새 메타데이터 파일을 생성하고, 마지막 단계에서 테이블 포인터를 원자적으로 업데이트합니다.

은행 거래로 비유하자면, 송금 과정이 중간에 끊기지 않고 '모두 성공하거나 아예 실패하거나' 둘 중 하나만 가능한 것과 같습니다. 작업이 실패해도 테이블은 이전 상태를 완벽하게 유지하고, 여러 작업이 동시에 진행되어도 서로 간섭하지 않아 데이터 신뢰성이 크게 향상됩니다.

2. 메타데이터 병목 해소 및 성능 향상

Iceberg는 중앙 HMS에 의존하지 않고 메타데이터 파일을 직접 읽어 처리합니다. 또한 파티션과 파일 수준의 통계 정보를 활용해 필요한 데이터 파일만 정확히 필터링할 수 있어요. 이를 '프루닝(Pruning)'이라고 하는데, 필요 없는 데이터는 아예 읽지 않고 건너뛰어 성능을 크게 향상시키는 기술입니다.

이는 마치 도서관에서 카탈로그실에 가지 않고도 각 책장에 부착된 상세 목록을 통해 필요한 책만 바로 찾을 수 있는 것과 같습니다. Netflix의 경우, 수백만 개 파일로 구성된 테이블에서 Hive는 쿼리 계획 수립에만 몇 분이 걸렸지만, Iceberg에서는 수 초 내로 단축되었습니다. 일부 분석 쿼리는 처리 시간이 최대 10배까지 단축되는 놀라운 성능 개선을 보였습니다.

3. 안전하고 유연한 스키마 진화

Iceberg는 컬럼을 이름이 아닌 고유 ID로 추적합니다. 스키마(schema)는 데이터의 구조를 정의하는 것으로, 테이블의 컬럼 이름, 데이터 타입, 순서 등을 포함합니다. Iceberg에서는 이 스키마가 변경되어도 문제가 없도록 각 컬럼에 고유 ID를 부여합니다. 이는 주민등록번호처럼 변하지 않는 식별자를 사용하는 것과 같습니다.

덕분에 컬럼 추가/삭제, 컬럼 이름 변경, 안전한 컬럼 타입 변경(int → long 등), 그리고 기존 데이터를 재작성할 필요 없이 파티션 방식을 변경할 수 있습니다.

마치 건물의 내부 구조를 철거하고 다시 짓는 대신, 간단히 벽만 재배치하는 것처럼 빠르고 안전하게 변경이 이루어지는 거죠.

4. 자동화된 파티션 관리

Iceberg에서는 파티션 관리가 대부분 자동화되어 있습니다. 새 파티션이 자동으로 인식되고, 숨겨진 파티셔닝(Hidden Partitioning)으로 쿼리 작성이 간편해지며, 파티션 진화(Evolution) 지원으로 파티션 전략 변경이 용이해졌습니다.

숨겨진 파티셔닝이란 사용자가 파티션 구조를 직접 신경 쓰지 않고 일반 조건절만으로 쿼리를 작성할 수 있게 하는 기능입니다. 예를 들어, Hive에서는 "WHERE year=2023 AND month=12"와 같이 파티션 컬럼을 명시해야 하지만, Iceberg에서는 "WHERE event_date='2023-12-01'"처럼 일반적인 날짜 조건만으로 쿼리할 수 있습니다.

Adobe는 Iceberg 도입 후 파티션 관리 오버헤드가 90% 이상 감소했으며, 데이터 엔지니어들의 운영 부담이 크게 줄었습니다. 이는 마치 수동으로 파일을 정리하던 작업이 자동 분류 시스템으로 대체된 것과 같은 효과입니다.

글로벌 기업들의 Iceberg 도입 사례

1. Netflix

Netflix는 매일 수 페타바이트 규모의 데이터를 처리하는 환경에서 Hive의 한계에 직면했습니다. ETL 작업 실패나 동시 쓰기로 인한 데이터 불일치가 빈번했고, 수억 개의 파일로 구성된 테이블에서 쿼리 성능이 크게 저하되었습니다.

Iceberg 도입 후 데이터 정합성 문제가 해소되었고, 일부 분석 작업은 10배 이상 빨라졌습니다. 특히 Time Travel 기능으로 데이터 복구가 간편해져 운영 안정성이 크게 향상되었습니다. 이제 Netflix는 실수로 데이터가 잘못 변경되어도 쉽게 이전 상태로 복원할 수 있게 되었습니다.

Netflix의 데이터 인프라 개선은 콘텐츠 추천 알고리즘의 정확도와 속도를 크게 향상시켰습니다. 이는 사용자 참여도 증가와 이탈률 감소로 이어졌으며, 결과적으로 구독자 유지율이 개선되었습니다. 또한 데이터 품질 문제로 인한 운영 중단이 77% 감소하여 연간 수백만 달러의 비용을 절감했습니다.

2. Apple

Apple은 글로벌 규모의 데이터 처리를 위해 Iceberg를 도입했습니다. Apple이 직면한 주요 과제는 다양한 제품과 서비스에서 발생하는 방대한 데이터를 안정적으로 처리하고 분석해야 했다는 점이었습니다.

Iceberg 도입으로 데이터 처리 파이프라인의 안정성과, 특히 동시 쓰기 상황에서의 신뢰성이 크게 향상되었습니다. 또한 스키마 진화 기능으로 빠르게 변화하는 비즈니스 요구사항에 유연하게 대응할 수 있게 되었습니다. 이전에는 데이터 구조 변경이 복잡한 작업이었지만, 이제는 새로운 분석 요구사항이 생겨도 신속하게 스키마를 조정할 수 있게 되었습니다.

Apple은 App Store 및 Apple 서비스 전반의 사용자 데이터 분석 속도가 크게 향상되었다고 보고했습니다. 이는 개발자 생태계 지원과 앱 마켓플레이스 최적화에 실질적인 기여를 했으며, 데이터 팀의 생산성이 크게 향상되어 새로운 데이터 기반 비즈니스 이니셔티브를 더 빠르게 진행할 수 있게 되었습니다.

3. LinkedIn

LinkedIn은 수십억 회원의 활동 데이터를 실시간으로 수집하고 분석하기 위해 Iceberg를 도입했습니다. 데이터 신뢰성과 쿼리 성능이 LinkedIn의 핵심 요구사항이었습니다.

Iceberg 도입 후 데이터 처리 지연 시간이 크게 감소했고, 특히 파티션 관리 자동화로 운영 효율성이 향상되었습니다. 또한 스키마 진화 기능으로 새로운 분석 요구사항에 빠르게 대응할 수 있게 되었습니다. LinkedIn의 데이터 과학자들은 이제 복잡한 데이터 구조 변경 없이도 새로운 유형의 분석을 쉽게 수행할 수 있게 되었습니다.

LinkedIn은 광고 타게팅 및 콘텐츠 추천 알고리즘의 실시간성과 정확도가 크게 향상되었다고 보고했습니다. 특히 채용 추천 서비스에서 적절한 구직자와 구인 기업을 매칭하는 속도가 30% 이상 향상되었으며, 이는 직접적인 비즈니스 성과로 이어졌습니다. 또한 데이터 엔지니어링 팀의 운영 부담이 크게 줄어들어, 새로운 데이터 제품 개발에 더 많은 리소스를 투입할 수 있게 되었습니다.

마치며

"Hive와 Iceberg가 다 똑같은 빅데이터 테이블 포맷 아닌가요?"라는 질문을 해본다면, 그 답은 아래와 같이 해볼 수 있겠습니다.

두 테이블 포맷은 근본적으로 다른 접근 방식을 가지고 있으며, 이는 실질적인 비즈니스 가치의 차이로 이어집니다. Netflix, Apple, LinkedIn 같은 글로벌 기업들이 Iceberg를 선택한 이유는 비용 효율성(클라우드 비용 절감), 데이터 신뢰성(정확한 의사결정), 비즈니스 민첩성(빠른 요구사항 대응), 리스크 감소(데이터 복구 및 일관성)와 같은 실질적인 비즈니스 이점 때문이죠.

데이터 기반 의사결정이 경쟁력의 핵심인 오늘날, 테이블 포맷은 단순한 기술적 선택이 아닌 비즈니스 성공의 핵심 요소입니다. 모든 기업에 Iceberg가 필요한 것은 아니지만, 데이터 의존도가 높고 경쟁이 치열한 환경일수록 Iceberg와 같은 현대적 테이블 포맷의 가치는 더욱 커지는 것이죠. 기술 선택은 단순한 엔지니어링 결정이 아닌, 비즈니스의 미래를 좌우하는 전략적 결정이 되어가고 있습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.