중앙 메타스토어란 (레이크하우스 관점)

중앙 메타스토어는 다양한 데이터 처리 엔진과 플랫폼들이 데이터에 대한 정보를 공유하고 일관되게 접근할 수 있도록 모든 메타데이터를 한곳에 통합하여 관리하는 중앙 저장소입니다.

레이크하우스의 핵심 목표는 데이터 레이크의 유연성과 데이터 웨어하우스의 안정적인 데이터 관리 및 분석 성능을 결합하는 것입니다. 중앙 메타스토어는 이 두 세계를 연결하고 레이크하우스의 하우스 역할을 가능하게 하는 핵심적인 두뇌이자 관제탑이라고 할 수 있습니다.

레이크하우스에서 중앙 메타스토어가 필수적인 이유

중앙 메타스토어는 다양한 데이터 처리 엔진(Spark, Flink, Trino 등)이 데이터 레이크 위의 데이터에 대해 동일한 정보를 공유하고 일관되게 접근할 수 있도록 하는 단일 진실 공급원(Single Source of Truth) 역할을 합니다.

데이터의 통합된 뷰 제공 및 상호운용성

스파크로 작업한 테이블을 프레스토(Trino)에서도 동일하게 조회하고 Flink로 스트리밍 데이터를 쓴 결과를 하이브에서 배치 분석하는 등, 여러 엔진이 동일한 데이터를 매번 새롭게 정의할 필요 없이 즉시 사용할 수 있어야 합니다. 중앙 메타스토어는 "어떤 데이터가, 어디에, 어떤 형식과 스키마로 저장되어 있는지"에 대한 모든 정보를 한곳에 저장합니다. 모든 엔진은 이 중앙 메타스토어를 참조하므로 데이터에 대한 통합된 뷰를 가지게 됩니다.

ACID 트랜잭션 및 데이터 일관성 보장

여러 사용자가 동시에 데이터를 읽고 쓸 때 데이터가 깨지거나 잘못되는 것을 방지하고 데이터베이스처럼 안정적인 트랜잭션을 보장해야 합니다. Iceberg, Delta Lake, Hudi와 같은 현대적 테이블 포맷은 트랜잭션을 통해 데이터의 버전을 관리합니다. 중앙 메타스토어는 현재 테이블이 어떤 버전(어떤 메타데이터 파일)을 가리켜야 하는지에 대한 포인터를 원자적으로 업데이트하여 모든 사용자와 엔진이 항상 일관된 최신 데이터를 보도록 보장합니다.

스키마 관리 및 강제

데이터의 구조(스키마)가 변경될 때 이 변경 사항이 모든 사용자에게 일관되게 적용되어야 데이터 오류를 막을 수 있습니다. 중앙 메타스토어는 테이블의 공식적인 스키마를 저장하고 관리합니다. 스키마에 새로운 컬럼이 추가되거나 타입이 변경될 때, 이 중앙 메타스토어만 업데이트하면 모든 엔진이 변경된 스키마를 인지하고 데이터를 올바르게 해석할 수 있습니다.

성능 최적화

대용량 데이터 레이크에서 필요한 데이터만 빠르게 찾아 읽어오기 위해 불필요한 파일 스캔을 피해야 합니다. 메타스토어는 테이블의 파티션 정보, 각 파일의 통계 정보(최소/최대값 등)를 저장합니다. 쿼리 엔진은 이 정보를 활용하여 쿼리 조건과 무관한 파일들을 아예 읽지 않고 건너뛰는 파일 필터링(File Pruning)을 수행하여 쿼리 성능을 극대화합니다.

중앙 메타스토어가 없다면?

만약 중앙 메타스토어가 없다면, 레이크하우스는 데이터 늪(Data Swamp)으로 전락할 위험이 큽니다. 각 엔진이 자신만의 메타데이터를 따로 관리하게 되며 스파크에서 만든 테이블은 하이브에서 보이지 않고 그 반대도 마찬가지입니다. 이는 데이터 중복과 불일치를 야기하고 데이터 사일로를 발생시킵니다. 또한 여러 엔진이 동시에 같은 데이터 파일을 수정하려고 할 때 이를 제어할 방법이 없어 데이터가 쉽게 깨질 수 있고 ACID 트랜잭션을 보장할 수 없습니다. 마지막으로 데이터에 대한 접근 권한 관리, 데이터 계보 추적, 품질 관리 등을 중앙에서 통합적으로 수행하는 것이 불가능해집니다.

중앙 메타스토어가 없어도 s3://sales/2020/01/1.parquet 파일이 레이크하우스에서 테이블/컬럼 조회가 불가능하진 않습니다. 경로 기반으로 접근한다면 다음과 같이 조회가 가능합니다.

Parquet 파일 직접 읽기

# Spark 세션이 있다고 가정
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()

단, 경로 기반으로만 조회가 가능하며 우리가 생각하는 sales 테이블 조회와 같은 형태가 불가능합니다. 모든 사용자와 애플리케이션이 조회하고자 하는 파일의 물리적인 경로를 정확하게 알아야만 데이터에 접근이 가능합니다. 또한 A팀은 s3://sales/ 경로를 sales_table_A 라는 이름으로 자신들의 스파크 세션에서만 임시로 사용하고 B팀은 sales_raw 라는 이름으로 사용할 수 있습니다. 만약 A팀이 이 경로의 데이터를 변경하거나 스키마를 수정했을 때, B팀은 이 사실을 알 방법이 없습니다. B팀은 이전 스키마를 기준으로 쿼리를 실행하다가 오류를 겪거나 잘못된 분석 결과를 얻게 됩니다.

거버넌스와 ACID 트랜잭션에서도 문제가 발생합니다. 누가 sales 테이블을 읽고 쓸 수 있는지에 대한 권한 관리, 데이터의 변경 이력을 추적하는 리니지 관리, 데이터 품질 규칙 적용 등을 중앙에서 통합적으로 수행할 수 없고 여러 엔진(예: 스파크와 프레스토)이 동시에 같은 경로에 쓰기 작업을 시도할 때, 어떤 트랜잭션이 최종적으로 성공했는지에 대한 최종 중재자가 없어 동시성 문제가 발생할 가능성이 높아집니다.

관련 제품 또는 오픈소스

상용 제품 / 관리형 서비스

• AWS Glue Data Catalog: AWS 생태계의 사실상 표준 메타스토어입니다. Athena, EMR, Redshift Spectrum 등 다양한 AWS 서비스와 완벽하게 통합됩니다.
• Google Cloud Dataproc Metastore: 구글 클라우드에서 제공하는 완전 관리형 하이브 메타스토어 서비스로, Dataproc, BigQuery 등과 쉽게 연동됩니다.
• Databricks Unity Catalog: Databricks 플랫폼의 핵심으로, 테이블, 파일, AI 모델 등 모든 데이터 자산에 대한 통합 카탈로그 및 거버넌스 기능을 제공합니다.
• Tabular: Apache Iceberg의 창시자들이 만든 상용 서비스로, Iceberg를 위한 완전 관리형 카탈로그와 데이터 최적화 기능을 제공하여 운영 부담을 줄여줍니다.

오픈소스

• Apache Hive Metastore (HMS): 가장 전통적이고 널리 쓰이는 사실상의 표준 오픈소스 메타스토어입니다. 보통 MySQL이나 PostgreSQL을 백엔드 DB로 사용하여 메타데이터를 저장합니다.
• Project Nessie: "데이터를 위한 Git"을 표방하며, 데이터의 버전 관리(브랜치, 커밋, 병합) 기능을 제공하는 트랜잭셔널 카탈로그입니다. Iceberg와 잘 통합됩니다.
• Apache Polaris: Iceberg 커뮤니티에서 만든 현대적인 REST API 기반의 개방형 카탈로그 표준 구현체입니다. HMS를 대체하여 경량화되고 상호운용성 높은 중앙 카탈로그를 구축할 수 있습니다.
• Databricks Unity Catalog (오픈소스 버전): Databricks가 최근 핵심 기능을 오픈소스로 공개했습니다. Iceberg, Delta Lake, Parquet 등 다양한 포맷과 Hive Metastore API와도 호환되어, 특정 벤더에 종속되지 않는 개방형 중앙 카탈로그를 구축할 수 있습니다.

Iceberg는 설계 초기부터 카탈로그를 완전히 분리하고 API를 표준화하는 것을 매우 중요한 철학으로 삼았습니다. 이 덕분에 커뮤니티에서 Nessie나 Polaris와 같은 다양한 카탈로그 구현체들이 활발하게 등장할 수 있었습니다. 따라서 Nessie, Polaris, Tabular 등 다양한 카탈로그(메타스토어)를 선택할 수 있지만 다른 레이크하우스 포맷들은 Iceberg와 비교하면 선택할 수 있는 옵션이 제한적입니다.

아래는 레이크하우스 별, 선택할 수 있는 메타스토어입니다. Iceberg만 사용할 수 있는 제품은 제외했습니다.

포맷	Hive Metastore	AWS Glue	Unity Catalog	Nessie	주목할 만한 다른 옵션
Iceberg	✅	✅	✅ (UniForm)	✅ (핵심)	✅ (REST, Polaris 등 다수)
Delta Lake	✅	✅	✅ (핵심)	✅	파일 시스템 기반
Hudi	✅ (핵심)	✅	(제한적)	(개발 중)	JDBC 카탈로그, 자체 메타스토어
Paimon	✅	(HMS 통해)	(HMS 통해)	(미지원)	✅ (파일 시스템 및 JDBC 카탈로그 - 핵심)

여기서 Paimon은 HMS의 운영 부담을 줄이기 위한 자체적인 경량 카탈로그(파일 시스템, JDBC) 옵션을 강력하게 제공하는 특징이 있습니다.