Azure Data Explorer のデータ インジェスト概要

  • [アーティクル]

データ インジェストは、1 つ以上のソースから Azure Data Explorer のテーブルにデータを読み込むプロセスです。 取り込まれたデータは、クエリに使用できるようになります。

次の図は、Azure Data Explorer での作業のエンド ツー エンドのフローと、さまざまな取り込み方法を示したものです。

データ インジェストと管理の概要。

データ インジェストを担当する Azure Data Explorer のデータ管理サービスでは、次のプロセスが実装されます。

Azure Data Explorerは、外部ソースからデータをプルしたり、クライアントと共有されている保留中の Azure キューから要求を読み取ったりできます。 データは、データ管理 サービスによってバッチ処理またはストリーミングされます。 同じデータベースおよびテーブルに送られるバッチ データは、インジェストのスループット向けに最適化されます。 Azure Data Explorer は、初期データを検証し、必要に応じてデータ形式を変換します。 その他のデータ操作には、スキーマの照合と、データの整理、インデックス付け、エンコード、圧縮などがあります。 データは、設定されたアイテム保持ポリシーに従ってストレージに保存されます。 その後、データ管理 サービスによって Azure Data Explorerで取り込み操作がトリガーされ、クエリで使用できるようになります。

サポートされるデータ形式、プロパティ、およびアクセス許可

  • サポートされているデータ形式: Parquet や JSON など、Azure Data Explorerがネイティブに理解して取り込むことができるデータ形式。

  • インジェスト プロパティ: タグ付け、マッピング、作成時間など、データの取り込み方法に影響するプロパティ。

  • アクセス許可: * アクセス許可: コマンドとプロセスで使用されるリソースにアクセスするために必要なアクセス許可。次を含みます。

    • スキーマを変更せずに既存のテーブルにデータを取 り込むには、Database Ingestor のアクセス許可が必要です。
    • 新しいテーブルを作成するには、データベース ユーザーまたはデータベース 管理アクセス許可が必要です。
    • 既存のテーブルのスキーマを変更するには、テーブルを作成したユーザーによって継承された Table 管理、または Database 管理 権限が必要です。

    詳細については、「 Kusto ロールベースのアクセス制御」を参照してください。

バッチ処理とストリーミング インジェスト

  • バッチ処理インジェストでは、データのバッチ処理が行われ、高インジェスト スループットのために最適化されます。 この方法は、推奨される、最もパフォーマンスの高い種類のインジェストです。 データはインジェスト プロパティに従ってバッチ処理されます。 データの小さなバッチはその後マージされ、高速なクエリ結果用に最適化されます。 インジェスト バッチ ポリシーは、データベースまたはテーブルに対して設定できます。 既定では、バッチ処理の最大値は、5 分、1000 項目、または合計サイズ1 GB です。 バッチ インジェスト コマンドのデータ サイズ制限は 6 GB です。

  • ストリーミング インジェスト は、ストリーミング ソースからの継続的なデータ インジェストです。 ストリーミング インジェストを使用すると、テーブルごとに少量のデータ セットに対してほぼリアルタイムの待機時間を実現できます。 データは最初に行ストアに取り込まれ、次に列ストアのエクステントに移動されます。 ストリーミング インジェストは、Azure Data Explorer クライアント ライブラリまたはサポートされているいずれかのデータ パイプラインを使用して行うことができます。

インジェストの方法とツール

Azure Data Explorer では複数のインジェスト方法がサポートされており、それぞれに固有のターゲット シナリオがあります。 これらの方法には、インジェスト ツール、さまざまなサービスへのコネクタとプラグイン、マネージド パイプライン、SDK を使用したプログラムによる取り込み、インジェストへの直接アクセスなどがあります。

データ コネクタの一覧については、「 データ コネクタの概要」を参照してください。

マネージド パイプラインを使用したインジェスト

外部サービスによって実行される管理 (調整、再試行、監視、アラートなど) を必要とする組織では、コネクタを使用するのが最も適切なソリューションである可能性があります。 キューによるインジェストは、大量のデータに適しています。 Azure Data Explorer では、次の Azure Pipelines がサポートされています。

SDK を使用したプログラムによるインジェスト

Azure データ エクスプローラーで提供されている SDK を使用して、クエリとデータ インジェストを行うことができます。 プログラムによるインジェストは、インジェスト プロセスの最中および後のストレージ トランザクションを最小限に抑えることによって、インジェスト コスト (COG) を削減するように最適化されています。

使用可能な SDK とオープン ソース プロジェクト

ツール

  • インジェスト ウィザード: さまざまな種類のソースからテーブルを作成および調整することにより、データを迅速に取り込むことができます。 インジェスト ウィザードでは、Azure Data Explorer 内のデータ ソースに基づいて、テーブルとマッピングの構造が自動的に提案されます。 このウィザードは、1 回限りのインジェストに使ったり、データが取り込まれたされたコンテナー上の Event Grid を使用した継続的インジェストを定義するために使ったりすることができます。

  • LightIngest :Azure Data Explorer へのアドホック データ インジェストのためのコマンドライン ユーティリティ。 このユーティリティは、ローカル フォルダーまたは Azure Blob Storage コンテナーからソース データをプルできます。

管理コマンドの取り込み

コマンドを使用して、エンジンにデータを直接取り込みます。 このメソッドはデータ管理サービスをバイパスするため、探索とプロトタイプ作成にのみ使用してください。 運用環境または大規模なシナリオでは、この方法を使用しないでください。

  • インライン インジェスト: 管理コマンド .ingest inline がエンジンに送信され、取り込まれるデータはコマンド テキスト自体の一部になります。 この方法は、即席のテストを目的としたものです。

  • クエリからの取り込み: 管理コマンド .set、.append、.set-or-append、または .set-or-replace がエンジンに送信され、クエリまたはコマンドの結果として間接的にデータが指定されます。

  • ストレージからの取り込み (pull): 管理コマンド .ingest がエンジンに送信され、エンジンによってアクセス可能で、コマンドによって指し示される外部ストレージ (たとえば、Azure Blob Storage) に格納されたデータがエンジンに送信されます。

インジェストの方法とツールの比較

インジェスト名 データ型 ファイルの最大サイズ ストリーミング、バッチ処理、直接 最も一般的なシナリオ 考慮事項
Get Data エクスペリエンス *sv、JSON 非圧縮で 1 GB (注を参照) 直接インジェストでコンテナー、ローカル ファイル、BLOB にバッチ処理 1 回限り、テーブル スキーマの作成、Event Grid による継続的インジェストの定義、コンテナーを使用した一括インジェスト (最大 5,000 の BLOB。履歴のインジェストを使用する場合は制限なし)
LightIngest すべての形式がサポートされる 非圧縮で 1 GB (注を参照) DM を使用したバッチ処理またはエンジンへの直接インジェスト データの移行、インジェスト タイムスタンプを調整した履歴データ、一括インジェスト (サイズ制限なし) 大文字と小文字を区別する、スペースを区別する
ADX Kafka Avro、ApacheAvro、JSON、CSV、Parquet、ORC 無制限。 Java の制限を継承。 バッチ処理、ストリーミング 既存のパイプライン、ソースからの大量の使用量。 基本設定は、"複数のプロデューサー/コンシューマー" サービスが既に使用されているかどうか、またはどのようなサービスの管理が必要であるかによって決まります。
ADX から Apache Spark Spark 環境でサポートされているすべての形式 無制限 バッチ 既存のパイプライン、インジェスト前の Spark での前処理、Spark 環境でサポートされるさまざまなソースからの安全な (Spark) ストリーミング パイプラインを迅速に作成する方法。 Spark クラスターのコストを考慮してください。 バッチ書き込みの場合は、Event Grid の Azure Data Explorer データ接続と比較します。 Spark ストリーミングの場合は、Event Hub のデータ接続と比較します。
LogStash JSON 無制限。 Java の制限を継承。 コネクタへの入力は Logstash イベントであり、コネクタはバッチ インジェストを使用して Kusto に出力します。 既存のパイプライン、入力からの大量の使用量に対する Logstash の成熟したオープンソースの性質の活用。 基本設定は、"複数のプロデューサー/コンシューマー" サービスが既に使用されているかどうか、またはどのようなサービスの管理が必要であるかによって決まります。
Azure Data Factory (ADF) サポートされるデータ形式 無制限 *(ADF あたりの制限) バッチ処理または ADF トリガーごと 通常はサポートされていない形式、大規模なファイルをサポートしています。また、オンプレミスからクラウドに 90 を超えるソースをコピーできます。 この方法では、データが取り込まれるまでに比較的時間がかかります。 ADF によるすべてのデータがメモリにアップロードされ、インジェストが開始されます。
Power Automate すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ フローの一部としてのインジェスト コマンド。 パイプラインの自動化に使用される。
Logic Apps すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ パイプラインの自動化に使用される
IoT Hub サポートされるデータ形式 該当なし バッチ処理、ストリーミング IoT メッセージ、IoT イベント、IoT プロパティ
イベント ハブ サポートされるデータ形式 該当なし バッチ処理、ストリーミング メッセージ、イベント
Event Grid サポートされるデータ形式 非圧縮で 1 GB バッチ処理 Azure ストレージからの継続的なインジェスト、Azure ストレージ内の外部データ インジェストは、BLOB の名前変更または BLOB 作成アクションによってトリガーできます
.NET SDK すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ処理、ストリーミング、直接 組織のニーズに合わせて独自のコードを作成する
Python すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ処理、ストリーミング、直接 組織のニーズに合わせて独自のコードを作成する
Node.js すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ処理、ストリーミング、直接 組織のニーズに合わせて独自のコードを作成する
Java すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ処理、ストリーミング、直接 組織のニーズに合わせて独自のコードを作成する
REST すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ処理、ストリーミング、直接 組織のニーズに合わせて独自のコードを作成する
Go すべての形式がサポートされる 非圧縮で 1 GB (注を参照) バッチ処理、ストリーミング、直接 組織のニーズに合わせて独自のコードを作成する

注意

上の表で参照されている場合、インジェストでは最大ファイル サイズとして 6 GB がサポートされます。 100 MB から 1 GB の間のファイルを取り込むことをお勧めします。

インジェスト プロセス

ニーズに最も適したインジェスト方法を選択したら、次の手順を実行します。

  1. バッチ処理ポリシーを設定する (省略可能)

    バッチ処理マネージャーは、インジェスト バッチ処理ポリシーに基づいて、インジェスト データをバッチ処理します。 インジェストの前にバッチ処理ポリシーを定義します。 インジェストのベスト プラクティス - スループットの最適化に関するページを参照してください。 バッチ処理ポリシーに対する変更は、有効になるまでに最大 5 分かかる場合があります。 このポリシーにより、バッチ作成からの経過時間、累積項目数 (BLOB)、または合計バッチ サイズの 3 つの要因に従ってバッチ制限が設定されます。 既定では、設定は 5 分/1000 BLOB/1 GB で、最初に制限に達したときに有効になります。 そのため、通常、インジェストのためにサンプル データをキューに入れるのに 5 分の遅延が生じます。

  2. 保持ポリシーを設定する

    Azure Data Explorer のテーブルに取り込まれたデータは、テーブルの有効な保持ポリシーの対象となります。 テーブルに明示的に設定しない限り、有効な保持ポリシーはデータベースの保持ポリシーから取得されます。 ホット リテンションは、クラスター サイズと保持ポリシーの機能です。 使用可能な領域よりも多くのデータを取り込むと、最初のデータにコールド リテンションが適用されます。

    データベースの保持ポリシーがご自分のニーズに適していることを確認してください。 適していない場合は、テーブル レベルで明示的にオーバーライドします。 詳細については、「保持ポリシー」を参照してください。

  3. テーブルの作成

    プログラムでデータを取り込むには、事前にテーブルを作成する必要があります。 データの取得エクスペリエンスを使用している場合は、インジェスト フローの一部としてテーブルを作成できます。

    注意

    レコードが不完全な場合、またはフィールドを必要なデータ型として解析できない場合は、対応するテーブル列に null 値が設定されます。

  4. スキーマ マッピングの作成

    スキーマ マッピングは、ソースのデータ フィールドをターゲットのテーブル列にバインドするのに役立ちます。 マッピングを使用すると、定義された属性に基づいて、異なるソースから同じテーブルにデータを取り込むことができます。 行指向 (CSV、JSON、AVRO) と列指向 (Parquet) の両方で、さまざまな種類のマッピングがサポートされています。 ほとんどの方法では、マッピングをテーブルで事前に作成して、取り込みコマンドのパラメーターから参照することもできます。

  5. 更新ポリシーの設定 (省略可能)

    一部のデータ形式マッピング (Parquet、JSON、Avro) では、簡単で便利な取り込み時の変換がサポートされています。 取り込み時により複雑な処理を必要とするシナリオの場合は、更新ポリシーを調整します。これにより、クエリ コマンドを使用した簡易処理がサポートされます。 更新ポリシーでは、元のテーブルの取り込まれたデータに対して抽出と変換が自動的に実行され、結果のデータが 1 つ以上の宛先テーブルに取り込まれます。

  6. データの取り込み

    コマンドまたはインジェスト ウィザードを使って、データベースに作成したテーブルにサンプル データを取り込むことができます。 独自のデータを取り込むには、 インジェスト ツール、多様なサービスへの コネクタ 、 マネージド パイプライン、 SDK を使用したプログラムによるインジェスト、 インジェストへの直接アクセスなど、さまざまなオプションから選択できます。

次のステップ