Azure Data Explorer での取り込みに関するよくある質問

バッチ処理マネージャーでは、取り込みバッチ処理ポリシーの取り込み設定に基づいて取り込みデータをバッファーおよびバッチ処理します。 取り込みバッチ処理ポリシーにより、バッチ作成からの経過時間、累積項目数 (BLOB)、または合計バッチ サイズの 3 つの制限要因のいずれか早く達したものに従ってバッチ制限が設定されます。 既定のバッチ処理設定は 5 分/ 1 GB / 1,000 BLOB です。つまり、インジェスト用のサンプル データをキューに入れると、少なくとも 5 分の遅延が発生します。

キューインジェストは、高いインジェスト スループットのために最適化されており、最もパフォーマンスが高いインジェストの種類です。 これに対し、取り込みのストリーミングは取り込みの短い待機時間用に最適化されています。 キューインジェストとストリーミング インジェストの詳細。

のバッチ処理ポリシーの既定の設定ニーズに合わない場合は、バッチ処理ポリシーのtimeを下げてみてください。 スループットについては、「 最適化」を参照してください。 取り込みをスケールアップするときに設定を更新する必要もあります。 バッチ処理ポリシー設定を変更すると、有効になるまでに最大 5 分かかることがあります。

取り込みの待機時間は、取り込みバッチ処理ポリシー設定、またはデータ バックログの蓄積が原因で発生する可能性があります。 この問題に対処するには、バッチ処理ポリシー設定を調整します。 取り込みプロセスにおける待機時間を監視することができます。

キューに置かれたインジェスト待機時間のメトリックを表示するには、「インジェスト待機時間の監視を参照してください。 メトリック Stage Latency および Discovery Latency は、取り込みプロセスにおける待機時間を示し、待機時間が長い場合に表示されます。

データ バックログ、非効率的なバッチ処理、大量の非圧縮データのバッチ処理、非常に少量のデータの取り込みなどの待機時間の原因となる問題に対処するためにバッチ処理ポリシーの待機時間調整設定について学習できます。

バッチ処理ポリシーのデータ サイズは、非圧縮データに対して設定されます。 圧縮データを取り込む場合、圧縮されていない データ サイズは インジェスト バッチ処理パラメーター、ZIP ファイルメタデータ、圧縮ファイル サイズに対する要素から計算されます。

メトリックを使用したり、詳細なテーブルレベルの監視のために取り込み診断ログを設定および使用したり、詳細な取り込みエラー コードを表示することで取り込みを監視することができます。 追跡する特定のメトリックを選択し、結果を集計する方法を選び、ダッシュボードに表示するメトリック グラフを作成することができます。 メトリックのストリーミングの詳細についてはキューに登録されたインジェストを監視する方法。

ポータルの Azure Monitor の分析情報を使用すると、Azure Data Explorer のパフォーマンスとその方法を理解するのに役立ちます。 分析情報ビューは、Log Analytics ワークスペースにストリーミングできるメトリックと診断ログに基づいています。 .dup-next-ingest コマンドを使用して、次のインジェストをストレージ コンテナーに複製し、インジェストの詳細とメタデータを確認します。

完全なインジェスト プロセスは、インジェストのメトリックと診断ログを使用して監視できます。 取り込みの失敗は、IngestionResult メトリックまたは FailedIngestion 診断ログを使用して監視できます。 .show ingestion failures コマンドは、データ インジェスト管理コマンドに関連付けられたインジェスト エラーを示しており、エラーの監視には推奨されません。 .dup-next-failed-ingest コマンドは、インジェスト ファイルとメタデータをストレージ コンテナーにアップロードすることで、次に失敗したインジェストに関する情報を提供します。 これは、インジェスト フローを確認する場合に役立ちますが、安定した監視にはお勧めしません。

RetryAttemptsExceeded メトリック状態を含むメトリックが何度も表示される場合、繰り返し発生する一時的なエラーの後に取り込みが再試行の制限または期間の制限を超えていることを示します。 このエラーが診断ログに エラー コード General_RetryAttemptsExceeded 詳細 "ストレージにアクセスして BLOB の情報を取得できませんでした" にも表示される場合は、高負荷のストレージ アクセスの問題を示します。 Event Grid の取り込み中に、Azure Data Explorer により、ストレージ アカウントの BLOB の詳細が要求されます。 ストレージ アカウントの負荷が高すぎると、ストレージ アクセスが失敗する可能性があり、インジェストに必要な情報を取得できません。 試行が定義された最大再試行回数を超えた場合、Azure Data Explorer によって、失敗した BLOB の取り込みの試行が停止されます。 負荷の問題を防ぐには、Premium Storage アカウントを使用するか、取り込まれたデータをより多くのストレージ アカウントに分割します。 関連するエラーを検出するには、FailedIngestion 診断ログでエラー コードと、失敗した BLOB のパスを確認します。

大量の履歴データを効率的に取り込むには、LightIngest を使用します。 詳細については、最も 履歴データを参照してください。 多くの小さなファイルのパフォーマンスを向上させるには、バッチ処理ポリシーを調整し、バッチ処理条件を変更し、待機時間に対処します。 非常に大きなデータ ファイルを取り込む際の取り込みパフォーマンスを向上させるには、クラウドベースのデータ統合サービスである Azure Data Factory (ADF) を使用します。

不適切な形式のデータ(解析できない、大きすぎる、またはスキーマに準拠していない)は、正しく取り込めない可能性があります。 詳細については、「 無効なデータの取り込み」を参照してください。

SDK を介して取り込む場合、取り込みのバッチ処理ポリシー設定を使用してパフォーマンスを向上させることができます。 テーブルまたはデータベースのバッチ処理ポリシーに取り込まれるデータのサイズを 250 MB に減らしてみてください。 改善点があるかどうかを確認します。

Kafka Sink ユーザーはバッチ処理の時間、サイズ、および項目数を調整することで、取り込みバッチ処理ポリシーと連動するようにコネクタを調整する必要があります。