Azure Blob Storageの外部テーブルを自動的に更新する

Azure コンテナの Microsoft Azure Event Grid 通知を使用すると、外部テーブルを作成し、外部テーブルのメタデータを自動的に更新できます。この操作は、メタデータを外部ステージと外部パスの関連ファイルの最新セットと同期します。

次のリストは、パス内のファイルの状態がテーブルメタデータにどのように影響するかを示しています。

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

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

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

サポートされているアカウント、APIs、およびスキーマ

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

  • BLOBストレージ

  • Data Lake Storage Gen2

  • 汎用v2

注釈

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

クラウドプラットフォームのサポートとして、Azure Event Gridメッセージを使用した自動外部メタデータリフレッシュのトリガーは、Microsoft Azure(Azure)でホストされている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は外部テーブルのメタデータを更新しません。

Snowflakeは、 Azure Event Gridイベントスキーマ のみをサポートしています。CloudEvents Azure Event Grid スキーマはサポートしていません。

外部テーブルはストレージのバージョン管理(S3のバージョン管理、Google Cloud Storageのオブジェクトバージョン管理、Azure Storageのバージョン管理)をサポートしていません。

前提条件

続行する前に、次の前提条件を満たしていることを確認してください。

  • スキーマに対する CREATE STAGE および CREATE EXTERNAL TABLE 権限を持つロール。

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

  • Azure Blob Storageの外部テーブルを自動更新できるようにする前に、通知統合が必要です。

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

重要

データファイルを格納するAzure Blob Storageコンテナへの安全なアクセスを既に構成している場合は、このセクションをスキップして ステップ1: Event Grid サブスクリプションを構成する に進んでください。

クラウドストレージの認証責任をSnowflake IDおよびアクセス管理(IAM)エンティティに委任するには、Snowflakeストレージ統合オブジェクトを構成する必要があります。

注釈

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

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

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

注釈

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

このセクションの内容:

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

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

1つのストレージ統合で、複数の外部(つまり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クライアントアプリケーションの名前。このセクションの後半のステップでは、このアプリケーションに、許可されたストレージの場所でアクセストークンを取得するために必要な権限を付与する必要があります。

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

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

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

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

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

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

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

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

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

  8. 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でロールの割り当てを追加する
  9. Review + assign ボタンをクリックします。

    注釈

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

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

注釈

SYSTEM$VALIDATE_STORAGE_INTEGRATION 関数を使用して、ストレージ統合の構成を検証することができます。

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: 通知統合を作成する

A 通知統合 は、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 Message Processor または Storage Queue Data Contributor の下にリストされるようになります(同じダイアログ上)。

(オプション)ステップ3: ステージを作成する

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

注釈

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

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

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

USE SCHEMA mydb.public;

CREATE STAGE mystage
  URL='azure://myaccount.blob.core.windows.net/mycontainer/files/'
  STORAGE_INTEGRATION = my_storage_int;
Copy

注釈

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

ステップ4: 外部テーブルを作成する

CREATE EXTERNAL TABLE コマンドを使用して外部テーブルを作成します。

たとえば、 mydb.public パスで、 JSON ステージにステージングされたファイルから mystage データを読み取る path1/ スキーマに、外部テーブルを作成するとします。

CREATE OR REPLACE EXTERNAL TABLE ext_table
 INTEGRATION = 'MY_NOTIFICATION_INT'
 WITH LOCATION = @mystage/path1/
 FILE_FORMAT = (TYPE = JSON);
Copy

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

通知統合が指定されている場合、AUTO_REFRESH`パラメーターはデフォルトで:samp:`TRUE`になります。通知の統合がない場合、AUTO_REFRESH は常に :samp:`FALSE です。

このステップを完了すると、自動更新のある外部ステージが構成されます。

新規または更新されたデータファイルがAzureコンテナに追加されると、イベント通知はSnowflakeに通知して、それらを外部テーブルメタデータにスキャンします。

ステップ5: 外部テーブルのメタデータを手動で更新する

ALTER EXTERNAL TABLE を REFRESH パラメーターとともに使用して、外部テーブルのメタデータを手動で1回更新します。例:

ALTER EXTERNAL TABLE ext_table REFRESH;

+---------------------------------------------+----------------+-------------------------------+
| file                                        | status         | description                   |
|---------------------------------------------+----------------+-------------------------------|
| files/path1/file1.json                      | REGISTERED_NEW | File registered successfully. |
| files/path1/file2.json                      | REGISTERED_NEW | File registered successfully. |
| files/path1/file3.json                      | REGISTERED_NEW | File registered successfully. |
+---------------------------------------------+----------------+-------------------------------+
Copy

このステップは、外部テーブル定義のステージおよびパス内のファイルのリストとメタデータを同期します。また、このステップにより、外部テーブルが指定されたステージとパスのデータファイルを読み取ることができ、外部テーブル定義に欠落しているファイルがないことを確認します。

file 列のファイルのリストが期待と一致しない場合、外部テーブル定義と外部ステージ定義のパスを確認します。外部テーブル定義のパスは、ステージ定義で指定されたパスに追加されます。詳細については、 CREATE EXTERNAL TABLE をご参照ください。

重要

外部テーブルの作成後にこの手順が少なくとも1回正常に完了しない場合、外部テーブルのクエリは、Event Grid通知が外部テーブルのメタデータを初めて自動的に更新するまで結果を返しません。

これにより、ステップ4以降に発生したファイルリストへの変更とメタデータが同期されます。その後、Event Grid通知はメタデータの更新を自動的にトリガーします。

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

外部テーブルへのクエリに使用する追加のロールごとに、GRANT <権限> ... TO ROLE を使用して、さまざまなオブジェクト(データベース、スキーマ、ステージ、テーブル)に十分なアクセス制御権限を付与します。

オブジェクト

権限

注意

データベース

USAGE

スキーマ

USAGE

名前付きステージ

USAGE , READ

名前付きファイル形式

USAGE

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

外部テーブル

SELECT