次の方法で共有

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

  • [アーティクル]

適用対象: ✅Microsoft Fabric✅Azure データ エクスプローラー

この記事では、定期的に実行されるクエリを使用して、Kusto から外部テーブルにデータを連続エクスポートする方法について説明します。 結果は外部テーブルに格納されます。このテーブルでは、Azure Blob Storage、エクスポートされたデータのスキーマなど、変換先が定義されます。 このプロセスでは、一部の例外を除き、すべてのレコードが「厳密に 1 回だけ」エクスポート されます。

既定では、連続エクスポートは分散モードで実行され、すべてのノードが同時にエクスポートされるため、成果物の数はノードの数によって異なります。 連続エクスポートは、待機時間の短いストリーミング データ用に設計されていません。

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

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

アクセス許可

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

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

  • [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 - databsae での連続エクスポートの最大遅延 (分単位)。 これは、データベース内のすべての連続エクスポート ジョブの現在から最小 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")

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

Row Level Security ポリシーを持つテーブルを参照するクエリを使用して連続エクスポート ジョブを作成するには次の操作を行う必要があります。

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

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

重要

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

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

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

  1. 「 Azure Storage での差分外部テーブルの作成と変更」の説明に従って、外部デルタ テーブルを作成。

    Note

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

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

    重要

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

制限事項

全般:

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

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

データベース間およびイベントハウス間:

  • 連続エクスポートでは、Eventhouse 間の呼び出しはサポートされません。
  • 連続エクスポートでは、ディメンション テーブルに対してのみデータベース間の呼び出しがサポートされます。 すべてのファクト テーブルはローカル データベースに存在する必要があります。 ファクト テーブルとディメンション テーブルからの Export の詳細についてはを参照してください。

ポリシー:

関連するコンテンツ