継続的データ エクスポートの概要

  • [アーティクル]

この記事では、定期的に実行されるクエリを使用して、Kusto から外部テーブルにデータを連続エクスポートする方法について説明します。 結果は外部テーブルに格納されます。このテーブルでは、Azure Blob Storage、エクスポートされたデータのスキーマなど、変換先が定義されます。 このプロセスでは、一部の例外を除き、すべてのレコードが「厳密に 1 回だけ」エクスポート されます。 連続エクスポートは既定で、すべてのノードが同時にエクスポートされる分散モードで実行されるため、成果物の数はクラスター内のノードの数によって異なります。 継続的エクスポートは、クラスターからの低待機時間のストリーミング データ用に設計されていません。

連続データ エクスポートを有効にするには、外部テーブルを作成し、外部テーブルを指す連続エクスポート定義を作成します。

場合によっては、マネージド ID を使用して連続エクスポート ジョブを正常に構成する必要があります。 詳細については、「 マネージド ID を使用して連続エクスポート ジョブを実行する」を参照してください。

アクセス許可

すべての連続エクスポート コマンドには、少なくともデータベース 管理のアクセス許可が必要です。

連続エクスポートのガイドライン

  • [Output Schema](出力スキーマ):

    • エクスポート クエリの出力スキーマは、エクスポートする外部テーブルのスキーマと一致している必要があります。

  • 頻度:

    • 連続エクスポートは、intervalBetweenRuns プロパティで構成された期間に従って実行されます。 この間隔は、ユーザーが許容できる待ち時間に応じて、少なくとも数分に設定することをおすすめします。 インジェスト率が高い場合、時間間隔は 1 分程度にすることができます。

      Note

      intervalBetweenRuns はあくまで推奨事項であり、正確であるという保証はありません。 連続エクスポートは、集計を定期的にエクスポートする場合には適していません。 たとえば、構成を intervalBetweenRuns=1h とし、集計を1 時間に 1 回 (T | summarize by bin(Timestamp, 1h)) としても、連続エクスポートがその時間に正確に実行されるとは限らないので、期待したとおりには機能しません。 したがって、1 時間ごとのビンで、エクスポートされたデータに複数のエントリを受信することになります。

  • ファイル数:

    • 連続エクスポート イテレーションごとにエクスポートされるファイルの数は、外部テーブルのパーティション方法によって異なります。 詳細については、外部テーブルへのエクスポート コマンドに関する記事を参照してください。 連続エクスポートの各イテレーションでは、常に新しいファイルに書き込まれ、既存のファイルに追加されることはありません。 その結果、エクスポートされるファイルの数も、連続エクスポートを実行する頻度によって異なります。 周波数 パラメーターは intervalBetweenRuns です。

  • 外部テーブル ストレージ アカウント:

    • 最適なパフォーマンスを得るには、クラスターとストレージ アカウントを同じ Azure リージョンに併置する必要があります。
    • 連続エクスポートは、クラスター内のすべてのノードが同時にエクスポートされるように、分散された方法で動作します。 大規模なクラスターでは、エクスポートされたデータ ボリュームが大きい場合、ストレージの調整につながる可能性があります。 外部テーブルに対して、複数のストレージ アカウントを構成する方法をお勧めします。 詳細については、エクスポート コマンド中のストレージ エラーに関するページを参照してください。

1 回だけのエクスポート

エクスポートが「1 回だけ」実行されることを保証するために、連続エクスポートではデータベース カーソルが使用されます。 連続エクスポート クエリにはタイムスタンプ フィルターを含めないようにしてください。データベース カーソル機構が機能するので、レコードが 2 回以上処理されることはありません。 クエリにタイムスタンプ フィルターを追加すると、エクスポートされたデータからデータが欠落する可能性があります。

IngestionTime ポリシーは、エクスポートで「1 回だけ」処理する必要があるクエリで、参照されているテーブルすべてで有効にする必要があります。 このポリシーは、新しく作成されたテーブルすべてで既定で有効になっています。

エクスポートが「1 回だけ」実行されることは、エクスポートされた成果物の表示コマンドで報告されたファイルに対してのみ保証されます。 連続エクスポートでは、各レコードが外部テーブルに 1 回だけ書き込まれる保証はありません。 エクスポートの開始後にエラーが発生し、一部の成果物が既に外部テーブルに書き込まれている場合、外部テーブルに重複が含まれている可能性があります。 書き込み操作が完了前に中止された場合、外部テーブルに破損したファイルが含まれている可能性があります。 このような場合、成果物が外部テーブルから削除されることはありませんが、エクスポートされた成果物の表示コマンド では報告されません。 show exported artifacts command を使用してエクスポートされたファイルを使用することで、重複も破損も生じないことが保証されます。

ファクト テーブルとディメンション テーブルからのエクスポート

既定では、エクスポート クエリで参照されるすべてのテーブルがファクト テーブルと見なされます。 そのため、データベース カーソルにスコープが設定されます。 構文では、スコープが設定されているテーブル (ファクト) とスコープが設定されていないテーブル (ディメンション) を明示的に宣言します。 詳細については、 create コマンド に関する記事の over パラメーターを参照してください。

エクスポート クエリには、前のエクスポート実行以降に結合されたレコードだけが含まれます。 エクスポート クエリには 、ディメンション テーブル のすべてのレコードがすべてのエクスポート クエリに含まれるディメンション テーブルが含まれる場合があります。 連続エクスポートでファクト テーブルとディメンション テーブルの間で結合を使用する場合は、ファクト テーブル内のレコードは 1 回だけ処理されることにご注意ください。 ディメンション テーブル内のレコードが、一部のキーで欠落している状態でエクスポートが実行されると、それぞれのキーのレコードが欠落するか、エクスポートされたファイルでディメンション列に null 値が含まれることになります。 欠落レコードが返却されるか、または null 値レコードが返却されるかは、クエリで使用される結合が、内部結合か外部結合かによります。 連続エクスポート定義の forcedLatency プロパティは、レコードの照合にファクト テーブルとディメンション テーブルが同時に取り込まれた場合に役立ちます。

Note

ディメンション テーブルのみを連続エクスポートすることはできません。 エクスポート クエリには、少なくとも 1 つのファクト テーブルを含める必要があります。

連続エクスポートを監視する

次のエクスポート メトリックを使用して、連続エクスポート ジョブの正常性をモニタリングします。

  • Continuous export max lateness - クラスター内の連続エクスポートの遅さの最大値 (分)。 これは、クラスター内のすべての連続エクスポート ジョブの最小 ExportedTo 時間です。 詳細については、 .show continuous export コマンドを参照してください。
  • Continuous export result - 各連続エクスポート実行の成功/失敗の結果。 このメトリックは、連続エクスポート名で分割できます。

連続エクスポート ジョブの特定のエラーを確認するには、.show continuous export failures コマンドを使用します。

警告

永続的なエラーが原因で連続エクスポートが 7 日間以上失敗した場合、エクスポートはシステムによって自動的に無効になります。 永続的なエラーには、外部テーブルが見つからない、連続エクスポート クエリのスキーマと外部テーブル スキーマの間の不一致、ストレージ アカウントにアクセスできないなどのエラーが含まれます。 エラーが修正された後、.enable continuous export コマンドを使用して連続エクスポートを再び有効にできます。

リソース消費

  • クラスターへの連続エクスポートの影響は、連続エクスポートが実行されているクエリによって異なります。 CPU やメモリなどのほとんどのリソースは、クエリを実行することで消費されます。
  • 同時に実行できるエクスポート操作の数は、クラスターのデータ エクスポート容量によって制限されます。 詳細については、「 管理コマンドの調整」を参照してください。 クラスターに、すべての連続エクスポートを処理するための十分な容量がない場合は、一部で遅延が発生します。
  • show commands-and-queries コマンド を使用すると、リソースの消費量を見積もることができます。
    • 連続エクスポートに関連付けられているコマンドとクエリを表示するには、| where ClientActivityId startswith "RunContinuousExports" をフィルター処理します。

履歴データのエクスポート

連続エクスポートでは、作成時点からのみデータのエクスポートが開始されます。 その時間より前に取り込まれたレコードは、連続エクスポート コマンド以外のコマンドを使用して個別にエクスポートする必要があります。 履歴データが大きすぎて、1 つのエクスポート コマンドでエクスポートできない場合があります。 必要に応じて、クエリをいくつかの小さなバッチにパーティション化してください。

連続エクスポートによってエクスポートされたデータとの重複を回避するには、連続エクスポートの表示コマンドによって返される StartCursor を使用し、where cursor_before_or_at がカーソル値であるレコードのみをエクスポートします。 次に例を示します。

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

続けて次を入力します。

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

行レベルのセキュリティを使用したテーブルからの連続エクスポート

行レベル セキュリティ ポリシーを使用してテーブルを参照するクエリを使用して連続エクスポート ジョブを作成するには、次の操作を行う必要があります。

差分テーブルへの連続エクスポート - プレビュー

デルタ テーブルへの連続エクスポートは現在プレビュー段階です。

重要

差分テーブルのパーティション分割は、連続データ エクスポートではサポートされていません。

デルタ プロトコル ライターのバージョンが 1 より大きい場合、Kusto は既存のデルタ テーブルに書き込まれません。

差分テーブルへの連続エクスポートを定義するには、次の手順を実行します。

  1. 「Azure Storage でデルタ外部テーブルを作成および変更する」の説明に従って 、外部デルタ テーブルを作成します。

    注意

    スキーマが指定されていない場合、ターゲット ストレージ コンテナーに既にデルタ テーブルが定義されている場合、Kusto によって自動的に推論が試みられます。
    デルタ テーブルのパーティション分割はサポートされていません。

  2. 「連続エクスポートの 作成または変更」で説明されているコマンドを使用して、このテーブルへの連続エクスポートを定義します。

    重要

    差分テーブルのスキーマは、連続エクスポート クエリと同期している必要があります。 基になるデルタ テーブルが変更されると、エクスポートが予期しない動作で失敗し始める可能性があります。

制限事項

全般:

  • ターゲット テーブルCSVTSVJSONでは、および Parquetの形式を使用できます。
  • マ テリアライズド ビューは更新される可能性があるため、連続エクスポートは具体化されたビューに対して機能するようには設計されていませんが、ストレージにエクスポートされるデータは常に追加のみであり、更新されません。
  • 連続エクスポートには書き込み操作が必要となるため、読み取り専用のフォロワー データベースでは連続エクスポートを作成できません。
  • ソース テーブル内のレコードは、 更新ポリシーを使用してテーブルに直接取り込むか、 クエリ コマンドから取り込む必要があります。 .move エクステントまたは .rename テーブルを使用してレコードをテーブルに移動した場合、連続エクスポートでこれらのレコードが処理されない可能性があります。 データベース カーソルに関するページで説明されている制限事項を参照してください。
  • 連続エクスポートで使用される成果物が Event Grid 通知をトリガーすることを目的としている場合は、Event Grid ドキュメントの既知の問題に関するセクションを参照してください。

クロスデータベースとクロスクラスター:

  • 継続的エクスポートでは、クラスター間の呼び出しはサポートされていません。
  • 連続エクスポートでは、ディメンション テーブルに対してのみデータベース間の呼び出しがサポートされます。 すべてのファクト テーブルは、ローカル データベースに存在する必要があります。 詳細については、「 ファクト テーブルとディメンション テーブルからエクスポートする」を参照してください。
  • 連続エクスポートにデータベース間呼び出しが含まれている場合は、 マネージド ID で構成する必要があります。

ポリシー:

関連コンテンツ