Microsoft Azure BLOBストレージ用Snowpipeの自動化

このトピックでは、BLOBストレージイベントの Microsoft Azure Event Grid メッセージを使用して、Snowpipeデータのロードを自動的にトリガーする手順を説明します。手順では、データファイルが保存されているBLOBストレージのターゲットパスのイベントメッセージを作成する方法について説明します。

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

  • BLOBストレージ

  • Data Lake Storage Gen2

  • 汎用v2

Microsoft.Storage.BlobCreated イベントのみが、Snowpipeをトリガーしてファイルをロードします。BLOBストレージに新しいオブジェクトを追加するだけで、これらのイベントがトリガーされます。ディレクトリまたはオブジェクトの名前を変更しても、これらのイベントはトリガーされません。

このトピックの内容:

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

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

  • Amazonウェブサービス（AWS）

  • Microsoft Azure

このサポートを構成する手順は、どちらのクラウドホスティングプラットフォームのアカウントでも同じです。すべてのSnowflakeオブジェクト（例: 統合、ステージ、ファイル形式）は、ターゲットテーブルを保存するSnowflakeアカウントで作成されます。

プロセスフロー

Azureコンテナーの Microsoft Azure Event Grid 通知によるトリガーで、Snowpipeデータが自動的にロードされます。

次の図は、Snowpipeの自動インジェストプロセスフローを示しています。

Snowpipe Auto-ingest Process Flow

  1. データファイルはステージにロードされます。

  2. BLOBストレージイベントメッセージは、Event Gridを介してSnowpipeにファイルをロードする準備ができたことを通知します。Snowpipeはファイルをキューにコピーします。

  3. Snowflakeが提供する仮想ウェアハウスは、指定されたパイプで定義されたパラメーターに基づいて、キューに入れられたファイルからターゲットテーブルにデータをロードします。

手順については、 Microsoft Azure BLOBストレージ用Snowpipeの自動化 をご参照ください。

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

注釈

データファイルを格納する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>/') ]

条件：

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

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

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

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

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

次の例では、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/');

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

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

    DESC STORAGE INTEGRATION <integration_name>;

    条件：

AZURE_CONSENT_URL 列にある、次の形式を持つ URL に注意します。

https://login.microsoftonline.com/<tenant_id>/oauth2/authorize?client_id=<snowflake_application_id>

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

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

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

  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 読み取りおよび書き込みアクセスを許可します。これにより、ストレージアカウントでステージングされたファイルからのデータのロードまたはアンロードが可能になります。

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

    重要

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

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

  8. Save ボタンをクリックします。

    注釈

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

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

注釈

このトピックの手順では、データがロードされるSnowflakeデータベースにターゲットテーブルが既に存在することを前提としています。

ステップ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>

条件：

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

  • ロケーション は、Azure Storageアカウントの場所、またはSnowflakeの用語では 地域 です。

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

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

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

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

次のコマンドを実行して、データファイルを保存するストレージアカウントを作成します。このアカウントは、次のいずれかでなければなりません。

  • BLOBストレージ

  • Data Lake Storage Gen2

  • 汎用v2

これらのアカウントタイプのみがイベントメッセージをサポートします。

注釈

既に、これらのタイプのアカウントのいずれかがある場合は、代わりにそのアカウントを使用できます。

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

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

条件：

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

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

  • ロケーション は、Azure Storageアカウントの場所です。

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

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

注釈

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

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

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

条件：

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

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

  • ロケーション は、Azure Storageアカウントの場所です。

ストレージキューの作成

1つのAzure Queue Storageキューで、多くのEvent Gridサブスクリプションのイベントメッセージを収集できます。1つのストレージキューを複数のストレージアカウントで共有できます。

最高のパフォーマンスを得るために、Snowflakeは、Snowflakeに関連するすべてのサブスクリプションに対応する、単一のストレージキューを作成することをお勧めします。Snowpipeは、メッセージが同じストレージキューを介して中継される場合でも、メッセージを正しいパイプにルーティングします。

注釈

Snowflakeは、Snowpipeイベントメッセージの収集に使用できるストレージキューの数を10に制限しています。

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

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

条件：

参照用のストレージアカウントとキュー 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>"

  • 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>"

条件：

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

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

az extension add --name eventgrid

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

  • Windows：

    az eventgrid event-subscription create \
--source-resource-id %storageid% \
--name <subscription_name> --endpoint-type storagequeue \
--endpoint %queueid%

条件：

ステップ2： Snowflakeで通知統合を作成します

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

注釈

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

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

  1. 組織のAzure管理者としてMicrosoft Azureポータルにログインします。

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

    https://<storage_account_name>.queue.core.windows.net/<storage_queue_name>

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

通知統合の作成

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

注釈

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

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>';

条件：

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

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

    DESC NOTIFICATION INTEGRATION <integration_name>;

    条件：

  2. AZURE_CONSENT_URL 列にある、次の形式を持つ URL に注意します。

    https://login.microsoftonline.com/<tenant_id>/oauth2/authorize?client_id=<snowflake_application_id>

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

  4. Accept ボタンをクリックして、SnowflakeをActive Directoryに登録します。

  5. 組織のAzure管理者としてMicrosoft Azureポータルにログインします。

  6. Azure Active Directory » Enterprise applications に移動します。Snowflakeアプリケーションがリストされていることを確認します。

    重要

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

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

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

  9. Snowflakeアプリケーションを検索します。

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

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

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

    • Select: SnowflakeアプリケーションID

    Snowflakeアプリケーションが Storage Queue Data Contributor の下にリストされるはずです（同じダイアログ上）。

ステップ3：ステージを作成する（必要な場合）

CREATE STAGE コマンドを使用して、Azureコンテナーを参照する外部ステージを作成します。Snowpipeはステージからデータファイルをフェッチし、ターゲットテーブルにロードする前に一時的にキューに入れます。

または、既存の外部ステージを使用できます。

注釈

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

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

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

USE SCHEMA snowpipe_db.public;

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

注釈

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

ステップ4：自動インジェストを有効にしたパイプを作成する

CREATE PIPE コマンドを使用してパイプを作成します。パイプは、Snowpipeがインジェスションキューからターゲットテーブルにデータをロードするために使用する COPY INTO <テーブル> ステートメントを定義します。

例えば、 mystage ステージにステージングされたファイルから mytable テーブルにデータをロードする snowpipe_db.public スキーマにパイプを作成します。

create pipe snowpipe_db.public.mypipe
  auto_ingest = true
  integration = '<integration_name>'
  as
  copy into snowpipe_db.public.mytable
  from @snowpipe_db.public.mystage
  file_format = (type = 'JSON');

条件：

重要

  • 統合名はすべて大文字で入力する必要があります。

  • パイプ定義のステージ参照を既存のパイプと比較します。同じAzureコンテナーのディレクトリパスが重複していないことを確認します。そうしないと、複数のパイプが同じデータファイルのセットを複数回、1つ以上のターゲットテーブルにロードする可能性があります。これは、たとえば、複数のステージが azure://myaccount.blob.core.windows.net/mycontainer/path1 や azure://myaccount.blob.core.windows.net/mycontainer/path1/path2 などの異なるレベルの細分性で同じAzureコンテナーを参照している場合に発生する可能性があります。このユースケースでは、ファイルが azure://myaccount.blob.core.windows.net/mycontainer/path1/path2 にステージングされている場合、両方のステージのパイプがファイルのコピーをロードします。

    これは、Snowpipeの手動設定（自動インジェスト 無効）とは異なり、ユーザーがファイルの名前付きセットを REST API に送信して、ロードするファイルをキューに入れる必要があります。自動インジェストを有効にすると、各パイプはEvent Gridメッセージから生成されたファイルリストを受け取ります。データの重複を避けるために、追加の注意が必要です。

注釈

データベースまたはスキーマのクローンを作成すると、ソースデータベースまたはスキーマ内の外部ステージを参照するパイプを含む、 すべて のオブジェクトがクローンされます。データファイルがステージの場所に作成されるとき（例：BLOBストレージコンテナー）、通知のコピーがステージの場所に一致するすべてのパイプに送信されます。これにより、次の動作が発生します。

  • パイプ定義の COPY ステートメントでテーブルが完全修飾されている場合（ データベース名.スキーマ名.テーブル名 または スキーマ名.テーブル名 の形式）、次にSnowpipeは各パイプのソーステーブル（つまり、 COPY ステートメントの データベース.スキーマ.テーブル ）に重複データをロードします。

  • テーブルがパイプ定義で完全修飾されて いない 場合、Snowpipeはデータをソースおよびクローン化されたデータベース/スキーマの同じテーブル（例： mytable）にロードします。

自動インジェストを使用したSnowpipeが構成されました。

新しいデータファイルがAzureコンテナーに追加されると、イベントメッセージはSnowpipeに通知して、パイプで定義されたターゲットテーブルにそれらをロードします。

ステップ5：履歴ファイルをロードする

Event Gridメッセージが構成される 前 に外部ステージに存在したデータファイルのバックログをロードするには、 ALTER PIPE ... REFRESH ステートメントを実行します。

SYSTEM$PIPE_STATUS 出力

SYSTEM$PIPE_STATUS 関数は、パイプの現在のステータスの JSON 表現を取得します。

TRUEに設定された AUTO_INGEST のパイプの場合、関数は次の名前/値のペアを含む JSON オブジェクトを返します（現在のパイプステータスに該当する場合）。

{"executionState":"<値>","oldestFileTimestamp":<値>,"pendingFileCount":<値>,"notificationChannelName":"<値>","numOutstandingMessagesOnChannel":<値値>,"lastReceivedMessageTimestamp":"<値>","lastForwardedMessageTimestamp":"<値>","error":<値>,"fault":<値>}

条件：

executionState

パイプの現在の実行状態は、次のいずれかです。

  • RUNNING （つまり、すべてが正常です。Snowflakeはこのパイプのファイルをアクティブに処理する場合としない場合があります）

  • STOPPED_FEATURE_DISABLED

  • STOPPED_STAGE_DROPPED

  • STOPPED_FILE_FORMAT_DROPPED

  • STOPPED_MISSING_PIPE

  • STOPPED_MISSING_TABLE

  • STALLED_COMPILATION_ERROR

  • STALLED_INITIALIZATION_ERROR

  • STALLED_EXECUTION_ERROR

  • STALLED_INTERNAL_ERROR

  • PAUSED

  • PAUSED_BY_SNOWFLAKE_ADMIN

  • PAUSED_BY_ACCOUNT_ADMIN

oldestFileTimestamp

現在キューに入れられているデータファイルの中で最も早いタイムスタンプ（該当する場合）。ファイルがキューに追加されるときにタイムスタンプが設定されます。

pendingFileCount

現在パイプによって処理されているファイルの数。パイプが一時停止されている場合、パイプが一時停止される 前に キューに入れられたファイルが処理されるため、この値は減少します。この値が 0 の場合、このパイプのキューに入れられているファイルがないか、パイプが事実上一時停止しています。

notificationChannelName

パイプに関連付けられたAzureストレージキュー。

numOutstandingMessagesOnChannel

キューに入れられたがまだ受信されていないストレージキュー内のメッセージの数。

lastReceivedMessageTimestamp

ストレージキューから受信した最後のメッセージのタイムスタンプ。たとえば、メッセージに関連付けられたパス/プレフィックスがパイプ定義のパス/プレフィックスと一致しない場合など、このメッセージが特定のパイプに適用されない場合があります。また、作成されたデータオブジェクトによってトリガーされたメッセージのみが自動インジェストパイプによって消費されます。

lastForwardedMessageTimestamp

パイプに転送された一致するパス/プレフィックスを持つ最後の「オブジェクトの作成」イベントメッセージのタイムスタンプ。

error

パイプが実行のために最後にコンパイルされたときに生成されたエラーメッセージ（該当する場合）。多くの場合、権限の問題またはオブジェクトの削除により、必要なオブジェクト（テーブル、ステージ、ファイル形式）へのアクセスに問題が生じたことが原因です。

fault

最新の内部Snowflakeプロセスエラー（該当する場合）。主にSnowflakeがデバッグ目的で使用します。

通知統合 DDL

通知の作成と管理をサポートするために、Snowflakeは次の一連の特別な DDL コマンドを提供します。