LLM WikiAccess-protected knowledge portal
← 스터디 홈
21편 · 약 15분

Apache Polaris 1.x: Iceberg REST 카탈로그 표준이 멀티엔진 Lakehouse 거버넌스 레이어가 되는 방법

왜 지금 Polaris를 봐야 하나

Apache Polaris는 2026년 2월 18일 Apache Incubator를 졸업해 최상위 프로젝트(Top-Level Project, TLP)가 됐다. Snowflake와 Dremio가 함께 만들어 2024년 8월 ASF에 기증한 뒤 18개월 만이다. Google, Microsoft, Confluent, AWS를 포함한 수십 개 조직이 기여에 참여했다.

TLP 졸업 자체보다 중요한 것은 Polaris가 맡은 역할이다. Polaris는 Apache Iceberg의 REST Catalog 사양을 구현하는 서버다. 그리고 이 REST 사양은 2026년 현재 멀티엔진 Lakehouse의 사실상 표준 연결 프로토콜이 되고 있다. Spark, Flink, Trino, Dremio, StarRocks, DuckDB가 모두 같은 REST 엔드포인트로 동일한 테이블 목록을 볼 수 있다.

이 글은 Polaris가 왜 필요한지, 어떻게 동작하는지, 운영에서 무엇을 봐야 하는지 정리한다.

Iceberg 카탈로그가 필요한 이유

Apache Iceberg는 파일 포맷이 아니라 테이블 포맷이다. Parquet 파일을 어떻게 묶고, 어떤 메타데이터를 어디에 둘지를 정의한다. 그런데 Iceberg 스펙에는 "테이블 목록을 어떻게 가져오는가"에 대한 구현이 없다. 이 역할을 카탈로그가 담당한다.

초기에는 카탈로그가 여러 방식으로 존재했다. Hive Metastore에 올려두거나, Glue에 연결하거나, Nessie 같은 Git-style 카탈로그를 쓰는 방식이었다. 문제는 엔진마다 카탈로그 접속 방식이 달랐다는 것이다.

Iceberg REST Catalog 사양은 이 문제를 해결하기 위해 HTTP API를 정의했다. 카탈로그가 REST 엔드포인트를 노출하면, 어떤 엔진이든 같은 방식으로 테이블 정보를 가져갈 수 있다. Polaris는 이 사양의 오픈소스 서버 구현체다.

Polaris 아키텍처 개요

Apache Polaris — REST 카탈로그 서버 아키텍처 쿼리 엔진 Apache Spark Apache Flink Trino Dremio OSS StarRocks DuckDB REST Catalog 지원 엔진 Iceberg REST API 요청 Apache Polaris Iceberg REST Catalog 표준 구현체 REST API 레이어 Catalog API + Management API (OpenAPI) RBAC / 인증 Principal Roles Catalog Roles Privileges (테이블·네임스페이스) Credential Vending 권한 확인 후 단기 토큰 발급 스토리지 경로 한정 내부 카탈로그 Polaris가 직접 관리 Iceberg 테이블 메타데이터 스냅샷·파티션 정보 카탈로그 연합 AWS Glue Hive Metastore BigQuery Metastore (v1.5+) 메타데이터 백엔드 EclipseLink JPA (기본) · Eclipse Store (in-memory) · 외부 RDB 지원 로드맵 Policy Store 카탈로그·네임스페이스·테이블 레벨 접근 정책 저장소 클라우드 스토리지 AWS S3 AssumeRole → STS 단기 토큰 Azure Data Lake Storage Service Principal + 단기 Entra 토큰 Google Cloud Storage Service Account → 단기 OAuth2 토큰 Parquet / Iceberg 데이터 파일 단기 토큰 발급 토큰으로 직접 스토리지 접근 (엔진 → S3/GCS/ADLS)
Apache Polaris 아키텍처 — 멀티엔진 REST 카탈로그

Polaris는 두 가지 API 표면을 노출한다.

  • Catalog API: 표준 Iceberg REST 사양 구현. 테이블 목록 조회, 스냅샷 조회, 메타데이터 읽기/쓰기, 테이블 생성·삭제. 모든 엔진이 이 API를 통해 Iceberg 테이블에 접근한다.
  • Management API: Polaris 전용. Principal, Principal Role, Catalog, Catalog Role, Privilege 설정. 관리자가 거버넌스 정책을 구성하는 데 사용한다.

Credential Vending: 공유 키 없이 스토리지 접근

Polaris의 핵심 보안 메커니즘은 Credential Vending이다.

전통적인 방식에서는 S3나 GCS에 직접 접근할 수 있는 IAM 키나 서비스 계정 키를 엔진 클러스터에 배포했다. 이 방식의 문제는 키가 여러 곳에 분산되고, 키 유출 시 모든 데이터에 접근이 가능하다는 것이다.

Polaris의 Credential Vending은 다르게 동작한다.

  1. 쿼리 엔진이 테이블 접근을 요청한다.
  2. Polaris가 해당 Principal의 RBAC 권한을 확인한다.
  3. 권한이 확인되면 Polaris가 클라우드 프로바이더에게 단기, 범위 제한 토큰을 요청한다. 이 토큰은 해당 테이블의 스토리지 경로만 접근할 수 있고, 수 분~수 시간 안에 만료된다.
  4. 엔진이 이 단기 토큰으로 S3/GCS/ADLS에 직접 데이터 파일을 읽거나 쓴다.

2026년 기준으로 Credential Vending은 감사(audit) 수준으로 성숙했다. AWS CloudTrail에 세션 태그가 흘러들어가기 때문에, "어느 Principal이 어느 테이블에 어떤 작업을 요청했는가"를 스토리지 접근 로그에서 추적할 수 있다.

RBAC 모델: Principal Role / Catalog Role / Privilege

Polaris의 접근 제어는 세 가지 개념을 조합한다.

계층 1: Principal과 Principal Role
Principal
Polaris에 인증하는 주체
서비스 계정 또는 사용자
→
Principal Role
책임별 논리 그룹
예: "Spark-ETL-Role"
계층 2: Catalog Role과 Privilege
Catalog Role
카탈로그·네임스페이스·테이블 단위
리소스별 역할
→
Privilege
TABLE_READ_DATA
TABLE_WRITE_DATA
NAMESPACE_CREATE 등
계층 연결: Principal Role ↔ Catalog Role
관리자는 Catalog Role에 Privilege를 부여한다. 그런 다음 Principal Role에 Catalog Role을 grant한다. 이렇게 하면 "Spark-ETL-Role을 가진 모든 Principal은 analytics-catalog의 TABLE_READ_DATA 권한을 갖는다"는 정책이 만들어진다. 새 팀원이 추가될 때는 Principal에 Principal Role만 연결하면 된다.
RBAC 구조 — 세 계층의 연결

Polaris가 제공하는 주요 Privilege 유형:

Privilege설명
CATALOG_MANAGE_ACCESS카탈로그 전체 RBAC 설정 권한
NAMESPACE_CREATE카탈로그 내 네임스페이스 생성
TABLE_CREATE네임스페이스 내 테이블 생성
TABLE_READ_DATA테이블 데이터 읽기 (Credential Vending 포함)
TABLE_WRITE_DATA테이블 데이터 쓰기
TABLE_FULL_METADATA테이블 메타데이터 전체 접근

카탈로그 연합: 여러 메타데이터 소스를 하나의 거버넌스 레이어로

Polaris는 직접 관리하는 내부 카탈로그 외에도 외부 카탈로그를 연합(federation)으로 등록할 수 있다. 연합된 카탈로그는 Polaris에서 관리하지 않지만, Polaris REST API를 통해 접근할 수 있고 Polaris의 RBAC가 적용된다.

지원하는 외부 카탈로그:

  • AWS Glue: Glue Data Catalog의 Iceberg 테이블을 Polaris를 통해 노출.
  • Hive Metastore: 기존 HMS의 테이블을 Iceberg REST 프로토콜로 변환.
  • 외부 Iceberg REST: 다른 Iceberg REST 서버(예: 다른 Polaris 인스턴스)를 연합으로 등록.
  • Google BigQuery Metastore: v1.5.0(2026년 5월)에서 추가. GCP 환경에서 BigQuery 테이블을 Polaris를 통해 Spark나 Trino로 쿼리 가능.

하나의 Polaris 인스턴스가 여러 클라우드 환경의 데이터 소스를 단일 REST 엔드포인트로 통합하는 "카탈로그의 카탈로그" 역할을 할 수 있다.

Polaris 1.x 주요 릴리스 흐름

버전시기주요 변화
0.x (Incubating)2024년 8월 ~ 2025년초기 REST Catalog, 기본 RBAC
1.0.02025년 말첫 안정 릴리스. Credential Vending 표준화
1.3.02026년 초카탈로그 연합 개선, 비 Iceberg 데이터셋 처리
1.5.02026년 5월BigQuery Metastore 연합, 암호화 강화, 감사 로그 개선
TLP 졸업2026년 2월ASF Top-Level Project. 거버넌스 기반 안정화

운영자가 봐야 할 한계와 현실

메타데이터 백엔드 선택

현재 프로덕션에서 검증된 메타데이터 백엔드는 EclipseLink JPA 기반이다. 이는 내부 관계형 DB(RDBMS)에 Iceberg 메타데이터를 저장하는 구조다. 대규모 테이블 수(수십만 테이블)에서의 성능 특성은 아직 완전히 검증되지 않은 영역이다.

연합 카탈로그 읽기 전용 제약

연합 카탈로그는 기본적으로 읽기 전용이다. Glue나 HMS의 테이블을 Polaris를 통해 수정하는 시나리오는 현재 제한적으로만 지원된다. 쓰기 작업은 원래 카탈로그 직접 접근이 여전히 권장된다.

엔진별 REST Catalog 지원 성숙도

Spark, Flink, Trino는 Iceberg REST Catalog 클라이언트가 성숙해 있다. 그러나 일부 엔진은 특정 Iceberg REST 기능(서버 사이드 스캔 플래닝, V3 delete 벡터 등)을 아직 완전히 활용하지 못한다. 엔진과 Polaris 버전 조합을 먼저 테스트해야 한다.

HA와 수평 확장

Polaris 서버 자체의 HA와 수평 확장은 운영자가 직접 구성해야 한다. Kubernetes에서 여러 Pod을 띄우는 방식이 주로 쓰인다. 상태는 메타데이터 백엔드 DB에 집중되기 때문에, DB의 HA 설정이 Polaris HA의 전제가 된다.

Polaris와 대안 선택 기준

카탈로그적합한 상황
Apache Polaris멀티엔진·멀티클라우드 환경, 세밀한 RBAC, 오픈 거버넌스
AWS GlueAWS 단일 환경, 관리 오버헤드 최소화
Hive Metastore온프레미스 Hadoop 환경, 기존 자산 재사용
Unity Catalog (Databricks)Databricks 중심 환경, 상용 지원 필요
NessieGit-style 브랜치·버전 관리가 워크플로 핵심인 경우

오픈 표준 기반이 필요하고, 특정 클라우드나 벤더에 종속되지 않아야 하는 환경이라면 Polaris가 현재 가장 성숙한 선택지다.

운영자 도입 체크리스트

도입 전 확인
사용하는 엔진의 Iceberg REST 지원 버전 확인
Spark 3.5+, Flink 1.19+, Trino 440+ 권장
클라우드 스토리지 IAM 역할 설계
Polaris가 STS 단기 토큰 발급에 필요한 권한 부여
메타데이터 백엔드 DB 선택 및 HA 구성
Polaris Pod 무상태, DB가 단일 장애점
RBAC 설계
Principal Role 기준 정의
팀·역할·환경(prod/dev) 기준으로 분류
Catalog Role과 Privilege 매핑
최소 권한 원칙 적용
감사 로그 연결
Credential Vending → CloudTrail 세션 태그 설정
운영 모니터링
REST API 응답 시간 (특히 /v1/namespaces, /v1/tables 엔드포인트)
Credential Vending 성공/실패율
메타데이터 DB 연결 수 및 쿼리 지연
연합 카탈로그 동기화 지연 (외부 카탈로그 사용 시)
Apache Polaris 도입 체크리스트

이 졸업을 한 문장으로 요약하면

Apache Polaris의 TLP 졸업은 Iceberg REST 카탈로그 표준이 특정 벤더의 제품이 아니라 오픈 커뮤니티가 유지하는 인프라가 됐다는 선언이다.

2026년 현재, Polaris는 단순한 테이블 목록 서버가 아니라 멀티엔진 Lakehouse의 거버넌스 레이어로 역할이 확장되고 있다. Credential Vending이 감사 수준으로 성숙하고, BigQuery Metastore 연합이 추가되면서 멀티클라우드 환경에서도 단일 제어 지점으로 쓸 수 있는 기반이 갖춰졌다.

도입을 검토하는 운영자라면 엔진 버전 호환성과 메타데이터 백엔드 HA 설계부터 시작하는 것이 현실적이다.

References

  • Apache Polaris TLP 졸업 공식 발표 (2026-02-19): https://polaris.apache.org/blog/2026/02/19/apache-polaris-graduates-to-top-level-project/
  • Apache Polaris 공식 문서: https://polaris.apache.org/
  • Apache Polaris GitHub: https://github.com/apache/polaris
  • Apache Polaris 1.5.0 발표 — Dremio 블로그: https://www.dremio.com/blog/apache-polaris-1-5-0-deep-dive-into-the-future-of-open-data-catalogs/
  • Apache Polaris 아키텍처 심층 분석 (Cloudera 커뮤니티): https://community.cloudera.com/t5/Developer-Blogs/The-Architecture-of-Apache-Polaris-Under-the-Hood/ba-p/414066
  • The State of Apache Polaris in July 2026 (Alex Merced): https://dev.to/alexmercedcoder/the-state-of-apache-polaris-in-july-2026-from-incubating-catalog-to-the-governance-layer-of-the-1n3h
  • Apache Polaris Role-Based Access Control 문서: https://polaris.apache.org/in-dev/unreleased/managing-security/access-control/
  • Iceberg REST Catalog 사양: https://iceberg.apache.org/rest-catalog-spec/
  • The State of Apache Iceberg Catalogs in June 2026 — DEV Community: https://dev.to/alexmercedcoder/the-state-of-apache-iceberg-catalogs-in-june-2026-265e
  • Choosing the Right Iceberg Control Plane (2026-05): https://datalakehousehub.com/blog/2026-05-choosing-iceberg-control-plane/