Snowflake Open Catalog 릴리스 노트

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

이 주제는 Snowflake Open Catalog의 가장 최근 릴리스에 대한 개요를 제공해요.

출처: Release notes

본문

2025년 9월 29일

External OAuth 및 키 페어 인증 지원

이제 External OAuth 또는 키 페어 인증으로 Snowflake Open Catalog에 연결할 수 있어요. 자세한 내용은 다음을 참조하세요:

2025년 5월 27일

프라이빗 연결로 Open Catalog UI 접근

이제 공개 인터넷 대신 프라이빗 연결을 통해 Open Catalog UI에 접근할 수 있어요. 자세한 내용은 다음을 참조하세요:

2025년 5월 5일

프라이빗 연결 지원

Snowflake는 Snowflake Open Catalog와 함께 프라이빗 연결 사용을 지원해요. 프라이빗 연결을 사용해 Snowflake Open Catalog에 대한 연결을 공개 인터넷 대신 프라이빗 엔드포인트나 프라이빗 IP 주소를 통해 라우팅하세요.

자세한 내용은 다음을 참조하세요:

2025년 3월 31일

SAML 기반 SSO 지원

이 릴리스에서 Snowflake Open Catalog와 함께 SAML 기반 단일 로그온(SSO) 사용을 지원하게 되었음을 발표하게 되어 기쁘게 생각해요.

Open Catalog용 SSO를 사용하면 Open Catalog를 서드파티 ID 제공자와 통합할 수 있어요. 이제 사용자는 ID 제공자(IdP)가 관리하는 기존 자격 증명을 사용해 Open Catalog 웹 인터페이스에 로그인할 수 있어요. Open Catalog에서 별도의 사용자 이름과 비밀번호를 관리할 필요가 없어요. 자세히 알아보려면 Snowflake Open Catalog의 SSO 개요를 참조하세요.

2024년 11월 7일

외부 카탈로그용 자격 증명 공급이 이제 기본적으로 비활성화됨

이 릴리스에서 외부 카탈로그용 자격 증명 공급(credential vending)이 이제 기본적으로 비활성화돼요. 외부 카탈로그는 Snowflake Open Catalog가 관리하지 않으므로 Open Catalog는 특정 디렉터리 구조 계층을 적용할 수 없어요. 디렉터리 구조 계층에 대한 자세한 내용은 카탈로그 콘텐츠 구성을 참조하세요. 따라서 카탈로그를 만들 때 외부 카탈로그용 자격 증명 공급이 기본적으로 비활성화돼요. 또한 기존 외부 카탈로그에 대해서도 이제 비활성화돼요. 하지만 외부 카탈로그용 자격 증명 공급을 활성화할 수 있는 옵션은 있어요. 자세한 내용은 외부 카탈로그에 대한 자격 증명 공급 활성화를 참조하세요.

2024년 10월 18일

Snowflake Open Catalog: 일반 공급(GA)

이 릴리스에서 이전에 Polaris Catalog라고 불리고 프리뷰 기능으로 제공됐던 Snowflake Open Catalog의 일반 공급을 발표하게 되어 기쁘게 생각해요. 일반 공급과 함께 다음 업데이트를 적용했어요:

서비스 관리자는 이제 Open Catalog 계정에 추가 사용자를 만들 수 있어요. 이 사용자들은 Open Catalog 웹 인터페이스를 통해 계정을 관리할 수 있어요. 자세한 내용은 사용자 관리를 참조하세요.
카탈로그 관리자는 이제 카탈로그 내 개별 네임스페이스나 테이블을 보호할 수 있어요. 카탈로그 수준에서 카탈로그를 보호하는 것도 계속할 수 있어요. 자세한 내용은 카탈로그 보호를 참조하세요.
Snowflake Open Catalog에서 테이블의 스키마를 볼 때 이제 열의 중첩 스키마를 볼 수 있어요. 자세한 내용은 테이블의 스키마 보기를 참조하세요.
Open Catalog에 대한 청구 지원을 추가했지만 2025년 4월 30일까지는 Open Catalog를 무료로 사용할 수 있어요. 자세한 내용은 청구를 참조하세요.

2024년 8월 8일

이 릴리스에서 Open Catalog의 다음 새로운 개선 사항을 발표하게 되어 기쁘게 생각해요.

Snowflake가 이제 중첩 네임스페이스가 있는 테이블에서 쿼리를 지원

이전에는 Snowflake가 중첩 네임스페이스 아래에 있는 Open Catalog에 등록된 테이블을 읽을 수 없다는 제한을 나열했어요. Snowflake는 이제 중첩 네임스페이스 아래에 있는 테이블 쿼리를 지원해요. 예를 들어 중첩 네임스페이스 namespace1.namespace1a.namespace1ab을 만들면 Snowflake는 네임스페이스 namespace1ab 아래에 그룹화된 테이블을 읽을 수 있어요. 자세한 내용은 네임스페이스 만들기를 참조하세요.

2024년 7월 30일

이 릴리스에서 다음 기능과 함께 Snowflake에 호스팅된 Open Catalog의 초기 공개 프리뷰 릴리스를 발표하게 되어 기쁘게 생각해요.

Apache Iceberg™ REST API

Open Catalog는 Apache Iceberg REST 카탈로그 API를 제공하며, 이를 통해 Apache Iceberg™ REST 카탈로그 사양을 지원하는 모든 쿼리 엔진을 지원할 수 있어요.

인증

사용자는 Client ID와 Client Secret 서비스 자격 증명을 제공하는 서비스 연결을 만들 수 있어요. 이 자격 증명은 OAuth 2.0을 사용한 인증에 사용돼요.

Open Catalog 사용자 인터페이스

Open Catalog는 카탈로그 관리를 간소화하는 웹 애플리케이션과 함께 제공돼요. UI 내에서 사용자는 카탈로그, 서비스 주체, 서비스 주체의 권한을 관리할 수 있어요.

역할 기반 보안 모델

역할 기반 접근 제어(RBAC) 보안 모델이 포함되어 있어, 고객은 각 사용자나 사용자 그룹이 카탈로그에서 허용되는 접근 수준을 관리할 수 있어요. 자세한 내용은 접근 제어를 참조하세요.

자격 증명 공급

데이터가 위치한 스토리지 객체에 대한 접근은 Open Catalog가 관리해요. 사용자가 읽기든 쓰기든 테이블에 대한 접근을 요청하면 임시 범위 지정 스토리지 자격 증명이 생성되어 호출 엔진에 반환되며, 이는 스토리지 내에서 데이터가 위치한 폴더에 적절한 접근 권한을 제공해요.

Open Catalog용 Snowflake 웨어하우스 카탈로그 통합

Snowflake 내에서 Open Catalog용 새 카탈로그 통합을 사용할 수 있어요. 이 카탈로그 통합을 통해 사용자는 쿼리를 위해 Open Catalog에 있는 테이블을 가리키는 외부 관리 Apache Iceberg™ 테이블을 만들 수 있어요.

고려 사항 및 제한 사항

다음 고려 사항과 제한 사항은 Open Catalog에 적용되며 변경될 수 있어요:

가입

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

카탈로그

Open Catalog는 현재 다음 중 하나를 사용하는 Apache Iceberg™ 테이블을 지원해요: Iceberg 카탈로그로서의 Open Catalog, 또는 Iceberg 카탈로그로서의 Snowflake. Snowflake 외의 외부 Iceberg 카탈로그는 현재 지원되지 않아요. 다른 외부 카탈로그에서 Iceberg 테이블을 추가하려면 마이그레이션해야 해요.
Glue나 Tabular 같은 공급업체의 기존 Iceberg 테이블을 Open Catalog의 내부 카탈로그로 가져올 수 없지만, 외부 카탈로그에는 추가할 수 있어요.
Snowflake는 Open Catalog가 관리하는 테이블을 쿼리할 수 있지만 쓸 수는 없어요.
외부 카탈로그에서 사용할 수 있는 Snowflake Iceberg 테이블은 Open Catalog에서 읽기 전용이에요.
내부 카탈로그의 경우 네임스페이스 간에 테이블 이름을 바꿀 수 없어요. 예를 들어 테이블을 /mytables/ns1/table1에서 /mytables/ns2/table1로 이름을 바꿀 수 없어요.
내부 또는 외부 카탈로그를 만들 때 다른 카탈로그의 디렉터리 계층 구조와 겹치는 기본 기준 위치나 허용 위치를 지정할 수 없어요. 예를 들어 catalog1의 기본 기준 위치가 s3://mytables/db1/schema1/table1이라면 새 카탈로그의 기본 기준 위치를 s3://mytables/db1/로 지정할 수 없어요.

접근 제어

테이블의 범위 지정 접근 정책은 <table_base>/metadata/ 및 <table_base>/data/ 디렉터리로 제한돼요.

Iceberg

registerTable API를 호출할 때 부모 네임스페이스 디렉터리 밖의 위치에 테이블을 등록할 수 없어요. 예를 들어 카탈로그의 폴더 계층이 s3://teambucket/iceberg/namespace1/namespace1a/라면 기본 위치가 s3://teambucket/iceberg/namespace1인 mytbl3을 만들 수 없어요. 예를 들어 기본 위치가 s3://teambucket/iceberg/namespace1/mytbl3이면 만들 수 있어요.
dropTable API를 호출하고 purgeRequested 매개변수를 true로 설정해 테이블의 데이터와 메타데이터를 제거하도록 요청하면, Open Catalog는 다음 항목을 삭제하기 위해 최선을 다해요:
- 테이블과 연결된 모든 데이터 및 메타데이터 파일
- 테이블의 스토리지 디렉터리

하지만 이 항목 중 일부는 삭제되지 않을 수 있어요. 그런 경우 외부 클라우드 스토리지로 이동해 고아 파일이나 스토리지 디렉터리를 직접 식별해 삭제하세요.

Snowflake Open Catalog 릴리스 노트