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

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

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

  • BLOBストレージ

  • Data Lake Storage Gen2

  • 汎用v2

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

  • CopyBlob

  • PutBlob

  • PutBlockList

  • FlushWithClose

Data Lake Storage Gen2ストレージアカウントの場合は、クライアントが CreateFile および FlushWithClose 操作を使用すると、 Microsoft.Storage.BlobCreated イベントがトリガーされます。 CreateFile API だけでは、ストレージアカウント内のファイルのコミットを表しません。 FlushWithClose メッセージがSnowflakeキューに送信されない場合、Snowpipeはファイルをインジェストしません。

このトピックの内容:

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

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>/') ]

条件:

  • 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/');

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

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

    DESC STORAGE INTEGRATION <integration_name>;

    条件:

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

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時間待ってから、もう一度検索することをお勧めします。

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

    Add role assignment in 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>

条件:

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

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

次のコマンドを実行して、データファイルを保存するストレージアカウントを作成します。このアカウントは、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

条件:

  • 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

条件:

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

条件:

参照用のストレージアカウントとキュー 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 \
--advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose

  • 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

条件:

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

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

条件:

例:

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アクセスの許可

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

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

    DESC NOTIFICATION INTEGRATION <integration_name>;

    条件:

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

    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コンテナーを参照する外部ステージを作成します。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');

条件:

重要

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

  • COPY INTO <テーブル> ステートメントの保存場所の参照が、アカウントにある既存のパイプの参照と重複していないことを確認します。そうしないと、複数のパイプが、同じデータファイルのセットをターゲットテーブルにロードする可能性があります。たとえば、この状況は、複数のパイプ定義が <ストレージの場所>/path1/ や <ストレージの場所>/path1/path2/ など、細分性のレベルが異なる同じストレージの場所を参照している場合に発生する可能性があります。この例では、ファイルが <ストレージの場所>/path1/path2/ でステージングされている場合は、両方のパイプがファイルのコピーをロードします。

    SHOW PIPES を実行するか、Account Usageの PIPES ビューまたはInformation Schemaの PIPES ビューのいずれかをクエリして、アカウントにあるパイプの定義すべての COPY INTO <テーブル> ステートメントを表示します。

自動インジェストを使用した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":<値>}

出力値の説明については、 SQL 関数の参照トピックをご参照ください。

⇧
最上部に戻る