Azure Stream Analytics のクエリのトラブルシューティング

この記事では、Azure Stream Analytics クエリの開発に関する一般的な問題、クエリの問題のトラブルシューティングの方法、および問題を修正する方法について説明します。 多くのトラブルシューティング手順では、Stream Analytics ジョブのリソース ログを有効にする必要があります。 リソース ログが有効になっていない場合は、「リソース ログを使用したAzure Stream Analyticsのトラブルシューティング」を参照してください。

クエリは期待される出力を生み出していません

  1. ローカルでテストしてエラーを調査します。

    • Azureポータルのクエリタブで「Test」を選択してください。 ダウンロードしたサンプル データを使用してクエリをテストします。 すべてのエラーを調査し、修正を試みます。
    • また、Visual StudioやVisual Studio CodeのAzure Stream Analyticsツールを使ってローカルでクエリをテストすることもできます。
  2. Visual Studio Code の Azure Stream Analytics ツールで、ジョブ ダイアグラムを使用して段階を追ってローカルでクエリをデバッグします。 ジョブダイアグラムは、Azure Event HubsやAzure IoT Hubなどの入力ソースから、複数のクエリステップを経て最終的に出力のシンクへとデータがどのように流れていくかを示しています。 スクリプトは各クエリステップをWITH文を使って定義した一時的な結果セットにマッピングします。 各中間結果セットのデータと指標を確認し、問題の原因を特定してください。

    クエリステップのプレビュー結果を示すVisual Studio Codeのジョブ図のスクリーンショットです。

  3. Timestamp By を使用する場合は、イベントのタイムスタンプがジョブの開始時刻より後であることを確認します。

  4. よくある次のような問題を解消する。

    • クエリ内の WHERE 節がすべてのイベントをフィルタリングしたため、クエリは出力を生み出しません。
    • CAST 関数が失敗したため、ジョブが失敗する。 型キャスト エラーを回避するには、代わりに TRY_CAST を使用します。
    • ウィンドウ関数を使用する場合は、クエリの出力を確認するにはウィンドウ全体の期間が経過するまで待つ必要があります。
    • イベントのタイムスタンプはジョブ開始時間より先に設定されるため、ジョブはイベントをドロップします。
    • JOIN 条件が一致しない。 一致がなければ、クエリは出力を生み出しません。
  5. イベントの順序付けポリシーは、期待通りに設定していることを確認してください。 [設定] に移動し、[イベント順序] を選択します。 テストボタンはクエリのテスト時にポリシーを適用しません。 この結果は、ブラウザ内でテストするのと本番環境でジョブを実行することの違いの一つです。

  6. アクティビティとリソース ログを使用したデバッグ:

クエリを段階的にデバッグする

リアルタイムデータ処理では、クエリの途中でデータがどのような状態かを知ることが役立ちます。 中間データを表示するには、Visual Studioのジョブダイアグラムをご利用ください。 Visual Studioがない場合は、中間データを出力するために追加の手順を踏むことができます。

Azure Stream Analyticsジョブの入力やステップを複数回読み取れるため、追加のSELECT INTO文を書くことができます。 これにより中間データをストレージに出力し、プログラムのデバッグ時に ウォッチ変数が 行うようにデータの正確性を確認できます。

Azure Stream Analytics ジョブの次のサンプル クエリには、1 つのストリーム入力と 2 つの参照データ入力があり、Azure Table Storage に出力が行われます。 このクエリはイベント ハブと 2 つの参照 BLOB からのデータを結合し、名前とカテゴリの情報を取得します。

SELECT INTOを使ってイベントハブの入力と2つの参照ブロブを結合するStream Analyticsの例クエリのスクリーンショットです。

ジョブは実行中ですが、出力にイベントは生成されません。 ここに示されている モニタリング タイルでは、入力がデータを生成しているのがわかりますが、 どのJOIN ステップがすべてのイベントを落としたのかはわかりません。

Stream Analytics Monitoringタイルのスクリーンショットで、入力イベントが受信されているものの出力イベントは生成されていません。

この場合、中間JOIN結果や入力から読み取ったデータを「ログ化」するために、いくつかの追加のSELECT INTO文を追加できます。

この例では、2つの新しい「一時的出力」を追加しました。どんな洗面台でも構いません。 ここでは例として Azure Storage を使用します。

Stream Analyticsクエリのスクリーンショットで、中間結果をストレージに記録するための追加のSELECT INTO文を追加しました。

クエリは次のように書き換えることができます。

中間のJOIN結果を一時的な出力に出力する書き直されたStream Analyticsクエリのスクリーンショットです。

次に、ジョブをもう一度開始し、数分間そのまま実行させておきます。 次に、Visual Studio Cloud Explorer を使用して temp1temp2 をクエリし、次の表を生成します。

temp1 tableStream Analytics クエリからの中間 JOIN 結果を示すtemp1 テーブルのスクリーンショット。

temp2テーブル temp2テーブルのスクリーンショットで、Stream Analyticsクエリから正しく入力された名前列を示しています。

ご覧の通り、temp1temp2の両方にデータがあり、temp2name列は正しく入力されています。 しかし、出力がまだデータを持っていないため、何か問題があります:

Stream Analyticsクエリでデータが返ってこないoutput1テーブルのスクリーンショット。

データをサンプリングすることで、問題は第二 JOINにあるとほぼ確信できます。 BLOB から参照データをダウンロードして確認できます。

参照データ表のスクリーンショットで、temp2のfrom列とは異なるGUID形式を示しています。

ご覧の通り、この参照データのGUIDのフォーマットは、temp2[from]列のフォーマットとは異なります。 だからこそ、予想通りにデータが output1 に届かなかったのです。

データフォーマットを修正し、参照ブロブにアップロードしてから再度試してください:

GUIDフォーマットを修正して参照ブロブにアップロードした後の参照データテーブルのスクリーンショット。

今度は、出力のデータが想定どおりに書式設定されて入力されます。

Stream Analyticsクエリで予想通りにフォーマットされ、入力された出力テーブルのスクリーンショットです。

リソース使用率が高い

Azure Stream Analytics で並列処理を活用していることを確認します。 入力パーティションの設定や分析クエリ定義の調整を通じて、Stream Analyticsジョブの クエリ並列化を活用 する方法を学びましょう。

リソース使用率が常に 80% を超え、透かしの遅延が増加し、バックログされたイベントの数が増加している場合は、ストリーミング ユニットを増やすことを検討してください。 使用率が高い場合は、最大数に近い割り当てリソースがジョブによって使用されていることを示します。

ヘルプを表示

詳細については、Azure Stream Analytics に関する Microsoft Q&A 質問ページを参照してください。