ALTER ICEBERG TABLE ... REFRESH

外部Icebergカタログを使用する Apache Iceberg™ テーブル のメタデータをリフレッシュします。Icebergテーブルは、テーブルメタデータと最新のテーブル変更を同期します。

このトピックでは、 Iceberg tables と指定することで混乱を避ける場合を除き、Icebergテーブルを単に「テーブル」と呼びます。

こちらもご参照ください。

CREATE ICEBERG TABLEDROP ICEBERG TABLESHOW ICEBERG TABLESDESCRIBE ICEBERG TABLE

構文

ALTER ICEBERG TABLE [ IF EXISTS ] <table_name> REFRESH [ '<metadata_file_relative_path>' ]
Copy

パラメーター

table_name

リフレックスするテーブルの識別子。

識別子にスペースまたは特殊文字が含まれる場合は、文字列全体を二重引用符で囲む必要があります。二重引用符で囲まれた識別子も大文字と小文字が区別されます。

詳細については、 識別子の要件 をご参照ください。

'metadata_file_relative_path'

オブジェクトストレージ内の Iceberg ファイルから作成されたテーブルのメタデータファイルパスを指定します。パスは、テーブルに関連付けられている外部ボリュームの アクティブなストレージの場所 からの相対パスにする必要があります。

次のテーブルは、ストレージの場所の例に基づいて指定する値を示しています。

テーブルの外部ボリュームのアクティブなストレージの場所

s3://mybucket_us_east_1

メタデータファイルへのフルパス

s3://mybucket_us_east_1/metadata/v1.metadata.json

'metadata_file_relative_path' として指定する値

metadata/v1.metadata.json (先頭のスラッシュなし)

注釈

  • テーブルがカタログとして AWS Glueを使用している場合は、メタデータファイルのパスを指定しないでください。

  • メタデータファイルパスの先頭のスラッシュ(/)を省略します。

  • Snowflakeのバージョン7.34以前では、オブジェクトストレージ内のIcebergファイルからテーブルを作成するには BASE_LOCATION (以前のバージョンでの別称は FILE_PATH)というパラメーターが必要でした。パラメーターは、 EXTERNAL_VOLUME の場所からの相対パスを指定しました。

    古い構文を使用して作成したテーブルをリフレッシュするには、 BASE_LOCATION への相対パスを指定します。例えば、メタデータファイルのフルパスが s3://mybucket_us_east_1/my_base_location/metadata/v1.metadata.json の場合、 metadata/v1.metadata.jsonmetadata-file-relative-path として指定します。

アクセス制御の要件

この操作の実行に使用される ロール には、少なくとも次の 権限 が必要です。

権限

オブジェクト

注意

OWNERSHIP

Icebergテーブル

OWNERSHIP is a special privilege on an object that is automatically granted to the role that created the object, but can also be transferred using the GRANT OWNERSHIP command to a different role by the owning role (or any role with the MANAGE GRANTS privilege).

USAGE

外部ボリューム

ベンディングされた認証情報 を使用する場合は必要ありません。

USAGE

カタログ統合

スキーマ内のオブジェクトに対して操作を実行するには、親データベースとスキーマに対する USAGE 権限が必要です。スキーマに対する 任意の権限を付与されたロールは、そのロールがスキーマを解決できることに注意してください。たとえば、スキーマに対するCREATE権限を付与されたロールは、そのスキーマにオブジェクトを作成できますが、そのスキーマに対するUSAGE*も*付与されている必要はありません。

指定された権限のセットを使用してカスタムロールを作成する手順については、 カスタムロールの作成 をご参照ください。

セキュリティ保護可能なオブジェクト に対して SQL アクションを実行するためのロールと権限付与に関する一般的な情報については、 アクセス制御の概要 をご参照ください。

使用上の注意

  • このコマンドを実行できるのは、テーブルの所有者(つまり、テーブルに対する OWNERSHIP 権限を持つロール)以上のみです。

  • トランザクション内(暗黙的または明示的)での ALTER ICEBERG TABLE ... REFRESH コマンドの使用はサポートされていません。

  • Snowflakeは、 CREATE/ALTER ... REFRESH を使用してテーブルをリフレッシュするたびに、最大1000個のデルタコミットファイルを処理します。テーブルのコミットファイルが1000個を超える場合は、さらに手動でリフレッシュできます。毎回、リフレッシュ処理は前回の停止位置から続行されます。

    注釈

    SnowflakeはIcebergテーブルを作成する際にDeltaチェックポイントファイルを使用します。1,000コミットファイルの制限は、最新のチェックポイント以降のコミットにのみ適用されます。

    既存のテーブルを更新する場合、Snowflakeはデルタコミットファイルを処理しますが、チェックポイントファイルは処理しません。テーブルメンテナンスでソースデルタテーブルの古いログとデータファイルが削除された場合、SnowflakeのデルタベースのIcebergテーブルをデルタログとデータファイルの保持期間よりも頻繁に更新する必要があります。

  • メタデータについて:

    注意

    Snowflakeサービスを使用する場合、お客様は、個人データ(ユーザーオブジェクト向け以外)、機密データ、輸出管理データ、またはその他の規制されたデータがメタデータとして入力されていないことを確認する必要があります。詳細については、 Snowflakeのメタデータフィールド をご参照ください。

テーブルをリフレッシュする

この例では、以下のシナリオでテーブルのメタデータを手動でリフレッシュします。

  • この表は、Iceberg のカタログ用に AWS Glue を使用しています。

  • このテーブルは、オブジェクト・ストレージのDelta・テーブル・ファイルに基づいています。

これらのシナリオでは、refreshコマンドでメタデータ・ファイルのパスを指定しません。

ALTER ICEBERG TABLE myIcebergTable REFRESH;
Copy

オブジェクトストレージ内のIcebergファイルから作成されたテーブルのリフレッシュ

この例では、新しいメタデータファイルの変更に基づいてテーブルメタデータを手動で更新します。この例では、メタデータファイルへのフルパスは <external-volume-storage-base-url>/path/to/metadata/v2.metadata.json です。

メタデータファイルを指定する場合は、メタデータファイルのパスに先頭のスラッシュ(/)を含めません。

ALTER ICEBERG TABLE my_iceberg_table REFRESH 'path/to/metadata/v2.metadata.json';
Copy

注釈

Snowflakeのバージョン7.34以前では、オブジェクトストレージ内のIcebergファイルからテーブルを作成するには BASE_LOCATION (以前のバージョンでの別称は FILE_PATH)というパラメーターが必要でした。パラメーターは、 EXTERNAL_VOLUME の場所からの相対パスを指定しました。

古い構文を使用して作成したテーブルをリフレッシュするには、 BASE_LOCATION への相対パスを指定します。例えば、メタデータファイルのフルパスが s3://mybucket_us_east_1/my_base_location/metadata/v1.metadata.json の場合、 metadata/v1.metadata.jsonmetadata-file-relative-path として指定します。