공부/데이터 2026. 4. 26. 23:58

1. 개요

중앙 메타스토어(Central Metastore 또는 Data Catalog)는 데이터 레이크·레이크하우스 환경에서 테이블 스키마, 파티션 정보, 위치(Location), 통계, 직렬화 방식(SerDe) 등 데이터의 메타데이터를 통합 관리하는 핵심 인프라 컴포넌트입니다.

Spark, Trino, Flink, Hive 등 다수의 처리 엔진이 동일한 데이터 자산에 접근할 때, 각 엔진이 개별적으로 스키마 정보를 관리하면 불일치와 중복이 발생합니다. 중앙 메타스토어는 이러한 문제를 해결하기 위해 단일 진실 공급원(Single Source of Truth) 역할을 수행합니다.

초기에는 Apache Hive Metastore(HMS)가 사실상 표준으로 자리 잡았으나, 데이터 레이크하우스 시대에 접어들면서 트랜잭션 지원, REST 표준 호환, 멀티 포맷 지원, 세밀한 거버넌스 등을 제공하는 현대적 카탈로그들이 등장하였습니다.

2. 중앙 메타스토어가 왜 필요한지

멀티 엔진 환경의 일관성 확보

Spark, Trino, Flink, Hive, Presto 등 다양한 엔진이 S3·GCS·ADLS 같은 공용 오브젝트 스토리지의 동일 데이터를 조회합니다. 중앙 메타스토어가 없으면 각 엔진마다 별도로 테이블 스키마와 파티션 정보를 관리해야 하며, 스키마 변경 시 모든 엔진에 개별 반영해야 하는 운영 부담이 발생합니다.

데이터 거버넌스 및 보안

테이블과 컬럼 단위의 접근 권한을 중앙에서 관리하지 않으면 엔진별로 정책이 달라질 위험이 있습니다. 중앙 메타스토어는 RBAC(Role-Based Access Control), 행·열 수준 보안, Tag 기반 정책을 한 곳에서 적용하는 거버넌스 기반을 제공합니다.

데이터 발견성(Discoverability) 향상

수천 개의 테이블이 오브젝트 스토리지에 흩어져 있을 때, 중앙 카탈로그 없이는 필요한 데이터를 찾는 것 자체가 어렵습니다. 중앙 메타스토어는 스키마·통계·태그·Lineage 정보를 통해 데이터 탐색과 이해를 지원합니다.

레이크하우스 포맷의 트랜잭션 관리

Apache Iceberg, Delta Lake, Apache Hudi, Apache Paimon 같은 레이크하우스 테이블 포맷은 메타데이터를 통해 ACID 트랜잭션과 Time Travel을 구현합니다. 중앙 메타스토어는 이 메타데이터의 버전 관리와 카탈로그 등록을 책임집니다.

운영 자동화

테이블 최적화(Compaction), 스냅샷 만료(Snapshot Expiration), 컬럼 통계 수집 등 운영 작업을 카탈로그 레벨에서 자동화할 수 있어, 팀의 운영 부담을 크게 줄입니다.

메타스토어 없이 접근할 때의 문제 — 데이터 늪(Data Swamp)

메타스토어 없이 오브젝트 스토리지 경로를 직접 지정해 데이터에 접근하는 것은 기술적으로 가능합니다. 그러나 규모가 커질수록 데이터 늪(Data Swamp) 으로 전락할 위험이 높아집니다.

# 메타스토어 없이 Parquet 파일 직접 읽기 (물리적 경로 의존)
df = spark.read.format("parquet").load("s3://sales/2020/01/1.parquet")
df.printSchema()
df.show()

# Delta Lake 테이블 직접 읽기 (경로 기반)
df = spark.read.format("delta").load("s3://sales/")
df.printSchema()
df.show()

위 방식의 핵심 한계:

물리적 경로 의존: 논리적 테이블명 없이 S3 경로를 직접 지정하므로, 스토리지 구조 변경 시 모든 파이프라인이 깨집니다.
스키마 변경 추적 불가: 각 팀·엔진이 독립적으로 메타데이터를 관리하면 스키마 불일치가 발생합니다.
ACID 보장 불가 / 동시성 손상: 동시 쓰기 시 데이터 손상 위험이 있으며, 트랜잭션 격리를 보장할 수 없습니다.
접근 권한·Lineage 관리 불가: 컬럼·행 수준 보안 정책을 일관되게 적용할 수 없습니다.
성능 최적화 불가: 파일 프루닝(File Pruning)·파티션 통계는 카탈로그에 등록된 메타데이터 없이는 활용되지 않습니다.

3. 중앙 메타스토어 제품 조사

Hive Metastore (HMS)

유형: 오픈소스 (Apache 2.0)

2010년경 Apache Hive 프로젝트의 일부로 시작된 가장 전통적인 메타스토어입니다. 데이터베이스, 테이블, 스키마, 파티션, SerDe 정보를 RDBMS(MySQL, PostgreSQL 등) 백엔드에 저장하며, Thrift 서비스를 통해 다중 엔진이 동일한 메타데이터에 접근합니다.

특징

가장 성숙하고 광범위하게 채택된 표준으로, 거의 모든 빅데이터 엔진과 호환됩니다.
단일 테이블 단위 트랜잭션만 지원하며, 멀티 테이블 원자적 변경은 불가능합니다.
Thrift 기반 비공식 표준으로, REST가 아니어서 클라우드 네이티브 환경에 어색합니다.
파티션 메타데이터가 많아질 경우 RDBMS 병목이 발생합니다.
2026년 기준 업계 컨센서스는 신규 프로젝트에서는 HMS 대신 REST Catalog로 시작하라는 방향입니다.

매니지드 서비스 옵션: AWS Glue Data Catalog, GCP Dataproc Metastore, Cloudera CDP, EMR/HDInsight/Dataproc 내장

AWS Glue Data Catalog

유형: 클라우드 매니지드 (AWS, Closed Source)

AWS의 완전 매니지드 통합 메타데이터 저장소로, S3·RDS·Redshift·Athena 전반에 걸쳐 테이블 정의와 스키마를 관리합니다. 서버리스 구조로 자동 스키마 디스커버리(Crawlers), Schema Registry, Iceberg 테이블 자동 최적화(Compaction·Snapshot Expiration·컬럼 통계)를 제공합니다.

특징

AWS 생태계(Athena, EMR, Redshift, SageMaker, Lake Formation) 전체에서 사실상 표준 카탈로그입니다.
Iceberg 네이티브 자동 최적화는 타 매니지드 카탈로그 대비 차별화된 기능입니다.
월 100만 객체·요청까지 무료 티어를 제공합니다.
AWS 종속(Vendor Lock-in)이 강하며, Iceberg REST 표준 미준수로 외부 엔진은 어댑터가 필요합니다.

가격: 객체 수($1/100만 개) + 요청 수($1/100만 건) + 최적화 작업($0.44/DPU-시간)

Google Cloud Dataproc Metastore

유형: 클라우드 매니지드 (GCP, 백엔드는 OSS HMS)

GCP의 완전 매니지드 Apache Hive Metastore 서비스입니다. HMS Thrift API를 100% 호환하여 기존 Hive 기반 워크로드를 그대로 이전할 수 있습니다. 2024년 이후 GCP는 Iceberg 중심 신규 워크로드를 위해 BigLake Metastore(Iceberg REST 카탈로그 규격 준수)를 별도 출시하였습니다.

특징

HMS 100% 호환으로 Hadoop/Hive 생태계 마이그레이션 부담이 최소화됩니다.
Zonal HA 기본 제공, Regional HA·DR 옵션으로 엔터프라이즈 SLA를 충족합니다.
항상 켜진 인스턴스 기반 과금으로 소규모·간헐적 워크로드에서 비용이 높습니다.
Iceberg 신규 워크로드는 BigLake Metastore와 병행 운영이 필요합니다.

가격: Enterprise 기준 Scaling Factor × $3.42/시간 (최소 프로덕션 권장 시 월 약 $2,462)

Delta Lake Unity Catalog — 상용 버전 (Databricks)

유형: 상용 매니지드 (Databricks SaaS)

Databricks가 2022년 GA한 통합 거버넌스 솔루션으로, 3-Level Namespace(catalog.schema.table)를 도입하여 기존 Hive의 2-Level 한계를 해결하였습니다. HMS와 Apache Ranger의 기능을 Databricks 플랫폼 내에서 통합한 형태로, 단순 메타스토어를 넘어 AI·ML 자산까지 거버넌스 범위를 확장합니다.

특징

ANSI SQL 기반 GRANT/REVOKE, ABAC, 행·열 수준 보안(Row Filter·Column Mask)을 제공합니다.
컬럼 단위 Lineage 자동 추적, Audit 로그(System Tables), Delta Sharing 통합이 포함됩니다.
MySQL·PostgreSQL·Snowflake·BigQuery·Redshift 등을 Lakehouse Federation으로 가상 마운트합니다.
Databricks 워크스페이스 종속이 강하며, Apache Ranger와의 공식 연동은 없습니다(대체 포지셔닝).

Delta Lake Unity Catalog — 오픈소스 버전

유형: 오픈소스 (Apache 2.0, LF AI & Data Foundation)

2024년 6월 Databricks가 Apache 2.0 라이선스로 공개하고 LF AI & Data Foundation에 기증한 버전입니다. OpenAPI 기반 REST API, Iceberg REST Catalog API 호환, 멀티 포맷·멀티 엔진 지향 설계가 핵심입니다.

상용 vs 오픈소스 주요 차이

영역 OSS 상용 (Databricks)

인증/SSO	기본 Bearer 토큰	OIDC/SAML SSO, SCIM
권한 모델	기본 GRANT/REVOKE	ABAC, Row Filter, Column Mask
Lineage	미지원 (로드맵)	컬럼 단위 자동 캡처
Audit Log	미지원	System Tables 자동 제공
Lakehouse Federation	미지원	MySQL/Snowflake/BigQuery 등
자동 최적화	미지원	Predictive Optimization
AI/ML 자산	추상화만	MLflow·Feature Store 완전 통합
Delta Sharing	별도 서버 필요	네이티브 통합

OSS는 "카탈로그 API + 멀티 포맷 추상화" 가 핵심이며, 거버넌스 심화 기능(ABAC, Lineage, Audit, Federation)은 상용 버전의 차별점으로 남아 있습니다.

Tabular

유형: 상용 매니지드 (2024년 6월 Databricks 인수, 신규 채택 비권장)

Apache Iceberg 공동 창시자 Ryan Blue가 2021년 설립한 Iceberg 전용 매니지드 카탈로그·자동 최적화 서비스입니다. 2024년 6월 Databricks가 인수하여 신규 고객 온보딩이 중단되었으며, 기존 고객은 Unity Catalog로 이전이 안내됩니다.

핵심 가치 (인수 이전)

Iceberg Auto-compaction·Auto-clustering·Snapshot Expiration 등 자동화
Iceberg REST Catalog 사양의 레퍼런스 구현 수준
멀티 엔진(Spark, Trino, Flink, Snowflake, Athena) 동시 접근 안정성

Project Nessie

유형: 오픈소스 (Apache 2.0, Dremio 주도) / 매니지드: Dremio Arctic

Dremio가 주도하여 시작한 트랜잭셔널 카탈로그로, Git-like 의미론(branch, tag, commit, merge)을 데이터 레이크에 적용합니다. 카탈로그 메타데이터를 버전 관리되는 데이터 구조에 저장하여 격리된 dev/test 환경, 데이터 실험, 롤백, Zero-copy Clone을 지원합니다.

특징

Multi-table Atomic Commit을 지원하여 여러 테이블에 걸친 트랜잭션 보장이 가능합니다.
Iceberg 외 포맷(Delta, Hudi, Paimon) 지원이 약해 실질적으로 Iceberg 전용에 가깝습니다.
메타데이터 백엔드로 RocksDB, MongoDB, DynamoDB, PostgreSQL 등 다양한 옵션을 지원합니다.
매니지드 서비스: Dremio Arctic (자동 Compaction, Garbage Collection 등 추가)

Apache Polaris

유형: 오픈소스 (Apache 2.0 Incubating, Snowflake 기증) / 매니지드: Snowflake Open Catalog

2024년 7월 Snowflake가 오픈소스화하고 ASF에 기증한 Apache Iceberg REST Catalog 표준의 레퍼런스 구현체입니다. Vendor-neutral 멀티 엔진 상호운용성에 초점을 맞추며, Credential Vending(엔진별 임시 자격증명 발급)과 Fine-grained RBAC을 기본으로 포함합니다.

특징

Iceberg REST 표준의 레퍼런스 구현으로 미래 표준에 가장 잘 정렬되어 있습니다.
Snowflake, Databricks, Dremio, AWS, GCP 어디에도 락인되지 않는 벤더 중립성을 표방합니다.
Delta Lake와 Hudi 지원이 추가되며 Unified Catalog로 확장 중입니다.
2024년 오픈소스화로 성숙도 한계가 있으며, Git-like Branching 같은 고급 기능은 없습니다.

Snowflake Open Catalog

유형: 클라우드 매니지드 (백엔드는 OSS Apache Polaris)

Snowflake가 제공하는 Apache Polaris 기반 매니지드 카탈로그 서비스로, 2024년 10월 GA되었습니다. Internal Catalog(직접 관리, R/W)와 External Catalog(Snowflake·Glue 등에서 동기화, R/O) 두 모드를 지원합니다.

특징

Iceberg REST 표준 100% 준수로 진정한 멀티 엔진 상호운용성을 제공합니다.
오픈소스(Apache Polaris) 기반으로 자체 호스팅도 가능합니다.
Snowflake 워크로드와 외부 OSS 엔진 간 단일 카탈로그 운영이 가능합니다.
2026년 상반기부터 REST API 요청 단위 빌링 시작 예정으로 TCO 예측이 불확실합니다.

Apache Gravitino

유형: 오픈소스 (Apache 2.0, Datastrato 기증 → ASF TLP) / 매니지드 서비스: 없음 (자체 호스팅만)

2023년 Datastrato가 개발하여 2024년 6월 Apache Incubator에 기증, 2025년 6월 Apache Top-Level Project(TLP)로 정식 졸업한 AI-native 유니버설 메타스토어입니다. "카탈로그의 카탈로그(catalog of catalogs)"를 표방하며, 테이블·파일셋·ML 모델·벡터·메시징 토픽까지 통합 거버넌스를 제공합니다.

참고: LinkedIn의 오픈소스 프로젝트는 별도의 OpenHouse(Iceberg 테이블 RESTful 프로비저닝)이며, Gravitino는 Datastrato가 기증한 별개 프로젝트입니다.

핵심 아키텍처: Metalake → Catalog → Schema → Table/Fileset/Model

Metalake: 최상위 컨테이너/테넌트 (조직 단위)
Catalog: 특정 메타데이터 소스(Hive, Iceberg, MySQL 등)와 연결되는 Connector 묶음
Schema / Table / Fileset / Model / Topic: 테이블뿐 아니라 ML 모델, 파일셋, 메시징 토픽까지 1급 객체로 모델링

데이터를 복제·동기화하지 않고 원본 시스템에서 직접 관리(direct management) 하는 방식으로 sync 지연·불일치가 없습니다.

특징

Iceberg / Delta Lake(1.2+) / Hudi / Paimon을 모두 Generic Lakehouse Catalog로 지원합니다.
Trino, Spark, Flink, Apache Doris, ClickHouse 등 폭넓은 MPP 엔진을 지원합니다.
ML 모델(Model Catalog), 파일셋(Fileset), Lance 벡터 임베딩, MCP Server를 1급 시민으로 통합하는 AI-native 설계입니다.
HMS, JDBC 기반 RDB(MySQL, PostgreSQL, ClickHouse 등), Kafka 토픽을 Federation으로 직접 관리합니다.
2026년 3월 기준 최신 버전은 1.2.0이며, Uber·Pinterest·Apple·Cloudflare 등에서 프로덕션 운영 중입니다.
매니지드 SaaS 서비스는 없으며, Kubernetes/EC2 기반 자체 호스팅이 기본 운영 모델입니다.

4. 제품들과 Data Lakehouse 포맷과의 조합

카탈로그 Apache Iceberg Delta Lake Apache Hudi Apache Paimon

HMS	HiveCatalog 지원 (단일 테이블 한계)	Spark Delta Sync 경유 (제한적)	HiveSync 지원	HiveCatalog 지원
AWS Glue	네이티브 + 자동 최적화	네이티브	네이티브	공식 미지원 (Flink 경유)
GCP Dataproc Metastore	Spark/Trino 경유 (BigLake 권장)	Spark 경유 지원	Dataproc 1.3+ 지원	Flink 커넥터 경유 가능
UC 상용 (Databricks)	UniForm + REST API	1급 시민 (최우선)	External Table만	미지원
UC OSS	REST API 네이티브	네이티브	External Table	약함
Tabular (단종)	1급 시민 (유일)	미지원	미지원	미지원
Project Nessie	1급 시민 (핵심)	약함/비공식	약함/비공식	약함/비공식
Apache Polaris	1급 시민 (레퍼런스)	Generic Table API 추가 지원	로드맵/제한적	미지원
Snowflake Open Catalog	1급 시민	Polaris Generic Table 경유	로드맵	미지원
Apache Gravitino	1급 시민 (REST)	Generic Lakehouse Catalog 지원 (1.2+)	지원	1급 시민

포맷별 최적 조합 요약

Iceberg 중심 → Apache Polaris / Snowflake Open Catalog / Project Nessie / AWS Glue / Apache Gravitino
Delta Lake 중심 → UC 상용 (Databricks) / UC OSS / Apache Gravitino
Hudi 중심 → HMS / AWS Glue / GCP Dataproc Metastore / Apache Gravitino
Paimon 중심 → HMS (Flink + HiveCatalog) / AWS Glue (Flink 경유) / Apache Gravitino (1급 시민)
멀티 포맷 → HMS (넓지만 낡음) / UC OSS (Iceberg·Delta 지원) / Apache Gravitino (4대 포맷 통합)

Apache Paimon 자체 카탈로그 옵션: Paimon은 외부 중앙 메타스토어에 의존하지 않는 경량 카탈로그를 자체적으로 제공합니다. Filesystem Catalog(로컬·S3·HDFS 경로 기반, 운영 부담 최소), JDBC Catalog(MySQL·PostgreSQL 기반, 팀 공유), REST Catalog(HTTP 기반, 분산 환경) 세 가지 옵션이 있어, 소규모 환경이나 Flink 전용 파이프라인에서 HMS 없이 독립 운영이 가능합니다. HMS 운영 부담을 줄이고 싶은 Paimon 중심 팀에게 유효한 선택지입니다.

5. 제품들과 MPP 엔진, 클라우드 서비스, DB와의 조합

MPP 엔진 호환성

카탈로그 Spark Trino / Presto Flink Hive Doris / StarRocks

HMS	✅ 완전	✅ 완전	✅	✅ 네이티브	✅ (대부분)
AWS Glue	✅ (EMR)	✅ Athena (Trino 기반)	✅	✅ (EMR Hive)	부분 (어댑터 필요)
GCP Dataproc Metastore	✅	✅	✅	✅	간접
UC 상용	✅ (DBR 최적화)	✅ (커넥터)	제한적	—	간접
UC OSS	✅ (Spark 3.5+)	✅	제한적	—	Iceberg REST 경로
Project Nessie	✅	✅	✅	제한적	Dremio 경유
Apache Polaris	✅	✅	✅	—	✅ Doris, StarRocks
Snowflake Open Catalog	✅	✅	✅	—	✅ (REST 호환 엔진)
Apache Gravitino	✅	✅	✅	—	✅ Doris, ClickHouse

클라우드 서비스 통합

카탈로그 AWS EMR GCP Dataproc Azure HDInsight Snowflake BigQuery

HMS	✅ 기본	✅ (Dataproc Metastore)	✅ 기본	—	—
AWS Glue	✅ 1급	—	—	External Catalog	—
GCP Dataproc Metastore	—	✅ 1급	—	—	BigLake 연계
UC 상용	간접 (OSS 커넥터)	간접	간접	Federation	Federation
UC OSS	✅ (직접 배포 가능)	✅	✅	Iceberg REST	Iceberg REST
Project Nessie	사용자 구성	사용자 구성	사용자 구성	—	—
Apache Polaris	사용자 구성 (REST)	사용자 구성 (REST)	사용자 구성	✅ Open Catalog	—
Snowflake Open Catalog	✅ (REST 연결)	✅ (REST 연결)	✅	✅ 네이티브	—
Apache Gravitino	사용자 구성	사용자 구성	사용자 구성	—	—

RDB / 외부 DB 페더레이션

UC 상용: MySQL, PostgreSQL, Snowflake, BigQuery, Redshift, SQL Server, Salesforce, Oracle, Teradata 페더레이션
AWS Glue: Lake Formation 통해 RDS·Redshift·Aurora 메타데이터 통합
GCP Dataproc Metastore: BigQuery와 메타데이터 노출 가능
Apache Polaris / Snowflake Open Catalog: Federation 로드맵 (Unity Catalog, Glue, HMS에서 점진적 통합 예정)
Apache Gravitino: HMS, MySQL, PostgreSQL, ClickHouse, Kafka 등을 Connector로 직접 Federation. Snowflake는 JDBC Catalog 또는 Iceberg REST 방식으로 연동 가능 (→ 9번 아키텍처 패턴 참고)
HMS / Nessie / UC OSS: 외부 DB 페더레이션 기능 없음 (엔진 레벨에서 처리)

6. 거버넌스 도구 통합

중앙 메타스토어는 메타데이터 관리의 기술 계층을 담당하지만, 엔터프라이즈 데이터 거버넌스는 인가(Authorization), 데이터 계보(Lineage), 데이터 발견(Discovery)·분류(Classification)를 별도 레이어에서 처리하는 경우가 많습니다.

Apache Ranger — 정책 기반 인가 엔진

Apache Ranger는 Hadoop 생태계에서 출발한 오픈소스 인가 프레임워크로, 중앙화된 정책 관리와 감사 로깅을 제공합니다.

메타스토어 통합 방식 성숙도

HMS/Hive	RangerHiveAuthorizerFactory 플러그인으로 네이티브 통합. 테이블·켼럼·태그 기반 정책	Production (CDP/EMR 표준)
AWS Glue	직접 플러그인 없음. EMR + Ranger 조합으로 콤퓨트 레벨 인가. Glue 자체는 Lake Formation 사용	간접 지원
Databricks UC	네이티브 미지원. Privacera(Ranger 상용 fork)가 UC 정책을 Ranger UX로 매핑	써드파티 우회
Apache Polaris	RANGER-4910에서 플러그인 개발 요청 중. 2026년 4월 기준 미출시. Polaris 자체 RBAC 사용	로드맵 / 부재
Apache Gravitino	Gravitino 자체 RBAC으로 인가. Ranger 직접 통합 없음	부재

Ranger가 여전히 필요한 케이스

HDFS, HBase, Kafka, Solr 등 레거시 Hadoop 자산 비중이 높은 환경
온프레미스·엠어개플(air-gapped) 데이터 플랫폼 (CDP, MapR-legacy)
다중 엔진(Trino + Hive + HBase)에 동일 Tag 기반 정책(TBAC) 적용이 필요한 경우
컴플라이언스 요건으로 OSS 자체 호스팅이 필수인 경우

Apache Atlas — 데이터 계보 및 분류

Apache Atlas는 JanusGraph + Solr 기반 메타데이터·거버넌스 프레임워크로, Lineage 자동 캐포와 태그 기반 분류(Classification)를 제공합니다.

카탈로그 통합 방식

HMS/Hive	HiveHook 네이티브 통합. 가장 성숙. 테이블·켼럼 레벨 Lineage 자동 캐포
AWS Glue	Glue 메타데이터를 Atlas로 import하는 패턴 (자동 sync 아님 import 기반)
UC / Polaris / Gravitino	네이티브 미지원. UC는 자체 Lineage 제공

2026년 기준 Atlas는 Hadoop/CDP 레거시 환경에 최적화되어 있으며, 클라우드 네이티브 카탈로그와의 통합이 약합니다. 신규 환경에서의 Atlas 도입은 권장하지 않으며, OpenMetadata나 DataHub 같은 모던 거버넌스 카탈로그가 대안입니다.

OpenMetadata — 모던 오픈소스 거버넌스 카탈로그

OpenMetadata는 120개 이상의 커넥터를 제공하는 모던 오픈소스 메타데이터 플랫폼으로, Ranger+Atlas 조합을 대체하는 단일 거버넌스 레이어를 목표로 합니다.

카탈로그 커넥터 상태

HMS/Hive	GA, 성숙. 메타데이터 + Lineage + Profiling 지원
AWS Glue	GA. 메타데이터·Lineage·파티션 정보 수집
Databricks UC	GA (unity-catalog 커넥터). UC Lineage 활용
Apache Polaris	Iceberg REST 커넥터로 우회. 전용 커넥터는 미출시
Project Nessie	Iceberg 커넥터 + Nessie REST로 Branch 메타데이터 활용
Apache Gravitino	직접 커넥터 없음. HMS/Iceberg 경로로 우회

거버넌스 아키텍처 권장 패턴 — Two-Layer Architecture

업계는 Two-Layer Architecture로 수렴하고 있습니다.

기술 카탈로그(Technical Catalog): Polaris, UC, Glue, HMS, Nessie, Gravitino — Iceberg/Delta REST 스펙 구현, 엔진 인가의 source of truth
거버넌스 카탈로그(Governance Catalog): OpenMetadata, DataHub, Atlan, Collibra — 비즈니스 메타데이터, Lineage, Discovery, Stewardship

선택 가이드

환경 권장 조합

Greenfield (신규 2026)	카탈로그 네이티브 RBAC (UC/Lake Formation/Polaris) + OpenMetadata
Brownfield (Hadoop 레거시)	Ranger + Atlas 유지. 클라우드 마이그레이션 시 Privacera로 정책 연속성 확보
하이브리드 멀티 클라우드	카탈로그 네이티브가 Enforcement, OpenMetadata/Collibra가 Governance Layer

7. TCO 비교

카탈로그별 비용 구조

카탈로그 소형 (월) 중형 (월) 대형 (월) 과금 모델

HMS (자체)	~$200 + 0.1 FTE	~$780 + 0.3 FTE	~$3,250 + 0.7 FTE	인프라 + 운영 인력
AWS Glue	~$4	~$140	~$2,500	객체 수 + 요청 수
GCP DPMS Enterprise	$2,500 (항상 켜집)	$2,500	$5,000	인스턴스 시간 (고정)
UC 상용 (Databricks)	+$750 추가	+$7,500 추가	+$75,000 추가	DBU 프리미엄 차액
Polaris / Open Catalog	$0 → ~$50 (H1 과금 후)	$0 → ~$200	$0 → ~$2,000	API 요청 (2026 H1~)
Project Nessie OSS	~$200	~$700	~$2,500	인프라
Apache Gravitino OSS	~$200	~$700	~$2,500	인프라

소규모 워크로드: AWS Glue(~$4/월) 또는 Polaris(현재 무료)가 압도적으로 저렴합니다.
GCP Dataproc Metastore는 워크로드가 없어도 항상 과금되므로 소형 환경에는 비효율적입니다.
UC 상용은 Databricks를 이미 사용 중인 환경에서는 증분 비용(marginal cost)이지만, 비-Databricks 환경에서는 매우 비싘니다.

숨겨진 비용 요소

운영 인력 (가장 큰 숨겨진 비용)

자체 운영(HMS·Polaris OSS·Nessie·Gravitino)은 시니어 데이터 엔지니어 기준 대형 환경에서 연 $75K–$150K의 운영 인건비가 발생합니다. 매니지드 서비스(Glue·DPMS·UC)는 0.05–0.3 FTE 수준으로 감소합니다.

마이그레이션 비용

경로 예상 공수

HMS → Glue / DPMS	메타데이터 export/import + 파티션 재등록. 중형 1–3 person-month
HMS → Unity Catalog	External table 변환 + UC catalog 등록 + 권한 재정의. 1–6 person-month
HMS → Iceberg REST (Polaris/Nessie)	Hive→Iceberg 테이블 변환(스냅샷/리라이트) + 카탈로그 등록. 테이블당 컴퓨트 비용 발생
Ranger → UC 거버넌스	정책 자동 변환 도구 부재로 수작업 변환 + 검증 필요. 6–12 person-month (대규모)

Lock-in 탈출 비용

UC 상용 → 타 카탈로그: Managed Table을 External/Iceberg로 변환, 정책 재구성 필요. 사실상 재마이그레이션 수준
Glue → 타 카탈로그: Iceberg 테이블이면 거의 무비용. Hive 테이블은 중간 수준
OSS 카탈로그(Polaris·Nessie·HMS·UC OSS·Gravitino): 락인 거의 없음. OSS의 핵심 TCO 장점

Snowflake Open Catalog 과금 주의

2026년 H1부터 과금이 시작될 예정입니다. 현재 무료 기간에 마이그레이션을 완료하면 전환 비용 없이 진입 장벽을 낙었습니다.

8. 마이그레이션 전략

HMS에서 현대적 카탈로그로의 이전

레거시 Hive Metastore에서 현대적 카탈로그로 이전할 때는 점진적 접근(Incremental Migration) 이 권장됩니다. Big Bang 방식은 롤백이 어렵고 운영 중단 위험이 높습니다.

단계별 마이그레이션 로드맵

Phase 1 — 인벤토리 및 의존성 분석 (1–2개월)

전체 테이블 목록, 파티션 수, 접근 엔진, 권한 정책 문서화
비즈니스 크리티컈 테이블과 배치 파이프라인 식별
대상 카탈로그 선택 및 POC 진행

Phase 2 — Iceberg 포맷 변환 (테이블당)

신규 테이블: 처음부터 Iceberg 포맷으로 작성
기존 Hive 테이블: ALTER TABLE ... SET TBLPROPERTIES ('table_type'='ICEBERG')로 인플레이스 마이그레이션 또는 CALL system.rewrite_data_files()로 전체 재작성

Phase 3 — 카탈로그 등록 및 이중 운영

새 카탈로그(Polaris·Nessie·Glue 등)에 변환된 테이블 등록
HMS와 새 카탈로그를 병행 운영(dual-write/dual-read) 기간 유지
엔진별 카탈로그 설정 변경 (Spark spark.sql.catalog.*, Trino catalog.properties)

Phase 4 — 트래픽 이전 및 HMS 폐기

팀별·도메인별 순차 이전
HMS 메타데이터 아카이브 보관 후 폐기

클라우드별 권장 마이그레이션 경로

현재 환경 대상 카탈로그 주요 도구/서비스

HMS + AWS EMR	AWS Glue Data Catalog	AWS Glue Crawler, EMR Iceberg 설정
HMS + GCP Dataproc	GCP Dataproc Metastore → BigLake Metastore	Dataproc Metastore import, BigLake REST Catalog API
HMS + Databricks	Databricks Unity Catalog	Databricks UPGRADE TABLE 명령, HMS Federation → UC External Location
HMS + 멀티 클라우드	Apache Polaris / Nessie (자체 호스팅)	PyIceberg migration tool, Iceberg REST 카탈로그 마이그레이션 스크립트

마이그레이션 주요 함정(Pitfall)

파티션 수 과다: HMS에서 수억 개 파티션이 있는 테이블은 Iceberg 변환 시 메타데이터 재생성 비용이 큰 점을 쿠사해야 합니다. 먼저 파티셔닝 전략을 재검토하십시오.
직렬화 포맷(SerDe) 불일치: 특수 SerDe를 사용하는 테이블은 Iceberg 변환 전 Parquet/ORC 재작성이 필요합니다.
권한 정책 공백: Ranger 정책을 새 카탈로그의 RBAC 모델로 1:1 매핑하는 자동화 도구가 없으므로, 수작업 변환 및 검증 기간을 충분히 확보하십시오.
엔진별 동작 차이: HMS와 Iceberg 카탈로그는 파티션 프루닝, 통계 활용 방식이 다를 수 있어 쿼리 성능 회귀(regression) 검증이 필요합니다.

9. 아키텍처 패턴

단일 카탈로그 vs 멀티 카탈로그

항목 단일 카탈로그 멀티 카탈로그

운영 복잡도	낙음	높음
벤더 종속 위험	높음 (단일 벤더 의존)	낙음
멀티 클라우드 지원	어려움	자연스러움
엔진 다양성	제한	유연
거버넌스 일관성	강함	별도 Federation Layer 필요
권장 상황	단일 클라우드·단일 팀	멀티 클라우드·대형 조직·Data Mesh

Two-Layer Architecture

┌──────────────────────────────────────────────────┐
│    거버넌스 카탈로그 (Governance Layer)       │
│  OpenMetadata / DataHub / Collibra / Atlan  │
│  Lineage, Discovery, Classification         │
└──────────────────────────────────────────────────┘
          ↑ 메타데이터 수집 (Ingest)
┌──────────────────────────────────────────────────┐
│     기술 카탈로그 (Technical Layer)           │
│  HMS / Glue / Polaris / UC / Nessie / Gravitino │
│  스키마 관리, 엔진 인가, REST API, RBAC    │
└──────────────────────────────────────────────────┘
          ↑ 메타데이터 등록
┌──────────────────────────────────────────────────┐
│              스토리지 레이어                  │
│         S3 / GCS / ADLS / HDFS              │
│  Iceberg / Delta Lake / Hudi / Paimon       │
└──────────────────────────────────────────────────┘

멀티 카탈로그 Federation 패턴

방법 1 — 쿼리 엔진 레벨 Federation

Trino/Presto에서 여러 카탈로그를 catalog.properties로 동시 등록
SELECT * FROM glue_catalog.db.table JOIN nessie_catalog.db.table 형태로 크로스 카탈로그 조인 가능
운영 복잡도가 낙지만 쿼리 레이어에서만 통합

방법 2 — 카탈로그 레이어 Federation (Gravitino 방식)

Gravitino Metalake가 HMS·Glue·MySQL 등을 Connector로 흡수
엔진은 Gravitino 단일 엔드포인트에만 연결
양방향 direct management로 카탈로그 간 일관성 보장

방법 3 — 데이터 메시(Data Mesh) 분산 카탈로그

도메인별 독립 카탈로그 운영 (Domain Ownership)
중앙 거버넌스 카탈로그(OpenMetadata)가 각 도메인 카탈로그를 수집·조율
자율성과 거버넌스를 동시에 달성하는 현대적 패턴

Data Mesh에서의 카탈로그 역할

Data Mesh 아키텍처에서 카탈로그는 데이터 제품(Data Product) 의 메타데이터를 관리하는 계약(contract) 레지스트리 역할을 합니다.

각 도메인은 자체 기술 카탈로그(HMS·Iceberg REST·UC OSS 등)를 운영합니다.
중앙 거버넌스 카탈로그는 각 도메인의 데이터 제품 스펙, SLO, 오너십을 등록·검색합니다.
Apache Gravitino의 Metalake 개념은 이 패턴과 잘 정합합니다 — 도메인별 Catalog을 Metalake에서 연합 관리합니다.

Apache Gravitino + Snowflake 연동

Gravitino와 Snowflake를 연동하는 방법은 두 가지이며, 기존 환경과 목표에 따라 선택합니다.

방법 1 — JDBC Catalog 페더레이션 (Snowflake → Gravitino 데이터 소스 등록)

Gravitino가 Snowflake JDBC 드라이버를 통해 Snowflake를 Catalog로 등록합니다. Trino·Spark 등 엔진이 Gravitino 단일 엔드포인트를 통해 Snowflake 테이블과 Iceberg·HMS 테이블을 크로스 조인할 수 있습니다.

적합한 상황: Snowflake 워크로드가 이미 존재하고, Gravitino로 다른 데이터 소스(HMS, Iceberg, MySQL 등)와 통합해야 할 때

Gravitino REST API — Snowflake 카탈로그 등록

POST /api/metalakes/{metalake}/catalogs
{
  "name": "snowflake_catalog",
  "type": "RELATIONAL",
  "provider": "jdbc-postgresql",
  "comment": "Snowflake federation via Gravitino JDBC",
  "properties": {
    "jdbc-url": "jdbc:snowflake://<account>.snowflakecomputing.com/?db=<database>&warehouse=<warehouse>",
    "jdbc-user": "<username>",
    "jdbc-password": "<password>",
    "jdbc-driver": "net.snowflake.client.jdbc.SnowflakeDriver"
  }
}

Trino에서 크로스 소스 조인 예시

-- Gravitino를 통해 Snowflake 테이블 + Iceberg 테이블 조인
SELECT s.customer_id, s.revenue, r.region_name
FROM gravitino.snowflake_catalog.sales_db.orders s
JOIN gravitino.iceberg_catalog.warehouse.dim_region r
  ON s.region_id = r.region_id;

방법 2 — Iceberg REST (Gravitino → Snowflake Open Catalog 노출)

Gravitino가 관리하는 Iceberg 테이블 메타데이터를 Iceberg REST Catalog API로 노출하고, Snowflake Open Catalog(Polaris 기반)가 이를 구독하여 Snowflake가 동일 Iceberg 테이블을 External Iceberg Table로 직접 읽는 구조입니다.

적합한 상황: Iceberg 기반 레이크하우스를 Gravitino로 관리하고, Snowflake도 같은 테이블에 읽기 접근해야 할 때

아키텍처 흐름

Gravitino (Iceberg 메타데이터 관리 + 엔진 인가)
    ↕ Iceberg REST Catalog API
Snowflake Open Catalog (Polaris, Iceberg REST 클라이언트로 동기화)
    ↕ External Iceberg Table
Snowflake Warehouse (읽기 전용 쿼리)

Snowflake — External Catalog 통합 설정 예시

-- 1. Gravitino Iceberg REST를 External Catalog로 등록
CREATE CATALOG INTEGRATION gravitino_iceberg
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  CATALOG_NAMESPACE = 'warehouse'
  REST_CONFIG = (
    CATALOG_URI = 'https://<gravitino-host>:8090/iceberg/api'
    CATALOG_NAME = 'iceberg_catalog'
  )
  REST_AUTHENTICATION = (
    TYPE = OAUTH
    OAUTH_TOKEN_URI = 'https://<gravitino-host>:8090/oauth/token'
    OAUTH_CLIENT_ID = '<client_id>'
    OAUTH_CLIENT_SECRET = '<client_secret>'
    OAUTH_ALLOWED_SCOPES = ('PRINCIPAL_ROLE:ALL')
  )
  ENABLED = TRUE;

-- 2. Gravitino가 관리하는 Iceberg 테이블을 Snowflake External Table로 마운트
CREATE ICEBERG TABLE snowflake_db.public.orders
  EXTERNAL_VOLUME = 's3_iceberg_vol'
  CATALOG = 'gravitino_iceberg'
  CATALOG_TABLE_NAME = 'orders';

-- 3. Snowflake에서 조회
SELECT * FROM snowflake_db.public.orders LIMIT 100;

방법 비교

항목 방법 1 — JDBC Federation 방법 2 — Iceberg REST

Snowflake 역할	데이터 소스 (Gravitino가 읽음)	Iceberg 테이블 소비자 (Snowflake가 읽음)
데이터 흐름 방향	Snowflake → Gravitino → 엔진	Gravitino → Snowflake Open Catalog → Snowflake
Snowflake 쓰기	Gravitino 경유 가능 (JDBC Write)	Snowflake는 읽기 전용
구성 복잡도	낮음 (JDBC 드라이버 설치 + REST 등록)	중간 (Iceberg REST + OAuth 설정 필요)
권장 상황	기존 Snowflake 데이터를 다른 소스와 통합	Iceberg 레이크하우스 + Snowflake 동시 활용
락인 위험	없음 (JDBC 표준)	없음 (Iceberg REST 표준)

하이브리드 구성 — 방법 1 + 방법 2 동시 운용

단방향의 한계를 행과적으로 해결하는 구성입니다. Snowflake 원체 데이터는 JDBC로 Gravitino가 읽어 Iceberg 레이크하우스에 올리고, 처리된 Iceberg 테이블은 Snowflake Open Catalog을 통해 Snowflake가 다시 읽는 주기를 형성합니다.