Snowflake Open Catalog 개요

일반적으로 사용 가능(GA) — 정부 리전에서는 사용할 수 없어요.

새 고객은 Apache Iceberg™ 테이블 및 Iceberg와의 다중 엔진 상호 운용성을 위해 Snowflake Horizon Catalog를 사용해야 해요. 이전에 Snowflake Open Catalog 계정을 만든 적이 없는 고객은 첫 번째 Open Catalog 계정에 가입할 수 없어요.

기존 Snowflake Open Catalog 고객은 계속 사용할 수 있으며 필요한 경우 추가 Open Catalog 계정을 만들 수 있어요.

Snowflake Open Catalog는 Apache Iceberg™ 테이블용 카탈로그 구현이며 오픈소스 Apache Iceberg™ REST 프로토콜 위에 구축됐어요. Snowflake Open Catalog는 Apache Polaris™를 위한 관리 서비스예요.

Open Catalog를 사용하면 서로 다른 REST 호환 쿼리 엔진 전반에서 Iceberg 테이블에 대한 중앙 집중식의 안전한 읽기 및 쓰기 접근을 제공할 수 있어요.

Open Catalog는 현재 Snowflake 관리 인프라에 호스팅된 서비스로 제공돼요.

출처: Snowflake Open Catalog overview

본문

계정 가용성

이전에 Snowflake Open Catalog 계정을 만든 적이 없는 고객은 첫 번째 Open Catalog 계정에 가입할 수 없어요. 새 고객은 Apache Iceberg™ 테이블 및 Iceberg와의 다중 엔진 상호 운용성을 위해 Snowflake Horizon Catalog를 사용해야 해요.

이미 Open Catalog 계정이 하나 이상 있는 기존 Snowflake Open Catalog 고객은 Open Catalog를 계속 사용할 수 있으며 필요한 경우 추가 Open Catalog 계정을 만들 수 있어요. 지침은 Snowflake Open Catalog 계정 만들기를 참조하세요.

핵심 개념

이 섹션은 Snowflake에 호스팅된 Open Catalog 사용과 관련된 핵심 개념을 소개해요.

다음 다이어그램에서 중첩 네임스페이스가 있는 샘플 Open Catalog 구조가 Catalog1에 대해 표시돼요. Catalog2와 Catalog3에는 아직 테이블이나 네임스페이스가 만들어지지 않았어요.

카탈로그

Open Catalog에서는 하나 이상의 카탈로그 리소스를 만들어 Iceberg 테이블을 구성할 수 있어요.

Amazon S3, Azure 또는 Google Cloud Storage의 스토리지 구성에 값을 설정해 카탈로그를 구성하세요. Iceberg 카탈로그는 쿼리 엔진이 테이블을 관리하고 구성할 수 있게 해요. 카탈로그는 Apache Iceberg™ 테이블 사양의 첫 번째 아키텍처 계층을 형성하며 다음 작업을 지원해야 해요:

하나 이상의 Iceberg 테이블에 대한 현재 메타데이터 포인터 저장. 메타데이터 포인터는 테이블 이름을 해당 테이블의 현재 메타데이터 파일 위치에 매핑해요.
테이블의 현재 메타데이터 포인터를 테이블의 새 버전의 메타데이터 포인터로 업데이트할 수 있도록 원자적 작업 수행.

Iceberg 카탈로그에 대해 자세히 알아보려면 Apache Iceberg™ 문서를 참조하세요.

카탈로그 유형

카탈로그는 다음 두 가지 유형 중 하나일 수 있어요:

내부(Internal): 카탈로그가 Open Catalog로 관리돼요. 서드파티 쿼리 엔진이 이 카탈로그의 테이블에 읽고 쓸 수 있어요. 또한 Snowflake도 이 카탈로그의 테이블에 읽고 쓸 수 있어요.
외부(External): 카탈로그가 다른 Iceberg 카탈로그 제공자(예: Snowflake, Glue, Dremio Arctic)로 외부 관리돼요. 이 카탈로그의 테이블은 Open Catalog에 동기화돼요. 이 테이블은 Open Catalog에서 읽기 전용이에요. 현재 릴리스에서는 Snowflake 외부 카탈로그만 제공돼요.

카탈로그는 Amazon S3, Azure Storage 또는 Cloud Storage from Google을 가리킬 수 있는 스토리지 구성으로 구성돼요.

새 카탈로그를 만들려면 카탈로그 만들기를 참조하세요.

네임스페이스

카탈로그 내에서 Iceberg 테이블을 논리적으로 그룹화하기 위해 네임스페이스를 만들어요. 카탈로그는 여러 네임스페이스를 가질 수 있어요. 중첩 네임스페이스도 만들 수 있어요. Iceberg 테이블은 네임스페이스에 속해요.

Apache Iceberg™ 테이블과 카탈로그

내부 카탈로그에서 Iceberg 테이블은 Open Catalog에 등록되지만 쿼리 엔진을 통해 읽고 쓰여져요. 테이블 데이터와 메타데이터는 외부 클라우드 스토리지에 저장돼요. 테이블은 Iceberg 카탈로그로 Open Catalog를 사용해요.

Snowflake Open Catalog에서 테이블을 제거(purge)하지 않고 삭제했다면, 삭제된 테이블과 같은 이름과 위치로 새 테이블을 만들지 마세요. 그렇게 하면 사용자가 접근 권한이 없어야 할 원래 테이블의 데이터에 접근할 수 있게 될 수 있어요. 예를 들어 스토리지 디렉터리 위치가 /MyCatalog/Schema1/Table1인 Table1을 제거하지 않고 삭제했다면, 같은 Table1 스토리지 디렉터리 안에 새 Table1를 만들지 마세요. 테이블을 제거하지 않고 삭제하면 그 데이터는 외부 클라우드 스토리지에 유지돼요.

Snowflake를 Iceberg 카탈로그로 사용하는 테이블(Snowflake 관리 테이블)이 있다면 이 테이블을 Open Catalog의 외부 카탈로그에 동기화할 수 있어요. 이 카탈로그를 Open Catalog에 동기화하면 Open Catalog에서 외부 카탈로그로 나타나요. 테이블 데이터와 메타데이터는 외부 클라우드 스토리지에 저장돼요. Snowflake 쿼리 엔진은 이 테이블에서 읽거나 쓸 수 있어요. 하지만 다른 쿼리 엔진은 이 테이블에서 읽기만 할 수 있어요.

카탈로그에 정의된 접근 권한이 올바르게 적용되도록 하려면 다음 조건이 충족돼야 해요:

디렉터리에는 단일 테이블에 속한 데이터 파일만 포함된다.
디렉터리 계층 구조가 카탈로그의 네임스페이스 계층 구조와 일치한다.

예를 들어 카탈로그에 다음 항목이 포함된다면:

최상위 네임스페이스 namespace1
중첩 네임스페이스 namespace1a
중첩 네임스페이스 namespace1a 아래에 그룹화된 customers 테이블
중첩 네임스페이스 namespace1a 아래에 그룹화된 orders 테이블

카탈로그의 디렉터리 계층 구조는 다음과 같아야 해요:

/namespace1/namespace1a/customers/<customers 테이블의 파일 *만*>
/namespace1/namespace1a/orders/<orders 테이블의 파일 *만*>

이 조건은 내부 및 외부 카탈로그 모두에 적용되며 Snowflake 관리 Apache Iceberg™ 테이블을 포함하는 외부 카탈로그에도 적용돼요. 내부 카탈로그에서 테이블을 만들 때 Open Catalog는 기존 테이블의 디렉터리나 하위 디렉터리 안에 테이블을 만들지 못하게 해요. 외부 카탈로그에서 Snowflake 관리 Iceberg 테이블을 만들 때 Open Catalog는 겹치는 디렉터리 위치를 금지하지 않아요. 따라서 이 테이블들을 만들 때 BASE_LOCATION 매개변수를 사용해 각 테이블에 고유한 부모 디렉터리를 지정하세요. 자세한 내용은 CREATE ICEBERG TABLE (Snowflake를 Iceberg 카탈로그로)을 참조하세요.

내부 및 외부 카탈로그에 대한 자세한 내용은 카탈로그 유형을 참조하세요.

서비스 주체

서비스 주체(service principal)는 Open Catalog에서 만드는 엔터티예요. 각 서비스 주체는 Open Catalog에 연결하는 데 사용하는 자격 증명을 캡슐화해요.

쿼리 엔진은 서비스 주체를 사용해 카탈로그에 연결해요. Open Catalog는 각 서비스 주체에 대해 Client ID와 Client Secret 쌍을 생성해요.

다음 표는 Open Catalog에서 만들 수 있는 서비스 주체 예시를 보여줘요:

서비스 연결 이름	목적
Flink ingestion	Apache Flink®가 스트리밍 데이터를 Apache Iceberg™ 테이블에 수집하기 위함.
Spark ETL pipeline	Apache Spark™가 Iceberg 테이블에서 ETL 파이프라인 작업을 실행하기 위함.
Snowflake data pipelines	Snowflake가 Apache Iceberg™ 테이블의 데이터를 변환하는 데이터 파이프라인을 실행하기 위함.
Trino BI dashboard	Trino가 대시보드를 구동하는 BI 쿼리를 실행하기 위함.
Snowflake AI team	Snowflake가 Apache Iceberg™ 테이블의 데이터에 AI 작업을 실행하기 위함.

서비스 연결

서비스 연결(service connection)은 Open Catalog에서 읽고 쓸 수 있는 REST 호환 엔진(예: Apache Spark™, Apache Flink®, Trino)을 나타내요. 새 서비스 연결을 만들 때 Open Catalog 관리자는 새 서비스 연결과 함께 만들어지는 서비스 주체에 새 보안 주체 역할 또는 기존 보안 주체 역할을 부여해요. 보안 주체 역할은 Open Catalog의 리소스로, Open Catalog 서비스 주체를 논리적으로 그룹화하고 보안 가능 객체에 대한 권한을 부여하는 데 사용할 수 있어요. 자세한 내용은 보안 주체 역할을 참조하세요. Open Catalog는 RBAC(역할 기반 접근 제어) 모델을 사용해 서비스 주체에 리소스 접근 권한을 부여해요. 자세한 내용은 접근 제어를 참조하세요. 이 모델의 다이어그램은 RBAC 모델을 참조하세요.

Open Catalog 관리자가 새 서비스 연결의 서비스 주체에 새 보안 주체 역할을 부여하면, 서비스 주체에는 아직 어떤 권한도 부여되지 않아요. 새 서비스 연결이 연결할 카탈로그를 보호할 때 Open Catalog 관리자는 카탈로그 역할에 권한을 부여한 다음 이 카탈로그 역할을 새 보안 주체 역할에 부여해요. 그 결과 새 서비스 연결의 서비스 주체가 이러한 권한을 가지게 돼요. 카탈로그 역할에 대한 자세한 내용은 카탈로그 역할을 참조하세요.

Open Catalog 관리자가 새 서비스 연결의 서비스 주체에 기존 보안 주체 역할을 부여하면, 서비스 주체는 기존 보안 주체 역할에 부여된 카탈로그 역할에 부여된 권한을 내려받아요. 필요하면 Open Catalog 관리자는 기존 보안 주체 역할에 추가 카탈로그 역할을 부여하거나 카탈로그 역할을 제거해 서비스 주체에 내려진 권한을 조정할 수 있어요. Open Catalog에서 RBAC가 작동하는 방식의 예는 RBAC 예제를 참조하세요.

스토리지 구성

스토리지 구성은 외부 클라우드 스토리지에 대해 생성된 IAM(Identity and Access Management) 엔터티를 저장하며 카탈로그를 만들 때 생성돼요. 스토리지 구성은 Open Catalog를 클라우드 스토리지에 연결하는 값을 설정하는 데 사용돼요. 카탈로그 생성 과정에서 IAM 엔터티가 생성되어 클라우드 스토리지 제공자와 Open Catalog 사이에 신뢰 관계를 만드는 데 사용돼요.

카탈로그를 만들 때 외부 클라우드 스토리지에 대한 다음 정보를 입력해요:

클라우드 스토리지 제공자	정보
Amazon S3	Amazon S3 버킷의 기본 기준 위치, Amazon S3 버킷의 위치, S3 역할 ARN, 외부 ID(선택)
Cloud Storage from Google	Cloud Storage from Google 버킷의 기본 기준 위치, Cloud Storage from Google 버킷의 위치
Azure	Microsoft Azure 컨테이너의 기본 기준 위치, Microsoft Azure 컨테이너의 위치, Azure 테넌트 ID

예제 워크플로

다음 예제 워크플로에서 Bob은 Table1이라는 Apache Iceberg™ 테이블을 만들고 Alice는 Table1에서 데이터를 읽어요.

Bob은 Apache Spark™를 사용해 Catalog1 카탈로그의 Namespace1 네임스페이스 아래에 Table1 테이블을 만들고 Table1에 값을 삽입해요. Bob은 이러한 작업을 수행할 권한이 있는 서비스 주체가 있는 서비스 연결을 사용하고 있으므로 Table1을 만들고 데이터를 삽입할 수 있어요.
Alice는 Snowflake를 사용해 Table1에서 데이터를 읽어요. Alice는 이 작업을 수행할 권한이 있는 카탈로그 통합이 있는 서비스 주체가 있는 서비스 연결을 사용하고 있으므로 Table1에서 데이터를 읽을 수 있어요. Alice는 Snowflake에서 외부 관리 테이블을 만들어 Table1에서 데이터를 읽어요.

보안 및 접근 제어

이 섹션은 보안과 접근 제어를 설명해요.

자격 증명 공급(Credential vending)

자격 증명 공급은 다음 항목에 대한 접근 관리를 중앙화해 Open Catalog의 접근 제어를 간소화해요:

Open Catalog 내의 메타데이터
Apache Iceberg 테이블의 스토리지 위치

카탈로그에 대해 자격 증명 공급이 활성화되면 Open Catalog는 쿼리를 실행하는 쿼리 엔진에 임시 스토리지 자격 증명을 제공해요. 이 자격 증명은 쿼리 엔진이 Iceberg 테이블의 기본 디렉터리 위치에 접근할 수 있게 해요. 자격 증명 공급을 활성화하면 Open Catalog 밖에서 스토리지 접근을 별도로 관리할 필요가 없어요.

외부 카탈로그에 대한 자격 증명 공급

각 외부 카탈로그에 대해 자격 증명 공급을 활성화할 수 있는 옵션이 있어요. 카탈로그에 대해 자격 증명 공급을 활성화하지 않으면 Open Catalog 밖에서 쿼리 엔진에 자체 스토리지 자격 증명을 별도로 제공해야 해요.

외부 카탈로그에 대한 자격 증명 공급을 활성화하기 전에 Open Catalog가 카탈로그의 Iceberg 테이블이 겹치는 스토리지 디렉터리 위치를 갖는 것을 막지 않는다는 점을 인지하세요. 테이블이 겹치는 스토리지 디렉터리 위치를 가지면 사용자가 접근 권한이 없어야 할 테이블에 접근할 수 있게 될 수 있어요. 외부 카탈로그에 대한 자격 증명 공급을 활성화하기 전에 카탈로그의 테이블이 겹치는 스토리지 디렉터리 위치를 갖지 않도록 확인하세요.

예를 들어 다음 디렉터리 위치를 고려하세요:

Table1의 스토리지 디렉터리 위치는 /MyCatalog/Schema1/Table1.
Table2의 스토리지 디렉터리 위치는 /MyCatalog/Schema1/Table1/Table2.

Table1에 대한 공급 자격 증명을 가진 사용자는 Table2의 스토리지 위치에도 접근할 수 있어요.

겹치는 스토리지 디렉터리 위치를 해결하는 방법의 예는 다음과 같아요:

Table1의 스토리지 디렉터리 위치는 /MyCatalog/Schema1/Table1.
Table2의 스토리지 디렉터리 위치는 /MyCatalog/Schema1/Table2.

외부 카탈로그에 대한 자격 증명 공급을 활성화하려면 외부 카탈로그에 대한 자격 증명 공급 활성화를 참조하세요.

내부 카탈로그에 대한 자격 증명 공급

내부 카탈로그에 대한 자격 증명 공급은 카탈로그를 만들 때 기본적으로 활성화돼요. 활성화할 필요가 없어요. 내부 카탈로그에서 테이블을 만들 때 Open Catalog는 기존 테이블의 디렉터리나 하위 디렉터리 안에 테이블을 만들지 못하게 해요.

IAM(Identity and Access Management)

Open Catalog는 IAM 엔터티를 사용해 테이블 데이터, Iceberg 메타데이터, 테이블 스키마·파티션·기타 메타데이터를 저장하는 매니페스트 파일에 접근하기 위해 스토리지에 안전하게 연결해요. Open Catalog는 스토리지 위치에 대한 IAM 엔터티를 유지해요.

접근 제어

Open Catalog는 서비스에 등록된 모든 테이블에 걸쳐 구성한 접근 제어를 적용하고 쿼리 엔진의 모든 쿼리에 대한 보안을 일관된 방식으로 관리해요.

Open Catalog는 RBAC(역할 기반 접근 제어) 모델을 사용해 Open Catalog 서비스 주체가 카탈로그, 네임스페이스, 테이블에 접근하도록 중앙에서 구성할 수 있게 해요.

Open Catalog RBAC는 권한을 위임하기 위해 두 가지 다른 역할 유형을 사용해요:

보안 주체 역할(Principal roles): Open Catalog 서비스 주체에 부여되며 다른 접근 제어 시스템에서 서비스 주체에 부여하는 역할과 유사해요.
카탈로그 역할(Catalog roles): Open Catalog 리소스에 대한 특정 권한으로 구성되고 보안 주체 역할에 부여돼요.

자세한 내용은 접근 제어를 참조하세요.

청구

Open Catalog는 현재 일반 공급과 함께 무료로 사용할 수 있어요. 청구는 2026년 상반기에 시작될 예정이에요.

청구가 시작되면 Snowflake는 Open Catalog 서비스가 지원하는 REST API에 대한 요청에 대해 계정에 청구해요. 자세한 내용은 Snowflake 서비스 소비 테이블의 Serverless Feature Table을 참조하세요.

Snowflake는 Snowflake 밖에 저장된 Iceberg 테이블에 대해 계정에 청구하지 않아요. 클라우드 스토리지 제공자가 데이터 스토리지 사용에 대해 직접 청구해요.

법적 고지

Apache®, Apache Iceberg™, Apache Spark™, Apache Flink®, Flink®는 미국 및/또는 기타 국가에서 Apache Software Foundation의 등록 상표 또는 상표예요.

Snowflake Open Catalog 개요