The Brief FactStack이 되었습니다

FactStack

BigQuery로 보는 Hive Metastore 현대화 방법, Lakehouse 런타임 카탈로그란

데이터 인프라

한마디로

낡은 Hive Metastore를 코드 재작성 없이 옮겨서 BigQuery와 Spark가 같은 데이터를 동시에 쓰게 해주는 서버리스 카탈로그예요

한눈에

Google Cloud가 내놓은 Lakehouse 런타임 카탈로그는 Apache Iceberg REST 카탈로그 규격을 기반으로 만든 서버리스 메타데이터 저장소예요. 기존 Hive Metastore에 쌓인 테이블 정의와 파티션 맵을 그대로 옮겨서 BigQuery, Google Cloud Managed Service for Apache Spark, Trino 같은 엔진들이 데이터를 복사하지 않고 동시에 읽고 쓸 수 있게 해줍니다. 데이터를 다시 쓰거나 옮기는 작업 없이 몇 분 안에 전환이 가능하다는 점이 핵심이에요.

AS-IS: Hive Metastore가 안고 있던 문제

Apache Hive Metastore는 10년 넘게 빅데이터 분석의 메타데이터 저장소 역할을 해왔습니다. Hadoop 클러스터든 MySQL, PostgreSQL을 백엔드로 쓰는 Compute Engine VM이든 스키마 레지스트리로 기능하면서 Spark, Presto, Hive가 parquet, orc 파일을 조회할 수 있게 해줬어요. 문제는 데이터 레이크가 페타바이트급으로 커지고 파티션 테이블이 수십만 개로 늘어나면서 나타납니다. 관계형 데이터베이스에 의존하는 구조라 파티션 프루닝이나 대량 리스팅 작업이 몰리면 복잡한 Spark 작업 하나가 메타스토어 CPU를 100%까지 치솟게 만들고, 클러스터 전체의 쿼리 지연이나 메모리 부족 실패로 이어지기도 해요.

보안 정책 이중 관리와 운영 비용 부담

기존 메타스토어는 경계 기반의 Hadoop 보안 모델을 전제로 설계됐습니다. 테이블 단위 접근 제어 같은 세밀한 거버넌스를 Spark 컴퓨트 작업과 BigQuery 같은 엔터프라이즈 SQL 엔진 양쪽에 동시에 적용하려면 서로 다른 두 개의 제어 평면에서 분산되고 중복된 보안 정책을 유지해야 하는 부담이 생깁니다. 여기에 고가용성 MySQL, Postgres 인스턴스 운영, HMS 데몬 패치, JDBC 커넥션 풀 튜닝, 유휴 상태에서도 비용이 드는 인스턴스 기반 메타스토어 서버 운영까지 더해지면서 데이터 플랫폼 팀의 불필요한 운영 부담이 계속 쌓이는 구조였어요.

Lakehouse 런타임 카탈로그가 바꾸는 것

Google Cloud는 기존 저장 데이터를 다시 쓰게 만들지 않으면서 이 병목을 풀기 위해 Iceberg REST Catalog와 Hive Catalog를 모두 지원하는 완전 서버리스 카탈로그를 만들었습니다. Apache Iceberg REST Catalog 규격을 그대로 구현해서 메타데이터 탐색과 컴퓨트 엔진을 분리한 게 핵심이에요. 이 분리 덕분에 Iceberg와 호환되는 여러 엔진이 데이터를 복제하지 않고 동시에 접근할 수 있고, 고객이 데이터를 여러 벌로 복사해 관리할 필요가 줄어듭니다. 테이블은 등록 즉시 Google Cloud Managed Spark, BigQuery, 오픈소스 엔진들에서 표준 REST 인터페이스로 조회 가능해지고, 테이블 정의는 Cloud Storage에 있는 기존 데이터를 그대로 가리키기 때문에 데이터를 옮기거나 복제하지 않아요. 보안 측면에서는 Knowledge Catalog와 Cloud IAM과 직접 연동해서 에이전트를 위한 trusted context와 테이블 단위 보안을 여러 컴퓨트 엔진에 일관되게 적용할 수 있고, credential vending 같은 인증 방식을 지원해서 Cloud Storage 버킷의 파일에 직접 접근할 필요 없이 테이블에 접근할 수 있게 해줍니다. Spanner를 기반으로 하고 Cloud Storage의 dual-region, multi-region 버킷 지원으로 장애 복구 시나리오도 다룰 수 있으며, 서버리스와 no-ops 환경이라 운영 비용도 줄어든다고 설명하고 있어요.

실무 적용 포인트

Google Cloud가 제공하는 마이그레이션 기능은 기존 Hive Metastore에 직접 연결해서 외부 테이블 정의와 파티션 맵을 추출한 뒤 서버리스 Lakehouse 카탈로그에 등록해줍니다. 등록이 끝나면 곧바로 Google Managed Spark, BigQuery, Gemini 기반 Conversational Analytics 에이전트에서 같은 데이터를 쓸 수 있어요. 데이터 인프라 담당자라면 아래 항목을 체크해보면 좋습니다.

  • 파티션 테이블 수가 늘면서 메타스토어 CPU 스파이크나 OOM 실패를 겪고 있는지
  • Spark와 BigQuery에 보안 정책을 이중으로 관리하고 있는지
  • 고가용성 메타스토어 인스턴스 운영 비용이 부담되는지
  • 데이터 복사 없이 여러 엔진이 같은 Iceberg 테이블을 동시에 쓸 필요가 있는지

자주 묻는 질문

bigquery 란 무엇인가요

BigQuery는 Google Cloud의 서버리스 데이터 웨어하우스로, 이번에 소개된 Lakehouse 런타임 카탈로그에 등록된 테이블을 Spark, Trino 같은 다른 엔진과 데이터 복사 없이 동시에 조회할 수 있는 엔진 중 하나예요.

ai agent 란 무엇인가요

원문에서는 Gemini 기반 Conversational Analytics 에이전트를 예로 들면서, Lakehouse 카탈로그가 에이전트에 trusted context와 테이블 단위 보안을 일관되게 제공한다고 설명합니다. 즉 에이전트가 신뢰할 수 있는 데이터 접근 권한과 맥락을 갖고 분석 작업을 수행하는 구조를 뜻해요.

Hive Metastore를 BigQuery Lakehouse 카탈로그로 옮기는 방법은 무엇인가요

Google Cloud가 제공하는 마이그레이션 기능이 기존 Hive Metastore에 직접 연결해서 테이블 정의와 파티션 맵을 추출하고 서버리스 Lakehouse 카탈로그에 등록해줍니다. 데이터를 복사하거나 다시 쓰지 않는 zero-data-copy 방식으로 진행돼요.

Iceberg REST Catalog와 기존 Hive Catalog의 차이는 무엇인가요

Lakehouse 런타임 카탈로그는 Iceberg REST Catalog와 Hive Catalog를 모두 지원합니다. 메타데이터 탐색을 컴퓨트 엔진에서 분리한 덕분에 여러 팀이 각자 선호하는 분석 도구로 하나의 통합된 데이터셋에 접근할 수 있어요.

에디터 노트

여러 엔진이 뒤섞인 데이터 인프라에서 메타스토어 병목과 보안 정책 이중 관리는 실무자가 늘 겪는 골칫거리인데, zero-data-copy 전환이라는 접근은 마이그레이션 부담을 확실히 줄여줄 만합니다. 다만 원문이 Google Cloud 자체 발표문이라 성능 개선 폭이나 실제 전환 사례의 구체적 수치는 빠져 있어서, 대규모 환경에 적용하기 전에는 별도의 검증이 필요해 보여요.

참고 출처 | 원문 보기

태그

용어 풀이
bigquery
빅쿼리
hive metastore
하이브 메타스토어
lakehouse
레이크하우스
apache iceberg
아파치 아이스버그

이 노트는 자동 검증을 거쳐 발행되었습니다. 오류 제보는 편집팀이 즉시 확인합니다.

공유