Snowflakeオープンカタログの概要

Snowflakeオープンカタログは、Apache Iceberg™テーブルのためのカタログ実装であり、オープンソースのApache Iceberg™ REST プロトコルに基づいて構築されています。Snowflake Open Catalogは、Apache Polaris™ (incubating) の管理サービスです。

オープンカタログにより、異なる REST 互換クエリエンジン間でIcebergテーブルへの一元化された安全な読み取り/書き込みアクセスを提供できます。

オープンカタログは現在、Snowflakeで管理されるインフラストラクチャでホストされたサービスとして提供されています。

オープンカタログの概念図

サインアップ

オープンカタログには、以下のサインアップオプションがあります。

  • 既存のSnowflakeをご利用のお客様: 組織管理者として既存のSnowflakeアカウントにサインインし、Snowflake組織に新しいオープンカタログアカウントを作成します。Snowflakeで ORGADMIN ロールを持つユーザーは、Snowflakeからオープンカタログアカウントを管理できます。手順については、Snowflakeオープンカタログアカウントの作成をご参照ください。

  • 既存のSnowflakeのお客様でない場合: Snowflakeのトライアルアカウントにサインアップすると、Snowflakeオープンカタログを30日間無料でお試しいただけます。手順については、Snowflakeオープンカタログを無料で試すをご参照ください。

主な概念

このセクションでは、Snowflakeでホストされているオープンカタログの使用に関連する主要な概念を紹介します。

以下の図では、Catalog1のネストされた名前空間があるオープンカタログ構造のサンプルを示しています。Catalog2またはCatalog3のテーブルまたは名前空間はまだ作成されていません。

オープンカタログの構造例を示す図

カタログ

オープンカタログでは、Icebergテーブルを整理するために1つまたは複数のカタログリソースを作成できます。

S3、Azure、Google Cloud Storageのストレージ構成で値を設定してカタログを構成します。Icebergカタログは、クエリエンジンがテーブルを管理し、整理できるようにします。カタログはApache Iceberg™テーブル仕様の最初の構造上のレイヤーを形成し、以下のタスクをサポートする必要があります。

  • 1つ以上のIcebergテーブルの現在のメタデータポインターを格納する。メタデータポインターは、テーブル名とそのテーブルの現在のメタデータファイルの場所をマッピングします。

  • アトミック操作を実行することで、テーブルの現在のメタデータポインターをテーブルの新しいバージョンのメタデータポインターに更新できます。

Icebergカタログについての詳細は、Apache Iceberg™ドキュメントをご参照ください。

カタログの種類

カタログは以下の2つの種類のいずれかになります。

  • 内部: カタログはオープンカタログによって管理されます。このカタログからのテーブルは、オープンカタログで読み取りおよび書き込みできます。

  • 外部: カタログは、他のIcebergカタログプロバイダー(例えば、Snowflake、Glue、Dremio Arctic)によって外部管理されています。このカタログからのテーブルはオープンカタログに同期されます。これらのテーブルは、オープンカタログでは読み取り専用です。現在のリリースでは、Snowflakeの外部カタログのみが提供されています。

カタログは、S3、Azureストレージ、または GCS にポイントできるストレージ構成で設定されます。

新しいカタログを作成するには、カタログの作成をご参照ください。

名前空間

カタログ内のIcebergテーブルを論理的にグループ化するために 名前空間 を作成します。カタログには複数の名前空間を指定できます。ネストされた名前空間を作成することもできます。Icebergテーブルは名前空間に属しています。

Apache Iceberg™テーブルとカタログ

内部カタログでは、Icebergテーブルはオープンカタログに登録されていますが、クエリエンジンを介して読み取りおよび書き込みされます。テーブルデータとメタデータは、外部クラウドストレージに保管されます。このテーブルでは、Icebergカタログとしてオープンカタログを使用しています。

重要

Snowflake Open Catalogでテーブルをパージせずに削除した場合、削除したテーブルと同じ名前と場所で新しいテーブルを作成しないでください。そうすると、アクセス許可がないはずのユーザーが元のテーブルのデータにアクセスしてしまう可能性があります。たとえば、 /MyCatalog/Schema1/Table1 のストレージ・ディレクトリにある Table1 をパージせずに削除した場合、同じ Table1 ストレージ・ディレクトリ内に Table1 を新規作成しないでください。パージせずにテーブルを削除した場合、そのデータは外部クラウドストレージに保持されます。

IcebergカタログとしてSnowflakeを使用しているテーブル(Snowflakeで管理されるテーブル)がある場合、オープンカタログでこれらのテーブルを外部カタログに同期できます。このカタログをオープンカタログに同期すると、オープンカタログに外部カタログとして表示されます。テーブルデータとメタデータは、外部クラウドストレージに保管されます。Snowflakeクエリエンジンは、これらのテーブルから読み取り、またはこれらのテーブルに書き込むことができます。しかし、他のクエリエンジンができるのは、これらのテーブルからの読み取りのみです。

重要

カタログに定義されたアクセス権限が正しく実施されるようにするには、以下の条件を満たす必要があります。

  • ディレクトリに1つのテーブルに属するデータファイルのみが格納されている。

  • ディレクトリ階層はカタログの名前空間階層と一致する。

例えば、カタログに以下のような項目がある場合:

  • トップレベル名前空間の namespace1

  • ネストされた名前空間 namespace1a

  • ネストされた名前空間 namespace1a の下にグループ化された customers テーブル

  • ネストされた名前空間 namespace1a の下にグループ化された orders テーブル

カタログのディレクトリ階層は次のようにする必要があります。

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

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

これらの条件は、Snowflakeが管理するApache Iceberg™ tablesを含む外部カタログを含む、内部カタログと外部カタログの両方に適用されます。内部カタログにテーブルを作成する場合、Open Catalog では、既存のテーブルのディレクトリまたはサブディレクトリ内にテーブルを作成することを禁止しています。外部カタログに Snowflake 管理の Iceberg テーブルを作成する場合、Open Catalog はディレクトリの重複を禁止しません。したがって、これらのテーブルを作成する際には、 BASE_LOCATION パラメーターを使用して、各テーブルに一意の親ディレクトリを指定します。詳しくは CREATE ICEBERG TABLE (Snowflake as the Iceberg catalog) を参照してください。

内部カタログと外部カタログの詳細情報については、カタログタイプを参照してください。

サービスプリンシパル

サービスプリンシパルは、オープンカタログで作成するエンティティです。各サービスプリンシパルは、オープンカタログへの接続に使用する認証情報をカプセル化します。

クエリエンジンはサービスプリンシパルを使用してカタログに接続します。

オープンカタログは、各サービスプリンシパルのクライアント ID とクライアントシークレットのペアを生成します。

以下の表は、オープンカタログで作成する可能性があるサービスプリンシパルの例を示しています。

サービス接続名

目的

Flinkインジェスチョン

Apache Flink®がストリーミングデータをApache Iceberg™テーブルにインジェストする。

Spark ETL パイプライン

Apache Spark™がIcebergテーブルに対して ETL パイプラインジョブを実行する。

Snowflakeデータパイプライン

SnowflakeがApache Iceberg™テーブルのデータを変換するためのデータパイプラインを実行する。

Trino BI ダッシュボード

Trinoがダッシュボードを強化するための BI クエリを実行する。

Snowflake AI チーム

SnowflakeがApache Iceberg™テーブルのデータに対して AI ジョブを実行する。

サービス接続

サービス接続は、オープンカタログからの読み取りとオープンカタログへの書き込みが可能な REST 互換エンジン(Apache Spark™、Apache Flink®、またはTrinoなど)を表します。新しいサービス接続を作成する場合、オープンカタログ管理者は新しいサービス接続で作成されるサービスプリンシパルに新規または既存のプリンシパルロールを付与します。プリンシパルロールとは、オープンカタログのリソースで、オープンカタログのサービスプリンシパルを論理的にグループ化し、セキュリティ保護可能なオブジェクトに権限を付与するために使用できます。詳細については、プリンシパルロールをご参照ください。オープンカタログでは、ロールベースのアクセス制御(RBAC)モデルを使用して、サービスプリンシパルにリソースへのアクセス権限を付与します。詳細については、アクセス制御をご参照ください。このモデルの図は、RBAC モデルをご参照ください。

オープンカタログ管理者が新しいサービス接続のサービスプリンシパルに新しいプリンシパルロールを付与した場合、サービスプリンシパルにはまだ権限が付与されていません。新しいサービス接続が接続するカタログを確保する場合、オープンカタログ管理者はカタログロールに権限を付与し、これらのカタログロールを新しいプリンシパルロールに付与します。その結果、新しいサービス接続のサービスプリンシパルにはこれらの権限があります。カタログロールの詳細については、カタログロールをご参照ください。

オープンカタログ管理者が新しいサービス接続のサービスプリンシパルに既存のプリンシパルロールを付与する場合、サービスプリンシパルには既存のプリンシパルロールに付与されたカタログロールに付与されている権限が与えられます。必要に応じて、オープンカタログ管理者は、サービスプリンシパルに付与される権限を調整するために、既存のプリンシパルロールに追加のカタログロールを付与したり、カタログロールを削除できます。オープンカタログでの RBAC の仕組みの例については、RBAC の例をご参照ください。

ストレージ構成

ストレージ構成は、外部クラウドストレージ用に生成されたIDおよびアクセス管理(IAM)エンティティを格納し、カタログの作成時に作成されます。ストレージ構成は、オープンカタログをクラウドストレージに接続するための値を設定するために使用されます。カタログの作成プロセス中に IAM エンティティが生成され、クラウドストレージプロバイダーとオープンカタログの信頼関係を作成するために使用されます。

カタログを作成する際、外部クラウドストレージに関する以下の情報を提供します。

クラウドストレージプロバイダー

情報

Amazon S3

<ul><li>Amazon S3バケットのデフォルトのベースロケーション</li><li>Amazon S3バケットのロケーション</li><li>S3ロール ARN</li><li>外部 ID(オプション)</li></ul>

Google Cloud Storage(GCS)

<ul><li>GCS バケットのデフォルトのベースロケーション</li><li>GCS バケットのロケーション</li></ul>

Azure

<ul><li>Microsoft Azureコンテナのデフォルトのベースロケーション</li><li>Microsoft Azureコンテナのロケーション</li><li>Azureテナント ID</li></ul>

ワークフロー例

以下のワークフロー例では、BobがTable1というApache Iceberg™テーブルを作成し、AliceがTable1からデータを読み取ります。

  1. BobはApache Spark™を使用して、Catalog1カタログのNamespace1名前空間の下にTable1テーブルを作成し、Table1に値を挿入します。

    BobがTable1を作成し、そこにデータを挿入できるのは、これらのアクションを実行する権限を持つサービスプリンシパルとのサービス接続を使用しているからです。

  2. AliceはSnowflakeを使用してTable1からデータを読み取ります。

    Aliceは、このアクションを実行する権限を持つカタログ統合のサービスプリンシパルとのサービス接続を使用しているため、Table1からデータを読み取ることができます。AliceはTable1からデータを読み取るためにSnowflakeでアンマネージドテーブルを作成します。

オープンカタログのワークフロー例を示す図

セキュリティとアクセス制御

このセクションでは、セキュリティとアクセス制御について説明します。

認証情報のベンディング

認証情報ベンディングは、以下の項目のアクセス管理を一元化することで、オープンカタログのアクセス制御を簡素化します。

  • 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 では、既存のテーブルのディレクトリまたはサブディレクトリ内にテーブルを作成することを禁止しています。

IDおよびアクセス管理(IAM)

SnowflakeはIDおよびアクセス管理(IAM)エンティティを使用して、テーブルデータ、Icebergメタデータ、およびテーブルスキーマ、パーティション、その他のメタデータを格納するマニフェストファイルにアクセスするために、ストレージに安全に接続します。オープンカタログは、ストレージ場所の IAM エンティティを保持します。

アクセス制御

オープンカタログは、サービスに登録されたすべてのテーブルにわたって構成したアクセス制御を実施し、クエリエンジンからのすべてのクエリのセキュリティを一貫した方法で管理します。

オープンカタログはロールベースのアクセス制御(RBAC)モデルを使用しており、オープンカタログサービスプリンシパルのカタログ、名前空間、およびテーブルへのアクセスを一元的に構成できます。

オープンカタログ RBAC は、権限を委任するために2つの異なるロール型を使用します。

  • プリンシパルロール: オープンカタログのサービスプリンシパルに付与され、サービスプリンシパルに付与する他のアクセス制御システムのロールに似ています。

  • カタログロール: オープンカタログリソースの特定の権限で構成され、プリンシパルロールに付与されます。

詳細については、アクセス制御をご参照ください。

請求

オープンカタログは一般公開後6か月間無料です。請求開始は2025年半ばです。

請求が開始されると、Snowflakeは、オープンカタログサービスでサポートされている REST APIs へのリクエストの料金をお客様のアカウントに請求します。詳細については、Snowflakeサービス消費テーブルのサーバーレス機能テーブルをご参照ください。

Snowflakeは、Snowflake外に保存されたIcebergテーブルの請求はアカウントに行いません。クラウドストレージプロバイダーがデータストレージの使用料を直接請求します。