注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ストリーミングパイプラインを作成する際に、ストリーミングの失敗に遭遇することがあります。このページでは、失敗したストリームのデバッグに役立つワークフローを提案し、ストリームがなぜ失敗したのかを理解するための Foundry で利用可能なツールについて説明します。
失敗は失敗の種類に分類でき、それぞれの失敗の種類が異なる根本的な原因を示すことができます。以下に、最も一般的な失敗の種類とそれらが発生する理由をいくつか示します。
すぐに失敗するストリームは、通常、ユーザーが作成したロジックに問題があることが多いです。例えば、失敗は無効なキャスト、パースの例外、またはストリーミングクラスタが成功裏に起動できない他の問題から生じる可能性があります。
以前は成功していたストリームが今では失敗する場合は、ロジックと上流のストリームの変更を検査して、潜在的な問題を見つけます。
これらの問題の根本原因を特定するには、以下の ストリーミングクラスタのログを確認する ワークフローに示されている手順に従います。
以前は成功していたが再起動後に再稼働するストリームの失敗は、通常、ネットワークのダウンによるインフラ問題を示します。ダウンは、Foundry インスタンスが稼働しているクラウドプロバイダ(例えば、AWS、Azure、または GCP のダウン)によってしばしば引き起こされます。ストリームにスケジュールを適用すると、Foundry は自動的にストリームを再稼働させ、中断したところから処理を続行します。
以前は成功していたが、ロジックの変更がないにもかかわらず、連続して失敗するストリームの失敗は、通常、最も特定が難しいものです。しかし、一般的には以下の二つの要素のいずれかによって引き起こされます: 新しい入力データがストリームの進行を妨げている(例えば、無効な型、壊れたデータなど)、または持続的なインフラ問題が存在している(AWS のダウンなど)。
エラーがパイプラインのロジックによって引き起こされているかどうかを確認するには、以下の ストリーミングクラスタのログを確認する ワークフローに示されている手順に従います。
以下では、一般的なストリーミング問題を解決するために使用できるワークフローをいくつか紹介します。これらのチェックは特定の順序で行う必要はありません。
ストリームログを取得する の手順に従い、ログを検索して例外、エラー、または "throwable" を探します。これらのログは通常、"ERROR"、"throwable"、または "Exception" といったキーワードを通じて潜在的な基礎となる問題の説明を提供します。
パイプラインロジックの変更は、ユーザーが作成したコードのバグにより、しばしばブレークを引き起こします。通常、前のステップで得られたログの例外は、問題を引き起こしている特定のコードを指し示します。その場合、問題が解決するかどうかを確認するために、変更を元に戻すことができます。
場合によっては、ストリーミングパイプラインのロジックが予期せぬデータに遭遇すると例外をスローすることがあります。この挙動の例として、パイプラインが二つの行を互いに割り、除数が 0
または null
の値を返す場合があります。入力ストリームの最後のレコードを確認し、データがストリーミングパイプラインに問題を引き起こす可能性のある方法で変更されているかどうかを確認します。変更されたデータを見つけた場合は、フィルターを追加するか、データをクリーニングまたは削除するロジックを考慮してください。
Foundry はストリームが失敗した際に一般的な例外を検出し、それらをストリーム詳細ページに表示します。詳細を確認し、エラーが表示されるかどうかを確認します。
ストリームログで詳細ページよりも多くのエラー情報を見つけることがあります。ストリームの失敗に関する情報を得るために、両方の場所を確認することをお勧めします。
ストリーム中に失敗が発生し、ビルドのログを参照して原因を特定する必要があるかもしれません。ビルドログは、ストリームの失敗の種類を判断するのに最適な場所です。
ストリーミングジョブのログを取得するには、まず データセットプレビュー 内のストリーム詳細ページに移動します。
次に、確認したいジョブを見つけ、ログをダウンロードする をクリックします。
最初にダウンロードしたいログの行を選択します。
原因: com.palantir.logsafe.exceptions.SafeIllegalStateException: 開始トランザクションridは現在のビューに含まれていません。
このエラーは、通常、入力データセットの新しいスナップショットがストリーミングで実行されることによって引き起こされます。
ストリーミングは、レコードが受信されるとすぐにレコードを下流に送信します。これにより、レコードは元に戻すことができません。新しいスナップショットが作成されると、ストリーミングジョブは以前のトランザクションを無視し、新しいトランザクションのみを使用します。新しいスナップショットを優先して古いレコードを破棄するには、手動でリプレイを実行してください。
この問題は、ストリームをリプレイする新しいパイプラインのデプロイを実行することで解決します。これは、パイプラインのデプロイウィザードで デプロイ時にリプレイ オプションを選択することにより実行できます。