Azure BLOBストレージに対するディレクトリテーブルの自動更新

このトピックでは、Azureコンテナーの Microsoft Azure Event Grid 通知を使用して、ディレクトリテーブルを作成し、ディレクトリテーブルのメタデータを自動的に更新する手順について説明します。この操作は、メタデータを外部ステージと外部パスの関連ファイルの最新セットと同期します。つまり、

  • パス内の新しいファイルがテーブルメタデータに追加されます。

  • パス内のファイルへの変更は、テーブルメタデータで更新されます。

  • パス内になくなったファイルは、テーブルのメタデータから削除されます。

Snowflakeは、次のBLOBストレージアカウントのタイプをサポートしています。

  • BLOBストレージ

  • Data Lake Storage Gen2

  • 汎用v2

Microsoft.Storage.BlobCreated および Microsoft.Storage.BlobDeleted イベントのみがディレクトリテーブルの更新をトリガーすることに注意してください。BLOBストレージに新しいオブジェクトを追加すると、これらのイベントがトリガーされます。ディレクトリまたはオブジェクトの名前を変更しても、これらのイベントはトリガーされません。Snowflakeは、コスト、イベントノイズ、遅延を低減するために、ディレクトリテーブルでサポートされているイベントのみを送信することをお勧めします。

Snowflakeは、次の Microsoft.Storage.BlobCreated APIs をサポートしています。

  • CopyBlob

  • PutBlob

  • PutBlockList

  • FlushWithClose

  • SftpCommit

Snowflakeは、次の Microsoft.Storage.BlobDeleted APIs をサポートしています。

  • DeleteBlob

  • DeleteFile

  • SftpRemove

Data Lake Storage Gen2ストレージアカウントの場合は、クライアントが CreateFile および FlushWithClose 操作を使用すると、 Microsoft.Storage.BlobCreated イベントがトリガーされます。SSH ファイル転送プロトコル(SFTP)が使用されている場合は、 SftpCreate および SftpCommit 操作によって Microsoft.Storage.BlobCreated イベントがトリガーされます。 CreateFile または SftpCreate API 単体では、ストレージアカウント内のファイルのコミットを表しません。 FlushWithClose または SftpCommit メッセージが送信されない場合、Snowflakeはディレクトリテーブルを更新しません。

注釈

このトピックで説明されているタスクを実行するには、スキーマに対する CREATE STAGE 権限を持つロールを使用する必要があります。

さらに、Microsoft Azureへの管理アクセスが必要です。Azure管理者でない場合は、Azure管理者に ステップ1:Event Gridサブスクリプションを構成する の手順を完了するよう依頼します。

このトピックの内容:

クラウドプラットフォームのサポート

Azure Event Gridメッセージを使用した自動外部メタデータ更新のトリガーは、次の クラウドプラットフォーム でホストされているSnowflakeアカウントにおいてのみサポートされています。

  • Amazon Web Services(AWS)

  • Microsoft Azure

このサポートを構成する手順は、どちらのクラウドホスティングプラットフォームのアカウントでも同じです。

クラウドストレージへの安全なアクセスの構成

注釈

データファイルを格納するAzureBLOBストレージコンテナーへの安全なアクセスを既に構成している場合は、このセクションをスキップできます。

このセクションでは、Snowflakeストレージ統合オブジェクトを構成して、クラウドストレージの認証責任をSnowflake IDおよびアクセス管理(IAM)エンティティに委任する方法について説明します。

注釈

このオプションを強くお勧めします。これにより、クラウドストレージにアクセスするときに IAM 認証情報を提供する必要がなくなります。その他のストレージアクセスオプションについては データをロードするためのAzureコンテナーの構成 をご参照ください。

このセクションでは、ストレージ統合を使用して、Snowflakeが外部(Azure)ステージで参照されるAzureコンテナーに対してデータを読み書きできるようにする方法について説明します。統合は、名前付きのファーストクラスのSnowflakeオブジェクトであり、秘密キーまたはアクセストークンといった、クラウドプロバイダーの明示的な認証情報を渡す必要がありません。統合オブジェクトには、 アプリ登録 と呼ばれるAzure IDおよびアクセス管理(IAM)ユーザー ID が格納されます。組織の管理者は、このアプリにAzureアカウントで必要なアクセス許可を付与します。

統合では、統合を使用する外部ステージを作成するときにユーザーが指定できる場所を制限するコンテナー(およびオプションのパス)も指定する必要があります。

注釈

このセクションの手順を完了するには、ストレージアカウントを管理するAzureの権限が必要です。Azure管理者でない場合は、Azure管理者にこれらのタスクを実行するよう依頼します。

このセクションの内容:

ステップ1:Snowflakeでクラウドストレージ統合を作成する

CREATE STORAGE INTEGRATION コマンドを使用してストレージ統合を作成します。ストレージ統合は、Azureクラウドストレージ用に生成されたサービスプリンシパルと、許可またはブロックされたストレージの場所(コンテナーなど)のオプションセットを格納するSnowflakeオブジェクトです。組織のクラウドプロバイダー管理者は、生成されたサービスプリンシパルにストレージの場所に対するアクセス許可を付与します。このオプションにより、ユーザーはステージの作成時またはデータのロード時に認証情報の提供を回避できます。

単一のストレージ統合により、複数の外部(つまり、Azure)ステージをサポートできます。ステージ定義にある URL は、 STORAGE_ALLOWED_LOCATIONS パラメーターのために指定されたAzureコンテナー(およびオプションのパス)に合わせる必要があります。

注釈

この SQL コマンドを実行できるのは、アカウント管理者( ACCOUNTADMIN ロールを持つユーザー)またはグローバル CREATE INTEGRATION 権限を持つロールのみです。

CREATE STORAGE INTEGRATION <integration_name>
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'AZURE'
  ENABLED = TRUE
  AZURE_TENANT_ID = '<tenant_id>'
  STORAGE_ALLOWED_LOCATIONS = ('azure://<account>.blob.core.windows.net/<container>/<path>/', 'azure://<account>.blob.core.windows.net/<container>/<path>/')
  [ STORAGE_BLOCKED_LOCATIONS = ('azure://<account>.blob.core.windows.net/<container>/<path>/', 'azure://<account>.blob.core.windows.net/<container>/<path>/') ]
Copy

条件:

  • integration_name は、新しい統合の名前です。

  • tenant_id は、許可およびブロックされたストレージアカウントが属するOffice 365テナントの ID です。ストレージ統合は1つのテナントのみを認証できるため、許可およびブロックされたストレージの場所は、すべてこのテナントに属するストレージアカウントを参照する必要があります。

    テナント ID を見つけるには、Azureポータルにログインして Azure Active Directory » Properties をクリックします。テナント ID が Tenant ID フィールドに表示されます。

  • container は、データファイルを保存するAzureコンテナーの名前です(例: mycontainer)。STORAGE_ALLOWED_LOCATIONS および STORAGE_BLOCKED_LOCATIONS パラメーターは、この統合を参照するステージが作成または変更されるときに、それぞれこれらのコンテナーへのアクセスを許可またはブロックします。

  • path は、コンテナー内の論理ディレクトリを細かく制御するために使用できるオプションのパスです。

次の例では、2つのコンテナーとパスのいずれかを参照するために統合を使用する外部ステージを明示的に制限する統合を作成します。後のステップで、これらのコンテナーとパスのいずれかを参照する外部ステージを作成します。この統合を使用する複数の外部ステージは、許可されたコンテナーとパスを参照できます。

CREATE STORAGE INTEGRATION azure_int
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'AZURE'
  ENABLED = TRUE
  AZURE_TENANT_ID = 'a123b4c5-1234-123a-a12b-1a23b45678c9'
  STORAGE_ALLOWED_LOCATIONS = ('azure://myaccount.blob.core.windows.net/mycontainer1/mypath1/', 'azure://myaccount.blob.core.windows.net/mycontainer2/mypath2/')
  STORAGE_BLOCKED_LOCATIONS = ('azure://myaccount.blob.core.windows.net/mycontainer1/mypath1/sensitivedata/', 'azure://myaccount.blob.core.windows.net/mycontainer2/mypath2/sensitivedata/');
Copy

ステップ2:ストレージの場所にSnowflakeアクセスを許可する

  1. DESCRIBE INTEGRATION コマンドを実行して、同意 URL を取得します。

    DESC STORAGE INTEGRATION <integration_name>;
    
    Copy

    条件:

次の列の値に注意します。

AZURE_CONSENT_URL:

Microsoftのアクセス許可リクエストページへの URL。

AZURE_MULTI_TENANT_APP_NAME:

アカウント用に作成されたSnowflakeクライアントアプリケーションの名前。このセクションの後半のステップでは、このアプリケーションに、許可されたストレージの場所でアクセストークンを取得するために必要な権限を付与する必要があります。

  1. ウェブブラウザーで AZURE_CONSENT_URL 列にある URL に移動します。このページには、Microsoft許可リクエストページが表示されます。

  2. Accept ボタンをクリックします。このアクションにより、Snowflakeアカウント用に作成されたAzureサービスプリンシパルは、テナント内の指定されたリソースでアクセストークンを取得できるようになります。アクセストークンの取得は、コンテナーに対する適切なアクセス許可をサービスプリンシパルに付与した場合にのみ成功します(次のステップを参照)。

    Microsoftの権限リクエストページは、Snowflakeの企業サイト(snowflake.com)にリダイレクトされます。

  3. Microsoft Azureポータルにログインします。

  4. Azure Services » Storage Accounts に移動します。Snowflakeサービスプリンシパルアクセスを許可するストレージアカウントの名前をクリックします。

  5. Access Control (IAM) » Add role assignment をクリックします。

  6. Snowflakeサービスプリンシパルに付与する目的のロールを選択します。

    • Storage Blob Data Reader 読み取りアクセスのみを許可します。これにより、ストレージアカウントにステージングされたファイルからデータをロードできます。

    • Storage Blob Data Contributor 読み取りおよび書き込みアクセスを許可します。これにより、ストレージアカウントでステージングされたファイルからのデータのロードまたはアンロードが可能になります。このロールでは、 REMOVE コマンドを実行して、ストレージアカウントにステージングされたファイルを削除することもできます。

  7. Snowflakeサービスプリンシパルを検索します。これは DESC STORAGE INTEGRATION 出力(ステップ1)の AZURE_MULTI_TENANT_APP_NAME プロパティにあるIDです。AZURE_MULTI_TENANT_APP_NAME プロパティで、アンダースコアの 前にある 文字列を検索します。

    重要

    • このセクションのMicrosoftリクエストページでリクエストされたSnowflakeサービスプリンシパルをAzureが作成するのに、1時間以上かかる場合があります。サービスプリンシパルがすぐに利用できない場合は、1~2時間待ってから、もう一度検索することをお勧めします。

    • サービスプリンシパルを削除すると、ストレージ統合が機能しなくなります。

    Azure Storage Consoleでロールの割り当てを追加する
  8. Review + assign ボタンをクリックします。

    注釈

    • Microsoft Azureのドキュメントによると、ロールの割り当てが反映されるまでに最大5分かかる場合があります。

    • Snowflakeは、一時的な認証情報を一定期間キャッシュしますが、60分の有効期限を越えることができません。Snowflakeからのアクセスを取り消すと、ユーザーはキャッシュの有効期限が切れるまでファイルを一覧表示し、クラウドストレージの場所からデータを読み込むことができる場合があります。

Azure Event Gridを使用した自動化の構成

ステップ1: Event Gridサブスクリプションを構成する

このセクションでは、Azure CLI を使用してAzure StorageイベントのEvent Gridサブスクリプションを設定する方法について説明します。このセクションで説明されている手順の詳細については、Azureドキュメントの次の記事をご参照ください:

リソースグループを作成する

Event Grid トピック は、ソース(つまり、Azureストレージ)がイベントを送信するエンドポイントを提供します。トピックは、関連するイベントのコレクションに使用されます。Event GridトピックはAzureリソースであり、Azureリソースグループに配置する必要があります。

次のコマンドを実行して、リソースグループを作成します。

az group create --name <resource_group_name> --location <location>
Copy

条件:

  • resource_group_name は、新しいリソースグループの名前です。

  • location は、Azure Storageアカウントの場所、またはSnowflakeの用語では リージョン です。

Event Gridリソースプロバイダーの有効化

次のコマンドを実行して、Event Gridリソースプロバイダーを登録します。この手順は、AzureアカウントでEvent Gridを使用したことがない場合にのみ必要です:

az provider register --namespace Microsoft.EventGrid
az provider show --namespace Microsoft.EventGrid --query "registrationState"
Copy

データファイル用のストレージアカウントの作成

次のコマンドを実行して、データファイルを保存するストレージアカウントを作成します。このアカウントは、BLOBストレージ(つまり、 BlobStorage の種類)または GPv2 (つまり、 StorageV2 の種類)アカウントでなければなりません。これら2つのアカウントタイプのみがイベントメッセージをサポートするためです。

注釈

BLOBストレージまたは GPv2 アカウントを既にお持ちの場合は、代わりにそのアカウントを使用できます。

たとえば、BLOBストレージアカウントを作成します。

az storage account create --resource-group <resource_group_name> --name <storage_account_name> --sku Standard_LRS --location <location> --kind BlobStorage --access-tier Hot
Copy

条件:

  • resource_group_name は、 リソースグループを作成する で作成したリソースグループの名前です。

  • storage_account_name は、新しいストレージアカウントの名前です。

  • location は、Azure Storageアカウントの場所です。

ストレージキューのストレージアカウントの作成

次のコマンドを実行して、ストレージキューをホストするストレージアカウントを作成します。このアカウントは GPv2 アカウントでなければなりません。この種類のアカウントのみがストレージキューへのイベントメッセージをサポートするためです。

注釈

既に GPv2 アカウントをお持ちの場合、そのアカウントを使用して、データファイルとストレージキューの両方をホストできます。

例えば、 GPv2 アカウントを作成します:

az storage account create --resource-group <resource_group_name> --name <storage_account_name> --sku Standard_LRS --location <location> --kind StorageV2
Copy

条件:

  • resource_group_name は、 リソースグループを作成する で作成したリソースグループの名前です。

  • storage_account_name は、新しいストレージアカウントの名前です。

  • location は、Azure Storageアカウントの場所です。

ストレージキューの作成

1つのAzure Queue Storageキューで、多くのEvent Gridサブスクリプションのイベントメッセージを収集できます。最高のパフォーマンスを得るために、Snowflakeは、Snowflakeに関連するすべてのサブスクリプションに対応する、単一のストレージキューを作成することをお勧めします。

次のコマンドを実行して、ストレージキューを作成します。ストレージキューには、一連のメッセージ、この場合はEvent Gridからのイベントメッセージが格納されます:

az storage queue create --name <storage_queue_name> --account-name <storage_account_name>
Copy

条件:

参照用のストレージアカウントとキュー IDs のエクスポート

次のコマンドを実行して、次の手順の際にのちほどリクエストされる、ストレージアカウントとキュー IDs の環境変数を設定します。

  • Linuxまたは macOS:

    export storageid=$(az storage account show --name <data_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
    export queuestorageid=$(az storage account show --name <queue_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
    export queueid="$queuestorageid/queueservices/default/queues/<storage_queue_name>"
    
    Copy
  • Windows:

    set storageid=$(az storage account show --name <data_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
    set queuestorageid=$(az storage account show --name <queue_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
    set queueid="%queuestorageid%/queueservices/default/queues/<storage_queue_name>"
    
    Copy

条件:

Event Grid拡張機能のインストール

次のコマンドを実行して、Azure CLIのEvent Grid拡張機能をインストールします:

az extension add --name eventgrid
Copy

Event Gridサブスクリプションの作成

次のコマンドを実行して、Event Gridサブスクリプションを作成します。トピックをサブスクライブすると、Event Gridに追跡するイベントが通知されます:

  • Linuxまたは macOS:

    az eventgrid event-subscription create \
    --source-resource-id $storageid \
    --name <subscription_name> --endpoint-type storagequeue \
    --endpoint $queueid \
    --advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose SftpCommit DeleteBlob DeleteFile SftpRemove
    
    Copy
  • Windows:

    az eventgrid event-subscription create \
    --source-resource-id %storageid% \
    --name <subscription_name> --endpoint-type storagequeue \
    --endpoint %queueid% \
    -advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose SftpCommit DeleteBlob DeleteFile SftpRemove
    
    Copy

条件:

ステップ2: 通知統合を作成する

通知統合は、Snowflakeと、Azure Event Gridといった、サードパーティのクラウドメッセージキューサービス間のインターフェイスを提供するSnowflakeオブジェクトです。

注釈

単一の通知統合は、単一のAzure Storageキューをサポートします。イベント通知は通知の統合間で分割されるため、複数の通知統合で同一のストレージキューを参照すると、ターゲットテーブルのデータが失われる可能性があります。

ストレージキュー URL およびテナント ID の取得

  1. Microsoft Azureポータルにログインします。

  2. Storage account » Queue service » Queues に移動します。後で参照できるように、 ストレージキューの作成 で作成したキューの URL を記録します。 URL の形式は次のとおりです。

    https://<storage_account_name>.queue.core.windows.net/<storage_queue_name>
    
    Copy
  3. Azure Active Directory » Properties に移動します。後で参照できるように、 Tenant ID 値を記録します。Event GridサブスクリプションへのSnowflakeアクセスを許可する同意 URL を生成するには、ディレクトリ IDまたは テナント ID が必要です。

通知統合の作成

CREATE NOTIFICATION INTEGRATION コマンドを使用して通知統合を作成します。

注釈

  • この SQL コマンドを実行できるのは、アカウント管理者( ACCOUNTADMIN ロールを持つユーザー)またはグローバル CREATE INTEGRATION 権限を持つロールのみです。

  • 通知統合のAzureサービスプリンシパルは、ストレージ統合用に作成されたサービスプリンシパルとは異なります。

CREATE NOTIFICATION INTEGRATION <integration_name>
  ENABLED = true
  TYPE = QUEUE
  NOTIFICATION_PROVIDER = AZURE_STORAGE_QUEUE
  AZURE_STORAGE_QUEUE_PRIMARY_URI = '<queue_URL>'
  AZURE_TENANT_ID = '<directory_ID>';
Copy

条件:

例:

CREATE NOTIFICATION INTEGRATION my_notification_int
  ENABLED = true
  TYPE = QUEUE
  NOTIFICATION_PROVIDER = AZURE_STORAGE_QUEUE
  AZURE_STORAGE_QUEUE_PRIMARY_URI = 'https://myqueue.queue.core.windows.net/mystoragequeue'
  AZURE_TENANT_ID = 'a123bcde-1234-5678-abc1-9abc12345678';
Copy

ストレージキューへのSnowflakeアクセスの許可

このセクションの特定のステップでは、Azure CLI をローカルにインストールする必要があることに注意してください。

  1. DESCRIBE INTEGRATION コマンドを実行して、同意 URL を取得します。

    DESC NOTIFICATION INTEGRATION <integration_name>;
    
    Copy

    条件:

    次の列の値に注意します。

    AZURE_CONSENT_URL:

    Microsoftのアクセス許可リクエストページへの URL。

    AZURE_MULTI_TENANT_APP_NAME:

    アカウント用に作成されたSnowflakeクライアントアプリケーションの名前。このセクションの後半のステップでは、このアプリケーションに、許可されたトピックでアクセストークンを取得するために必要な権限を付与する必要があります。

  2. ウェブブラウザーで AZURE_CONSENT_URL 列にある URL に移動します。このページには、Microsoft許可リクエストページが表示されます。

  3. Accept ボタンをクリックします。このアクションにより、Snowflakeアカウント用に作成されたAzureサービスプリンシパルは、テナント内のリソースでアクセストークンを取得できます。アクセストークンの取得は、コンテナーに対する適切なアクセス許可をサービスプリンシパルに付与した場合にのみ成功します(次のステップを参照)。

    Microsoftの権限リクエストページは、Snowflakeの企業サイト(snowflake.com)にリダイレクトされます。

  4. Microsoft Azureポータルにログインします。

  5. Azure Active Directory » Enterprise applications に移動します。このセクションのステップ2で記録した、Snowflakeアプリケーション識別子がリストされていることを確認します。

    重要

    Azure Active DirectoryでSnowflakeアプリケーションを後で削除すると、通知統合が機能しなくなります。

  6. Queues » storage_queue_name に移動します。 storage_queue_name は、 ストレージキューの作成 で作成したストレージキューの名前です。

  7. Access Control (IAM) » Add role assignment をクリックします。

  8. Snowflakeサービスプリンシパルを検索します。これは DESC NOTIFICATION INTEGRATION 出力(ステップ1)の AZURE_MULTI_TENANT_APP_NAME プロパティにあるIDです。AZURE_MULTI_TENANT_APP_NAME プロパティで、アンダースコアの 前にある 文字列を検索します。

    重要

    • このセクションのMicrosoftリクエストページでリクエストされたSnowflakeサービスプリンシパルをAzureが作成するのに、1時間以上かかる場合があります。サービスプリンシパルがすぐに利用できない場合は、1~2時間待ってから、もう一度検索することをお勧めします。

    • サービスプリンシパルを削除すると、通知統合が機能しなくなります。

  9. Snowflakeアプリに次の権限を付与します。

    • Role: ストレージキューデータコントリビューター

    • Assign access to: Azure AD のユーザー、グループ、またはサービスプリンシパル

    • Select: appDisplayName 値。

    Snowflakeアプリケーション識別子が Storage Queue Data Contributor の下にリストされるようになります(同じダイアログ上)。

ステップ3: 含まれているディレクトリテーブルを使用してステージを作成する

CREATE STAGE コマンドを使用して、Azureコンテナーを参照する外部ステージを作成します。Snowflakeは、ステージングされたデータファイルをディレクトリテーブルのメタデータに読み取ります。または、既存の外部ステージを使用できます。

注釈

  • クラウドストレージの場所への安全なアクセスを構成するには、 クラウドストレージへの安全なアクセスの構成 (このトピック内)をご参照ください。

  • CREATE STAGE ステートメントでストレージ統合を参照するには、ストレージ統合オブジェクトに対する USAGE 権限がロールに必要です。

-- External stage
CREATE [ OR REPLACE ] [ TEMPORARY ] STAGE [ IF NOT EXISTS ] <external_stage_name>
      <cloud_storage_access_settings>
    [ FILE_FORMAT = ( { FORMAT_NAME = '<file_format_name>' | TYPE = { CSV | JSON | AVRO | ORC | PARQUET | XML } [ formatTypeOptions ] } ) ]
    [ directoryTable ]
    [ COPY_OPTIONS = ( copyOptions ) ]
    [ COMMENT = '<string_literal>' ]
Copy

条件:

directoryTable (for Microsoft Azure) ::=
  [ DIRECTORY = ( ENABLE = { TRUE | FALSE }
                  [ AUTO_REFRESH = { TRUE | FALSE } ]
                  [ NOTIFICATION_INTEGRATION = '<notification_integration_name>' ] ) ]
Copy

ディレクトリテーブルパラメーター(directoryTable

ENABLE = TRUE | FALSE

ディレクトリテーブルをステージに追加するかどうかを指定します。値が TRUE の場合は、ステージとともにディレクトリテーブルが作成されます。

デフォルト: FALSE

AUTO_REFRESH = TRUE | FALSE

[ WITH ] LOCATION = 設定で指定された名前付き外部ステージで 新しいまたは更新された データファイルが使用可能な場合に、Snowflakeがディレクトリテーブルのメタデータの自動更新トリガーを有効にするかどうかを指定します。

TRUE

Snowflakeを使用すると、ディレクトリテーブルのメタデータの自動更新をトリガーできます。

FALSE

Snowflakeは、ディレクトリテーブルのメタデータの自動更新トリガーを有効にしません。 ALTER STAGE ... REFRESH を使用して、ディレクトリテーブルのメタデータを手動で定期的に更新し、メタデータをステージパスにあるファイルの現在のリストと同期する必要があります。

デフォルト: FALSE

Microsoft Azure

NOTIFICATION_INTEGRATION = '<通知統合名>'

Azure Event Grid通知を使用して、ディレクトリテーブルのメタデータを自動的に更新するために使用される通知統合の名前を指定します。通知統合は、Snowflakeとサードパーティのクラウドメッセージキューサービス間のインターフェイスを提供するSnowflakeオブジェクトです。

次の例では、ユーザーセッションのアクティブスキーマに mystage という名前のステージを作成します。クラウドストレージ URL にはパス files が含まれています。ステージは my_storage_int という名前のストレージ統合を参照します。

USE SCHEMA mydb.public;
Copy
CREATE STAGE mystage
  URL='azure://myaccount.blob.core.windows.net/load/files/'
  STORAGE_INTEGRATION = my_storage_int
  DIRECTORY = (
    ENABLE = true
    AUTO_REFRESH = true
    NOTIFICATION_INTEGRATION = 'MY_NOTIFICATION_INT'
  );
Copy

注釈

  • Data Lake Storage Gen2を含む、サポートされているすべてのタイプのAzure Blobストレージアカウントに、 blob.core.windows.net エンドポイントを使用します。

  • URL 値の保存場所は、スラッシュ(/)で終わる必要があります。

NOTIFICATION_INTEGRATION パラメーターは、 ステップ2: 通知統合を作成する で作成した my_notification_int 統合を参照します。統合名はすべて大文字で提供する必要があります。

新規または更新されたデータファイルがクラウドストレージの場所に追加されると、イベント通知はSnowflakeに通知して、それらをディレクトリテーブルのメタデータにスキャンします。

ステップ4: ディレクトリテーブルのメタデータを手動で更新する

ALTER STAGE コマンドを使用して、ディレクトリテーブルのメタデータを手動で更新します。

構文

ALTER STAGE [ IF EXISTS ] <name> REFRESH [ SUBPATH = '<relative-path>' ]
Copy

条件:

REFRESH

ディレクトリテーブル定義で参照されるステージングされたデータファイルにアクセスし、テーブルメタデータを更新します。

  • パス内の新しいファイルがテーブルメタデータに追加されます。

  • パス内のファイルへの変更は、テーブルメタデータで更新されます。

  • パス内になくなったファイルは、テーブルのメタデータから削除されます。

現在、ファイルがステージに追加、更新、または削除されるたびに、このコマンドを実行する必要があります。このステップでは、ディレクトリテーブルのステージ定義にある関連ファイルの最新セットとメタデータが同期されます。

SUBPATH = '<relative-path>'

任意で、相対パスを指定して、データファイルの特定のサブセットに対するメタデータを更新します。

mystage という名前のステージで、ディレクトリテーブルのメタデータを手動で更新します。

ALTER STAGE mystage REFRESH;
Copy

重要

ディレクトリテーブルの作成後にこのステップが少なくとも1回正常に完了しなかった場合は、通知イベントがディレクトリテーブルのメタデータをトリガーして、初めて自動的に更新されるまで、ディレクトリテーブルをクエリしても結果は返されません。

ステップ5: セキュリティを構成する

ディレクトリテーブルのクエリに使用される追加のロールごとに、 GRANT <権限> を使用してさまざまなオブジェクト(つまり、データベース、スキーマ、ステージ、およびテーブル)に十分なアクセス制御権限を付与します。

オブジェクト

権限

注意

データベース

USAGE

スキーマ

USAGE

名前付きステージ

USAGE , READ

名前付きファイル形式

USAGE

オプション。作成したステージが名前付きファイル形式を参照している場合にのみ必要です。