Snowpipeのトラブルシューティング¶
このトピックでは、Snowpipeを使用してデータをロードする際の問題をトラブルシューティングするための体系的なアプローチについて説明します。
このトピックの内容：
Snowpipeの問題をトラブルシューティングする手順は、データファイルの読み込みに使用されるワークフローによって異なります。
クラウドストレージイベント通知を使用したデータの自動ロード¶
エラー通知¶
プレビュー機能 --- オープン
すべてのアカウントで利用可能。
Snowpipeのエラー通知を構成します。読み込み中にSnowpipeでエラーが発生すると、この機能は設定されたクラウドメッセージングサービスに通知をプッシュし、データファイルの分析を可能にします。詳細については、 Snowpipeのエラー通知 をご参照ください。
一般的なトラブルシューティングステップ¶
次のステップを実行して、ファイルの自動ロードを妨げるほとんどの問題の原因を特定します。
ステップ1: パイプステータスを確認する¶
パイプの現在のステータスを取得します。結果は JSON 形式で表示されます。詳細については、 SYSTEM$PIPE_STATUS をご参照ください。
以下の値を確認します。
lastReceivedMessageTimestampメッセージキューから受信した、最後のイベントメッセージのタイムスタンプを指定します。たとえば、メッセージに関連付けられたパスがパイプ定義のパスと一致しない場合、このメッセージは特定のパイプに適用されない場合があります。また、作成されたデータオブジェクトによってトリガーされたメッセージのみが自動インジェストパイプによって消費されます。
タイムスタンプが予想よりも早い場合、サービス構成か（つまり、Amazon SQS、Amazon SNS、またはAzure Event Grid）、サービス自体のいずれかに問題があることを示している場合があります。フィールドが空の場合、サービス構成設定を確認します。フィールドにタイムスタンプが含まれているが、予想よりも早い場合、サービス構成で設定が変更されたかどうかを確認します。
lastForwardedMessageTimestampパイプに転送された一致するパスを持つ、最後の「オブジェクトの作成」イベントメッセージのタイムスタンプを指定します。
イベントメッセージがメッセージキューから受信されてもパイプに転送されない場合、新しいデータファイルが作成されるBLOBストレージパスと、Snowflakeステージおよびパイプ定義で指定された結合パスとの間に不一致がある可能性があります。ステージおよびパイプ定義で指定されているパスを確認します。パイプ定義で指定されたパスは、ステージ定義のすべてのパスに追加されます。
ステップ2。テーブルの COPY 履歴を表示する¶
イベントメッセージを受信して転送する場合は、ターゲットテーブルのロードアクティビティ履歴をクエリします。詳細については、 COPY_HISTORY をご参照ください。
STATUS 列は、特定のファイルセットがロードされたか、部分的にロードされたか、ロードに失敗したかを示します。 FIRST_ERROR_MESSAGE 列は、試行が部分的にロードされたか失敗した場合の理由を示します。
ファイルのセットに複数の問題がある場合、 FIRST_ERROR_MESSAGE 列は最初に発生したエラーのみを示します。ファイル内のすべてのエラーを表示するには、 VALIDATION_MODE コピーオプションを RETURN_ALL_ERRORS に設定して COPY INTO <テーブル> ステートメントを実行します。VALIDATION_MODE コピーオプションは、ロードされるデータを検証し、指定された検証オプションに基づいて結果を返すように COPY ステートメントに指示します。このコピーオプションが指定されている場合、データはロードされません。ステートメントで、Snowpipeを使用してロードしようとしたファイルのセットを参照します。コピーオプションの詳細については、 COPY INTO <テーブル> をご参照ください。
COPY_HISTORY 出力に予想されるファイルのセットが含まれていない場合は、以前の期間をクエリします。ファイルが以前のファイルの複製であった場合は、元のファイルをロードしようとしたときに、ロード履歴にアクティビティが記録されていた可能性があります。
ステップ3：データファイルを検証する¶
ロード操作でデータファイルのエラーが発生した場合、 COPY_HISTORY テーブル関数は各ファイルで最初に発生したエラーを説明します。データファイルを検証するには、 VALIDATE_PIPE_LOAD 関数をクエリします。
Microsoft Azure Data Lake Storage Gen2ストレージで生成されたファイルが読み込まれていません¶
現在、一部のサードパーティクライアントは ADLS Gen 2 REST API にある FlushWithClose を呼び出しません。このステップは、Snowpipeにファイルをロードするように通知するイベントをトリガーするために必要です。Snowpipeをトリガーしてこれらのファイルをロードするために、手動による REST API の呼び出しを試みてください。
close 引数を使用した Flush メソッドの詳細については、https://docs.microsoft.com/en-us/dotnet/api/azure.storage.files.datalake.datalakefileclient.flushをご参照ください。 close パラメーターの負荷に関する追加の REST API 参照情報については、https://docs.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/updateをご参照ください。
Amazon SNS トピックのサブスクリプションが削除された後に、Snowpipeによるファイルの読み込みが停止する¶
ユーザーが特定のAmazon Simple Notification Service（SNS）トピックを参照するパイプオブジェクトを初めて作成するとき、SnowflakeはSnowflakeが所有するAmazon Simple Queue Service（SQS）キューをトピックにサブスクライブします。AWS 管理者が SNS トピックへの SQS サブスクリプションを削除すると、トピックを参照するパイプはAmazon S3からイベントメッセージを受信しなくなります。
問題を解決するには、
SNS トピックサブスクリプションが削除されてから72時間待ちます。
72時間後、Amazon SNS は削除されたサブスクリプションをクリアします。詳細については、 Amazon SNS ドキュメント をご参照ください。
トピックを参照するパイプを再作成します（CREATE OR REPLACE PIPE を使用）。パイプ定義で同じ SNS トピックを参照します。手順については、 ステップ3：自動インジェストを有効にしたパイプを作成する をご参照ください。
SNS トピックサブスクリプションの削除前に機能していたすべてのパイプが、S3からのイベントメッセージの受信を再開するはずです。
72時間の遅延を回避するために、別の名前で SNS トピックを作成できます。CREATE OR REPLACE PIPE コマンドを使用してトピックを参照するパイプを再作成し、新しいトピック名を指定します。
Google Cloud Storageからのロードの遅延、またはファイルの欠落¶
Pub/Subメッセージを使用して、Google Cloud Storage（GCS）からの自動データロードが構成されている場合は、単一のステージングされたファイルのイベントメッセージのみを読み取ることができます。または、 GCS からのデータのロードを数分から1日以上遅らせることもできます。一般的に、どちらの問題も、 GCS 管理者がSnowflakeサービスアカウントに Monitoring Viewer ロールを付与していない場合に発生します。
手順については、 クラウドストレージへの安全なアクセスの構成 にある「ステップ2: Pub/SubサブスクリプションにSnowflakeアクセスを許可する」をご参照ください。
Snowpipe RESTエンドポイントの呼び出しによるデータのロード¶
エラー通知¶
Snowpipeエラー通知のプレビューサポートは、Amazon Web Services（AWS）でホストされているSnowflakeアカウントで利用できます。データファイルの分析を可能にするデータロードトリガー通知中に発生したエラー。詳細については、 Snowpipeのエラー通知 をご参照ください。
一般的なトラブルシューティングステップ¶
次のステップを実行して、ファイルのロードを妨げるほとんどの問題の原因を特定します。
ステップ1: 認証の問題を確認する¶
Snowpipe REST エンドポイントは、 JSON Webトークン（JWT）でキーペアの認証を使用します。
Python/Javaインジェスト SDKs が JWT を生成します。REST API を直接呼び出す場合は、それらを生成する必要があります。リクエストで JWT トークンが提供されない場合、REST エンドポイントからエラー 400 が返されます。無効なトークンが提供されると、次のようなエラーが返されます。
snowflake.ingest.error.IngestResponseError: Http Error: 401, Vender Code: 390144, Message: JWT token is invalid.
ステップ2。テーブルの COPY 履歴を表示する¶
Snowpipeを使用して試行されたデータロードを含む、テーブルのロードアクティビティ履歴をクエリします。詳細については、 COPY_HISTORY をご参照ください。 STATUS 列は、特定のファイルセットがロードされたか、部分的にロードされたか、ロードに失敗したかを示します。 FIRST_ERROR_MESSAGE 列は、試行が部分的にロードされたか失敗した場合の理由を示します。
ファイルのセットに複数の問題がある場合、 FIRST_ERROR_MESSAGE 列は最初に発生したエラーのみを示します。ファイル内のすべてのエラーを表示するには、 VALIDATION_MODE コピーオプションを RETURN_ALL_ERRORS に設定して COPY INTO <テーブル> ステートメントを実行します。VALIDATION_MODE コピーオプションは、ロードされるデータを検証し、指定された検証オプションに基づいて結果を返すように COPY ステートメントに指示します。このコピーオプションが指定されている場合、データはロードされません。ステートメントで、Snowpipeを使用してロードしようとしたファイルのセットを参照します。コピーオプションの詳細については、 COPY INTO <テーブル> をご参照ください。
ステップ3：パイプステータスを確認する¶
COPY_HISTORY テーブル関数が調査中のデータロードに対して0の結果を返す場合、パイプの現在の状態を取得します。結果は JSON 形式で表示されます。詳細については、 SYSTEM$PIPE_STATUS をご参照ください。
executionState キーは、パイプの実行状態を識別します。たとえば、 PAUSED はパイプが現在一時停止していることを示します。パイプの所有者は、 ALTER PIPE を使用してパイプの実行を再開できます。
executionState 値がパイプの開始に関する問題を示している場合は、 error キーで詳細を確認してください。
ステップ4：データファイルを検証する¶
ロード操作でデータファイルのエラーが発生した場合、 COPY_HISTORY テーブル関数は各ファイルで最初に発生したエラーを説明します。データファイルを検証するには、 VALIDATE_PIPE_LOAD 関数をクエリします。
その他の問題¶
ロードされていないファイルのセット¶
ロードの COPY_HISTORY 記録がありません¶
パイプ内の COPY INTO <テーブル> ステートメントに PATTERN 句が含まれているかどうかを確認してください。その場合は、 PATTERN 値として指定された正規表現が、ロードするすべてのステージングされたファイルを除外しているかどうかを確認します。
PATTERN 値を変更するには、 CREATE OR REPLACE PIPE 構文を使用してパイプを再作成する必要があります。
次をご参照ください。
COPY_HISTORY 記録は、ファイルのアンロードされたサブセットを示しています¶
COPY_HISTORY 関数の出力が、ファイルのサブセットがロードされていないことを示している場合は、パイプの「更新」を試みます。
この状況は、次のいずれかの状況で発生する可能性があります。
以前、外部ステージは、 COPY INTO テーブル コマンドを使用してデータを一括ロードしていた。
REST API:
外部イベントドリブン機能を使用して REST APIsを呼び出し、データファイルのバックログは、イベントが構成される前に外部ステージにすでに存在していました。
自動取り込み：
イベント通知が構成される前の外部ステージには、データファイルのバックログがすでに存在していました。
イベント通知の失敗により、一連のファイルがキューに入れられませんでした。
構成されたパイプを使用して外部ステージにデータファイルをロードするには、 ALTER PIPE ... REFRESH ステートメントを実行します。
ターゲットテーブルのデータが重複しています¶
SHOW PIPES を実行するか、Account Usageの PIPES ビューまたはInformation Schemaの PIPES ビューのいずれかをクエリして、アカウントにあるすべてのパイプの定義にある COPY INTO <テーブル> ステートメントを比較します。複数のパイプが、 COPY INTO <テーブル> ステートメントで同じクラウドストレージの場所を参照している場合は、ディレクトリパスが重複していないことを確認してください。そうしないと、複数のパイプが、同じデータファイルのセットをターゲットテーブルにロードする可能性があります。たとえば、この状況は、複数のパイプ定義が <ストレージの場所>/path1/ や <ストレージの場所>/path1/path2/ など、細分性のレベルが異なる同じストレージの場所を参照している場合に発生する可能性があります。この例では、ファイルが <ストレージの場所>/path1/path2/ でステージングされている場合は、両方のパイプがファイルのコピーをロードします。
変更済みデータをリロードできません、変更済みデータが意図せずにロードされました¶
Snowflakeはファイルロードメタデータを使用して、テーブル内の同じファイル（およびデータの複製）の再ロードを防ぎます。Snowpipeは、後で変更された（つまり、異なるeTagを持つ）場合でも、同じ名前のファイルをロードしません。
ファイルロードメタデータは、テーブルではなく、 パイプオブジェクト に関連付けられています。その結果：
既にロードされたファイルと同じ名前のステージングされたファイルは、新しい行の追加や、ファイルのエラーの修正などの変更があっても無視されます。
TRUNCATE TABLE コマンドを使用してテーブルを切り捨てても、メタデータをロードしているSnowpipeファイルは削除 されません 。
ただし、パイプは 14日間 のロード履歴メタデータのみを保持します。したがって、次のようになります。
- 14日以内に変更され、再度ステージングされたファイル
Snowpipeは、再度ステージングされた変更済みファイルを無視します。現在、同じデータファイルをリロードするには、
CREATE OR REPLACE PIPE構文を使用してパイプオブジェクトを再作成する必要があります。次の例では、 Snowpipe REST APIを使用したデータロードの準備 のステップ1の例に基づいて
mypipeパイプを再作成します。create or replace pipe mypipe as copy into mytable from @mystage;
- 14日後に変更され、再びステージングされたファイル
Snowpipeはデータを再度ロードするため、ターゲットテーブルにレコードが重複する可能性があります。
さらに、アクティブなSnowpipeロードと同じバケット/コンテナ、パス、およびターゲットテーブルを参照する COPY INTO <テーブル> ステートメントが実行された場合、ターゲットレコードに重複レコードをロードできます。COPY コマンドとSnowpipeのロード履歴は、Snowflakeに個別に保存されます。履歴ステージングデータを読み込んだ後、パイプ構成を使用して手動でデータを読み込む必要がある場合は、 ALTER PIPE ... REFRESH ステートメントを実行します。詳細については、このトピック内の ロードされていないファイルのセット をご参照ください。
COPY_HISTORY ビューの LOAD_TIME 値より前の CURRENT_TIMESTAMP を使用して挿入されたロード時間¶
テーブル設計者は、記録がテーブルにロードされるときに、現在のタイムスタンプをデフォルト値として挿入するタイムスタンプ列を追加できます。目的は、各記録がテーブルにロードされた時間をキャプチャすることです。ただし、タイムスタンプは、 COPY_HISTORY 関数 （Information Schema）または COPY_HISTORY ビュー （Account Usage）によって返される LOAD_TIME 列の値よりも前です。その理由は、 CURRENT_TIMESTAMP は、記録がテーブルに挿入されたとき（つまり、ロード操作のトランザクションがコミットされたとき）ではなく、クラウドサービスでロード操作がコンパイルされたときに評価されるためです。
注釈
現在、Snowpipeの copy_statement で次の関数を使用することはお勧めしません。
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP
GETDATE
LOCALTIME
LOCALTIMESTAMP
SYSDATE
SYSTIMESTAMP
これらの関数を使用して挿入された時間値は、 COPY_HISTORY 関数 または COPY_HISTORY ビュー によって返される LOAD_TIME 値よりも数時間早くなる可能性があるという既知の問題があります。
Error: Integration {0} associated with the stage {1} cannot be found¶
003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.
このエラーは、外部ステージと、ステージにリンクされているストレージ統合との関連付けが壊れている場合に発生する可能性があります。これは、ストレージ統合オブジェクトが再作成されたときに発生します（ CREATE OR REPLACE STORAGE INTEGRATION を使用）。ステージは、ストレージ統合の名前ではなく、非表示の ID を使用してストレージ統合にリンクします。バックグラウンドでは、 CREATE OR REPLACE 構文はオブジェクトをドロップし、別の非表示の IDでオブジェクトを再作成します。
1つ以上のステージにリンクされた後にストレージ統合を再作成する必要がある場合は、 ALTER STAGE stage_name SET STORAGE_INTEGRATION = storage_integration_name を実行して、各ステージとストレージ統合間の関連付けを再確立する必要があります。ここで、
stage_nameは、ステージの名前です。storage_integration_nameは、ストレージ統合の名前です。