Snowflake Open Catalog 개요¶

카탈로그¶

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

S3, Azure 또는 Google Cloud Storage의 저장소 구성에서 값을 설정하여 카탈로그를 구성합니다. Iceberg 카탈로그를 통해 쿼리 엔진이 테이블을 관리하고 구성할 수 있습니다. 카탈로그는 Apache Iceberg™ 테이블 사양에서 첫 번째 아키텍처 계층을 형성하며 다음 작업을 지원해야 합니다.

• 하나 이상의 Iceberg 테이블에 대한 현재 메타데이터 포인터 저장. 메타데이터 포인터는 테이블 이름을 해당 테이블의 현재 메타데이터 파일 위치에 매핑합니다.

• 테이블의 현재 메타데이터 포인터를 테이블의 새 버전에 대한 메타데이터 포인터로 업데이트할 수 있도록 원자성 작업 수행.

Iceberg 카탈로그에 대해 자세히 알아보려면 Apache Iceberg™ 설명서 섹션을 참조하십시오.

네임스페이스¶

네임스페이스 를 만들어 카탈로그 내에서 Iceberg 테이블을 논리적으로 그룹화합니다. 카탈로그에는 여러 개의 네임스페이스가 있을 수 있습니다. 중첩된 네임스페이스를 만들 수도 있습니다. Iceberg 테이블은 네임스페이스에 속합니다.

Apache Iceberg™ 테이블 및 카탈로그¶

내부 카탈로그에서는 Iceberg 테이블이 Open Catalog에 등록되지만 쿼리 엔진을 통해 읽고 씁니다. 테이블 데이터 및 메타데이터는 외부 클라우드 저장소에 저장됩니다. 테이블에서는 Open Catalog를 Iceberg 카탈로그로 사용합니다.

Snowflake를 Iceberg 카탈로그로 사용하는 테이블(Snowflake 관리 테이블)이 있는 경우, 이러한 테이블을 Open Catalog의 외부 카탈로그와 동기화할 수 있습니다. 이 카탈로그를 Open Catalog에 동기화하면 Open Catalog에 외부 카탈로그로 표시됩니다. 테이블 데이터 및 메타데이터는 외부 클라우드 저장소에 저장됩니다. Snowflake 쿼리 엔진은 이러한 테이블에서 데이터를 읽거나 테이블에 데이터를 쓸 수 있습니다. 하지만 다른 쿼리 엔진은 이러한 테이블에서만 데이터를 읽을 수 있습니다.

중요

카탈로그에 대해 정의된 액세스 권한을 올바르게 적용하려면 다음 조건을 충족해야 합니다.

• 디렉터리에는 단일 테이블에 속한 데이터 파일만 포함됩니다.

• 디렉터리 계층 구조는 카탈로그의 네임스페이스 계층 구조와 일치합니다.

카탈로그에 다음 항목이 포함된 경우를 예로 들겠습니다.

• 최상위 네임스페이스 namespace1

• 중첩된 네임스페이스 namespace1a

• 중첩된 네임스페이스 namespace1a 아래에 그룹화된 고객 테이블

• 중첩된 네임스페이스 namespace1a 아래에 그룹화된 주문 테이블

카탈로그의 디렉터리 계층 구조는 다음 구조를 따라야 합니다.

• /namespace1/namespace1a/customers/<files for the customers table only>

• /namespace1/namespace1a/orders/<files for the orders table only>

서비스 주체¶

서비스 주체는 Open Catalog에서 생성하는 엔터티입니다. 각 서비스 주체는 Open Catalog에 연결하는 데 사용하는 자격 증명을 캡슐화합니다.

쿼리 엔진은 서비스 주체를 사용하여 카탈로그에 연결합니다.

Open Catalog는 각 서비스 주체에 대해 클라이언트 ID와 클라이언트 시크릿 페어를 생성합니다.

다음 표는 Open Catalog에서 만들 수 있는 서비스 주체의 예를 보여줍니다.

서비스 연결¶

서비스 연결은 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 예제 섹션을 참조하십시오.

저장소 구성¶

저장소 구성은 외부 클라우드 저장소에 대해 생성된 ID 및 액세스 관리(IAM) 엔터티를 저장하며 카탈로그를 생성할 때 생성됩니다. 저장소 구성은 Open Catalog를 클라우드 저장소에 연결하기 위한 값을 설정하는 데 사용됩니다. 카탈로그 생성 과정에서 IAM 엔터티가 생성되어 클라우드 저장소 공급자와 Open Catalog 간의 신뢰 관계를 만드는 데 사용됩니다.

카탈로그를 만들 때 외부 클라우드 저장소에 대한 다음 정보를 제공합니다.

자격 증명 제공¶

서비스 연결과의 상호 작용을 보호하기 위해 Open Catalog는 쿼리 실행 중에 임시 저장소 자격 증명을 쿼리 엔진에 제공합니다. 쿼리 엔진은 이러한 자격 증명을 통해 Iceberg 테이블에 대한 외부 클라우드 저장소에 액세스할 필요 없이 쿼리를 실행할 수 있습니다. 이 과정을 자격 증명 제공이라고 합니다.

ID 및 액세스 관리(IAM)¶

Open Catalog는 ID 및 액세스 관리(IAM) 엔터티를 사용하여 테이블 데이터, Iceberg 메타데이터 및 테이블 스키마, 파티션 및 기타 메타데이터를 저장하는 매니페스트 파일에 액세스하기 위해 저장소에 대한 보안 연결을 제공합니다. Open Catalog는 저장소 위치에 대한 IAM 엔터티를 유지합니다.

액세스 제어¶

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

Open Catalog는 Open Catalog 서비스 주체의 카탈로그, 네임스페이스, 테이블에 대한 액세스 권한을 중앙에서 구성할 수 있는 역할 기반 액세스 제어(RBAC) 모델을 사용합니다.

Open Catalog RBAC는 두 가지 서로 다른 역할 유형을 사용하여 권한을 위임합니다.

• 주체 역할: Open Catalog 서비스 주체에게 부여되는 역할로, 서비스 주체에게 부여하는 다른 액세스 제어 시스템의 역할과 유사합니다.

• 카탈로그 역할: Open Catalog 리소스에 대한 특정 권한으로 구성되고 주체 역할에 부여됩니다.

자세한 내용은 액세스 제어 섹션을 참조하십시오.