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の自動インジェストプロセスフローを示しています。
データファイルはステージにロードされます。
BLOBストレージイベントメッセージは、Event Gridを介してSnowpipeにファイルをロードする準備ができたことを通知します。Snowpipeはファイルをキューにコピーします。
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アクセスを許可する¶
DESCRIBE INTEGRATION コマンドを実行して、同意 URL を取得します。
DESC STORAGE INTEGRATION <integration_name>;
条件：
統合名は、 ステップ1: Snowflakeでクラウドストレージ統合を作成する で作成した統合の名前です。
次の列の値に注意します。
- AZURE_CONSENT_URL
Microsoftのアクセス許可リクエストページへの URL。
- AZURE_MULTI_TENANT_APP_NAME
アカウント用に作成されたSnowflakeクライアントアプリケーションの名前。このセクションの後半のステップでは、このアプリケーションに、許可されたストレージの場所でアクセストークンを取得するために必要な権限を付与する必要があります。
ウェブブラウザーで AZURE_CONSENT_URL 列にある URL に移動します。このページには、Microsoft許可リクエストページが表示されます。
Accept ボタンをクリックします。このアクションにより、Snowflakeアカウント用に作成されたAzureサービスプリンシパルは、テナント内のリソースでアクセストークンを取得できます。アクセストークンの取得は、コンテナーに対する適切なアクセス許可をサービスプリンシパルに付与した場合にのみ成功します（次のステップを参照）。
Microsoft Azureポータルにログインします。
Azure Services » Storage Accounts に移動します。Snowflakeサービスプリンシパルアクセスを許可するストレージアカウントの名前をクリックします。
Access Control (IAM) » Add role assignment をクリックします。
Snowflakeサービスプリンシパルに付与する目的のロールを選択します。
Storage Blob Data Reader読み取りアクセスのみを許可します。これにより、ストレージアカウントにステージングされたファイルからデータをロードできます。Storage Blob Data Contributor読み取りおよび書き込みアクセスを許可します。これにより、ストレージアカウントでステージングされたファイルからのデータのロードまたはアンロードが可能になります。このロールでは、 REMOVE コマンドを実行して、ストレージアカウントにステージングされたファイルを削除することもできます。
Snowflakeサービスプリンシパルを検索します。これは DESC STORAGE INTEGRATION 出力（ステップ1）の AZURE_MULTI_TENANT_APP_NAME プロパティにあるIDです。AZURE_MULTI_TENANT_APP_NAME プロパティで、アンダースコアの 前にある 文字列を検索します。
重要
このセクションのMicrosoftリクエストページでリクエストされたSnowflakeサービスプリンシパルをAzureが作成するのに、1時間以上かかる場合があります。サービスプリンシパルがすぐに利用できない場合は、1～2時間待ってから、もう一度検索することをお勧めします。
サービスプリンシパルを削除すると、ストレージ統合が機能しなくなります。
Save ボタンをクリックします。
注釈
Microsoft Azureのドキュメントによると、ロールの割り当てが反映されるまでに最大5分かかる場合があります。
Azure Event Gridを使用した自動化の構成¶
ステップ1: Event Gridサブスクリプションを構成する¶
このセクションでは、Azure CLI を使用してAzure StorageイベントのEvent Gridサブスクリプションを設定する方法について説明します。このセクションで説明されている手順の詳細については、Azureドキュメントの次の記事をご参照ください：
https://docs.microsoft.com/en-us/azure/event-grid/custom-event-to-queue-storage
https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-event-quickstart
リソースグループを作成する¶
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ストレージ（つまり、 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
条件：
リソースグループ名は、 リソースグループの作成 で作成したリソースグループの名前です。ストレージアカウント名は、新しいストレージアカウントの名前です。ロケーションは、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
条件：
リソースグループ名は、 リソースグループの作成 で作成したリソースグループの名前です。ストレージアカウント名は、新しいストレージアカウントの名前です。ロケーションは、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>
条件：
ストレージキュー名は、新しいストレージキューの名前です。ストレージアカウント名は、 ストレージキューのストレージアカウントの作成 で作成したストレージアカウントの名前です。
参照用のストレージアカウントとキュー 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%
条件：
ストレージidおよびキューidは、 参照用のストレージアカウントとキュー IDs のエクスポート で設定したストレージアカウントとキューの ID 環境変数です。サブスクリプション名は、新しいEvent Gridサブスクリプションの名前です。
ステップ2: 通知統合を作成する¶
通知統合は、Snowflakeと、Azure Event Gridといった、サードパーティのクラウドメッセージキューサービス間のインターフェイスを提供するSnowflakeオブジェクトです。
注釈
Azure Queue Storageキューは、単一の通知の統合をサポートしています。イベント通知は通知の統合間で分割されるため、複数の通知統合で単一のストレージキューを参照すると、ターゲットテーブルのデータが失われる可能性があります。
ストレージキュー URL およびテナント ID の取得¶
Microsoft Azureポータルにログインします。
Storage account » Queue service » Queues に移動します。後で参照できるように、 ストレージキューの作成 で作成したキューの URL を記録します。 URL の形式は次のとおりです。
https://<storage_account_name>.queue.core.windows.net/<storage_queue_name>
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>';
条件：
統合名は、新しい統合の名前です。キュー URLおよびディレクトリ IDは、 ストレージキュー URL およびテナント ID の取得 で記録したキュー URL およびテナント ID です。
例：
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';
ストレージキューへのSnowflakeアクセスの許可¶
DESCRIBE INTEGRATION コマンドを実行して、同意 URL を取得します。
DESC NOTIFICATION INTEGRATION <integration_name>;
条件：
統合名は、 統合の作成 で作成した統合の名前です。
AZURE_CONSENT_URL 列にある、次の形式を持つ URL に注意します。
https://login.microsoftonline.com/<tenant_id>/oauth2/authorize?client_id=<snowflake_application_id>client_idの値を URL に記録します。この値は、Snowflakeアプリケーション識別子です。この値は、この同じセクションの後半のステップで必要になります。ウェブブラウザーで URL に移動します。このページには、Microsoft許可リクエストページが表示されます。
Accept ボタンをクリックして、SnowflakeをActive Directoryに登録します。
Microsoft Azureポータルにログインします。
Azure Active Directory » Enterprise applications に移動します。このセクションのステップ2で記録した、Snowflakeアプリケーション識別子がリストされていることを確認します。
重要
Azure Active DirectoryでSnowflakeアプリケーションを後で削除すると、通知統合が機能しなくなります。
Queues »
ストレージキュー名に移動します。ストレージキュー名は、 ストレージキューの作成 で作成したストレージキューの名前です。Access Control (IAM) » Add role assignment をクリックします。
Snowflakeアプリケーション識別子を検索します。
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 が含まれています。ステージは my_storage_int という名前のストレージ統合を参照します。
USE SCHEMA snowpipe_db.public; CREATE STAGE mystage URL = 'azure://myaccount.blob.core.windows.net/mycontainer/load/files/' STORAGE_INTEGRATION = my_storage_int;
注釈
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 = 'MY_NOTIFICATION_INT' as copy into snowpipe_db.public.mytable from @snowpipe_db.public.mystage file_format = (type = 'JSON');
条件：
通知統合名は、 ステップ2: 通知統合を作成する で作成した通知の名前です。
重要
統合名はすべて大文字で入力する必要があります。
COPY INTO <テーブル> ステートメントの保存場所の参照が、アカウントにある既存のパイプの参照と重複していないことを確認します。そうしないと、複数のパイプが、同じデータファイルのセットをターゲットテーブルにロードする可能性があります。たとえば、この状況は、複数のパイプ定義が
<ストレージの場所>/path1/や<ストレージの場所>/path1/path2/など、細分性のレベルが異なる同じストレージの場所を参照している場合に発生する可能性があります。この例では、ファイルが<ストレージの場所>/path1/path2/でステージングされている場合は、両方のパイプがファイルのコピーをロードします。SHOW PIPES を実行するか、Account Usageの PIPES ビューまたはInformation Schemaの PIPES ビューのいずれかをクエリして、アカウントにあるパイプの定義すべての COPY INTO <テーブル> ステートメントを表示します。
注釈
データベースまたはスキーマのクローンを作成すると、ソースデータベースまたはスキーマ内の外部ステージを参照するパイプを含む、 すべて のオブジェクトがクローンされます。データファイルがステージの場所に作成されるとき（例: BLOBストレージコンテナー）、通知のコピーがステージの場所に一致するすべてのパイプに送信されます。これにより、次の動作が発生します。
パイプ定義の COPY ステートメントでテーブルが完全修飾されている場合（
データベース名.スキーマ名.テーブル名またはスキーマ名.テーブル名の形式）、次にSnowpipeは各パイプのソーステーブル（つまり、 COPY ステートメントのデータベース.スキーマ.テーブル）に重複データをロードします。テーブルがパイプ定義で完全修飾されて いない 場合、Snowpipeはデータをソースおよびクローン化されたデータベース/スキーマの同じテーブル（例：
mytable）にロードします。
自動インジェストを使用したSnowpipeが構成されました。
新しいデータファイルがAzureコンテナーに追加されると、イベントメッセージはSnowpipeに通知して、パイプで定義されたターゲットテーブルにそれらをロードします。
ステップ5：履歴ファイルをロードする¶
Event Gridメッセージが構成される 前 に外部ステージに存在したデータファイルのバックログをロードするには、 ALTER PIPE ... REFRESH ステートメントを実行します。
ステップ6: ステージングされたファイルを削除する¶
データが正常にロードされ、ファイルが不要になったら、ステージングされたファイルを削除します。手順については、 Snowpipeがデータをロードした後のステージングされたファイルの削除 をご参照ください。
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_ADMINoldestFileTimestamp現在キューに入れられているデータファイルの中で最も早いタイムスタンプ（該当する場合）。ファイルがキューに追加されるときにタイムスタンプが設定されます。
pendingFileCount現在パイプによって処理されているファイルの数。パイプが一時停止されている場合、パイプが一時停止される 前に キューに入れられたファイルが処理されるため、この値は減少します。この値が
0の場合、このパイプのキューに入れられているファイルがないか、パイプが事実上一時停止しています。notificationChannelNameパイプに関連付けられたAzureストレージキュー。
numOutstandingMessagesOnChannelキューに入れられたがまだ受信されていないストレージキュー内のメッセージの数。
lastReceivedMessageTimestampストレージキューから受信した最後のメッセージのタイムスタンプ。たとえば、メッセージに関連付けられたパス/プレフィックスがパイプ定義のパス/プレフィックスと一致しない場合など、このメッセージが特定のパイプに適用されない場合があります。また、作成されたデータオブジェクトによってトリガーされたメッセージのみが自動インジェストパイプによって消費されます。
lastForwardedMessageTimestampパイプに転送された一致するパス/プレフィックスを持つ最後の「オブジェクトの作成」イベントメッセージのタイムスタンプ。
errorパイプが実行のために最後にコンパイルされたときに生成されたエラーメッセージ（該当する場合）。多くの場合、権限の問題またはオブジェクトの削除により、必要なオブジェクト（テーブル、ステージ、ファイル形式）へのアクセスに問題が生じたことが原因です。
fault最新の内部Snowflakeプロセスエラー（該当する場合）。主にSnowflakeがデバッグ目的で使用します。