Azure Data Explorerに履歴データを取り込む方法

Azure Data Explorer にオンボードする場合の一般的なシナリオは、履歴データ (バックフィルとも呼ばれます) を取り込む場合です。 このプロセスでは、既存のストレージ システムからエクステントのコレクションであるテーブルにデータを取り込 みます。

creationTime インジェスト プロパティを使用して履歴データを取り込み、エクステントの作成時間をデータが作成された時刻に設定することをお勧めします。 インジェストパーティション分割条件として作成時間を使用すると、 キャッシュ と 保持 ポリシーに従ってデータを期限切れにし、時間フィルターをより効率的にすることができます。

既定では、エクステントの作成時間はデータが取り込まれる時刻に設定されます。これにより、予期した動作が生成されない可能性があります。 たとえば、キャッシュ期間が 30 日で、保持期間が 2 年のテーブルがあるとします。 通常のフローでは、生成時に取り込まれたデータは 30 日間キャッシュされ、コールド ストレージに移動されます。 2 年後、作成時刻に基づいて、古いデータは一度に 1 日ずつ削除されます。 ただし、2 年間の履歴データを取り込む場合、既定では、データはデータの取り込み時刻として作成時刻としてマークされます。 次の理由により、望ましい結果が得られない可能性があります。

• すべてのデータはキャッシュに入り、予想よりも多くのキャッシュを使用して 30 日間そこに残ります。
• 古いデータは一度に 1 日ずつ削除されません。そのため、データは必要以上に長くクラスターに保持され、2 年後に一度にすべて削除されます。
• ソース システムで以前に日付別にグループ化されたデータが、同じ範囲で バッチ処理され 、非効率的なクエリが発生する可能性があります。

この記事では、履歴データをパーティション分割する方法について説明します。

• インジェスト時の creationTime インジェスト プロパティの使用 (推奨)

  可能であれば、ingestion プロパティをcreationTime使用して履歴データを取り込みます。これにより、ファイルまたは BLOB パスからエクステントを抽出してエクステントの作成時間を設定できます。 フォルダー構造で作成日パターンが使用されない場合は、作成時刻を反映するようにファイルまたは BLOB パスを再構築することをお勧めします。 この方法を使用すると、データが正しい作成時間でテーブルに取り込まれるので、キャッシュと保持期間が正しく適用されます。

  注意

  既定では、エクステントは作成 (インジェスト) の時間でパーティション分割されます。ほとんどの場合、データ パーティション分割ポリシーを設定する必要はありません。

• インジェスト後のパーティション分割ポリシーの使用

  インジェスト プロパティを creationTime 使用できない場合 (たとえば、作成時間を制御できない Azure Cosmos DB コネクタを使用してデータを取り込 む場合や、フォルダー構造を再構築できない場合は、インジェスト後にテーブルを再パーティション分割して 、パーティション分割ポリシーを使用して同じ効果を実現できます。 ただし、この方法では、ポリシー プロパティを最適化するために試行とエラーが必要になる場合があり、インジェスト プロパティを creationTime 使用するよりも効率が低くなります。 インジェスト プロパティを使用できない場合にのみ、 creationTime この方法をお勧めします。

前提条件

• Microsoft アカウントまたはMicrosoft Entraユーザー ID。 Azure サブスクリプションは不要です。
• Azure Data Explorer クラスターとデータベース。 クラスターとデータベースを作成します。
• ストレージ アカウント。
• インジェスト時にインジェスト プロパティを使用する creationTime 推奨される方法については、 LightIngest をインストールします。

履歴データを取り込む

インジェスト時にインジェスト プロパティを使用して履歴データを creationTime パーティション分割することを強くお勧めします。 ただし、この方法を使用できない場合は、パーティション分割ポリシーを使用して、インジェスト後にテーブルを再パーティション分割できます。

インジェスト中 (推奨)

LightIngest は、既存のストレージ システムから Azure Data Explorerに履歴データを読み込むのに役立ちます。 コマンド ライン引数の一覧を使用して独自のコマンドを作成できますが、この記事では、インジェスト ウィザードを使用してこのコマンドを自動生成する方法について説明します。 コマンドの作成だけでなく、このプロセスを使用して、新しいテーブルの作成およびスキーマ マッピングの作成も可能です。 このツールは、データセットからスキーマ マッピングを推論します。

到着地

1. Azure Data Explorer Web UI で、左側のメニューから [クエリ] を選択します。

2. データを取り込むデータベースを右クリックし、[ LightIngest] を選択します。

   

   [ データの取り込み ] ウィンドウが開き、[ 宛先 ] タブが選択されています。 [クラスター] と [データベース] の各フィールドには、自動的に値が設定されます。

3. ターゲット テーブルを選択します。 新しいテーブルにデータを取り込む場合は、[ 新しいテーブル] を選択し、テーブル名を入力します。

   注意

   テーブル名には、スペース、英数字、ハイフン、アンダースコアなど、最大 1024 文字を指定できます。 特殊文字はサポートされていません。

   

4. [Next: Source](次へ: ソース) を選択します。

source

1. [ ソースの選択] で、[ URL の追加] または [コンテナーの選択] を選択します。

   • URL を追加する場合は、[ リンク先] で、コンテナーへのアカウント キーまたは SAS URL を指定します。 SAS URL は 手動 または 自動で作成できます。

   • ストレージ アカウントからコンテナーを選択する場合は、ドロップダウン メニューから ストレージ サブスクリプション、 ストレージ アカウント、 コンテナー を選択します。

     

   注意

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

2. [ 詳細設定] を 選択して、LightIngest を使用してインジェスト プロセスの追加設定を定義します。

   

3. [ 詳細な構成 ] ウィンドウで、次の表に従って LightIngest 設定を定義します。

   

   プロパティ	説明
   作成時刻パターン	たとえば、コンテナーのフォルダー構造に基づいて日付を適用する場合など、作成されたエクステントのインジェスト時間プロパティをパターンでオーバーライドする場合に指定します。 「作成時刻のパターン」も参照してください。
   BLOB 名パターン	取り込まれたファイルを識別するために使用するパターンを指定します。 指定されたコンテナー内の blob 名のパターンに一致するすべてのファイルを取り込みます。 ワイルドカードがサポートされます。 二重引用符で囲むことをおすすめします。
   Tag	取り込まれたデータに割り当てられたタグ。 タグには、任意の文字列を使用できます。
   ファイルの量を制限する	取り込むことができるファイルの数を指定します。 指定された数を上限として、blob 名パターンに一致する最初の n 個のファイルを取り込みます。
   取り込みが完了するまで待機しない	設定すると、インジェスト処理を監視せずに、取り込み用の blob をキューに挿入します。 設定されていない場合は、LightIngest は、取り込みが完了するまでインジェストの状態のポーリングを続行します。
   選択した項目だけを表示する	コンテナー内のファイルを一覧表示しますが、取り込みません。

4. [ 完了] を選択 して[ ソース ] タブに戻ります。

   1. 必要に応じて、[ ファイル フィルター] を選択して、特定のフォルダー パスまたは特定のファイル拡張子を持つファイルのみを取り込むデータをフィルター処理します。

      

      既定では、コンテナー内のいずれかのファイルがランダムに選択され、テーブルのスキーマを生成するために使用されます。

   2. 必要に応じて、[ スキーマ定義ファイル] で使用するファイルを指定できます。

5. テーブル列の構成を表示および編集するには、 [Next: Schema](次へ: スキーマ) を選択します。

スキーマ

[スキーマ] タブには、データのプレビューが表示されます。

LightIngest コマンドを生成するには、[ 次へ: 取り込みの開始] を選択します。

省略可能:

• ドロップダウン メニューから目的の形式を選択して、自動的に推論される データ 形式を変更します。
• 自動的に推論される マッピング名を変更します。 英数字とアンダースコアを使用できます。 スペース、特殊文字、ハイフンはサポートされません。
• 既存のテーブルを使用する場合、選択した形式とテーブル スキーマが一致する場合は、現在のテーブル スキーマを保持できます。
• [ コマンド ビューアー] を選択して、入力から生成された自動コマンドを表示およびコピーします。
• 列を編集します。 [ 部分データ プレビュー] で、列のドロップダウン メニューを選択して、テーブルのさまざまな側面を変更します。

テーブルに加えることができる変更は、次のパラメーターによって異なります。

• テーブルの種類が新規かまたは既存か
• マッピングの種類が新規かまたは既存か

テーブルの種類です。	マッピングの種類	使用可能な調整
新しいテーブル	新しいマッピング	データ型の変更、列名の変更、列の削除、昇順で並べ替え、降順で並べ替え
既存のテーブル	新しいマッピング	新しい列 (その後データ型の変更、名前の変更、および更新が可能) 新しい列、昇順で並べ替え、降順で並べ替え
	既存のマッピング	昇順で並べ替え、降順で並べ替え

注意

新しい列を追加するとき、または列を更新するときに、マッピング変換を変更できます。 詳細については、マッピング変換に関するページを参照してください。

取り込み

1. テーブル、マッピング、LightIngest コマンドに緑色のチェックマークが付いたら、[生成されたコマンド] ボックスの右上にあるコピー アイコンを選択して、生成された LightIngest コマンドをコピーします。

   

   注意

   必要に応じて、[LightIngest のダウンロード] を選択して LightIngest ツールをダウンロードできます。

2. インジェスト プロセスを完了するには、コピーしたコマンドを使用して LightIngest を実行 する必要があります。

インジェスト後

手順 1: 再パーティション分割の準備

1. 古いデータを許可するように保持ポリシーを調整します。 次の例では、テーブル MyTable のアイテム保持ポリシーを 10 年に設定します。

   .alter-merge table MyTable policy retention softdelete = 3650d recoverability = enabled
   

2. インジェスト後に再パーティション分割できるのはホット データのみであるため、再パーティション分割のためにすべてのデータがホット キャッシュに入るようにキャッシュ ポリシーを調整します。 次の例では、テーブル MyTable のキャッシュを 10 年に設定します。

   .alter table MyTable policy caching hot = 3650d
   

   重要

   キャッシュ ポリシーを増やすと、通常の操作よりもかなり多くのホット キャッシュが使用され、コストが増加する可能性があります。

手順 2: 再パーティション分割を開始する

1. という名前 Timestampの列でデータをパーティション分割するパーティション分割ポリシーを作成します。 次の例では、テーブル MyTable のパーティション分割ポリシーを という名前 Timestampの列でパーティション分割するように設定します。

   .alter table MyTable policy partitioning
   ```
   {
     "EffectiveDateTime" : "1970-01-01T00:00:00",
     "PartitionKeys": [
       {
         "ColumnName": "Timestamp",
         "Kind": "UniformRange",
         "Properties": {
           "Reference": "1970-01-01T00:00:00",
           "RangeSize": "1.00:00:00",
           "OverrideCreationTime": true
         }
       }
     ]
   }
   ```
   

   パーティション分割ポリシーのプロパティの詳細については、「 パーティションのプロパティ」を参照してください。 履歴インジェストでは、次のプロパティを設定する方法が重要です。

   • 再パーティション分割をトリガーするには、 EffectiveDateTime プロパティをインジェストの開始より前の日付に設定する必要があります。
   • RangeSize は 1 日に設定されているため、データは 1 日のバケットに再パーティション分割されます。 ただし、この値はデータに合わせて設定する必要があります。 たとえば、1 日に数 GB 未満のデータがある場合は、より大きな値を設定することを検討してください。
   • OverrideCreationTime を true に設定して、データを日バケットに再パーティション分割した後、エクステントがその日に作成時刻としてマークされるようにする必要があります。

2. マージ ポリシーを設定して、14 日より前のエクステントを含むすべてのエクステントのマージを許可します。 このポリシーを設定することは重要です。再パーティション分割プロセスでは 14 日より前のエクステントが作成され、既定ではマージ プロセスによって除外されます。

   .alter table MyTable policy merge
   ```
   {
     "Lookback": {
       "Kind": "HotCache"
     }
   }
   ```
   

3. .show database extents partitioning statistics コマンドを使用して、パーティション分割の進行状況を監視します。 返された結果で、パーティション分割しているテーブルを探し、 PartitionedRowPercentage 列を監視します。 PartitionedRowPercentage 列の値が の場合、100パーティション分割は完了です。

手順 3: 再パーティション分割後のクリーンアップ

再パーティション分割が完了したら、前の手順で設定したポリシーをクリーンできます。

1. パーティション分割ポリシーを削除します。

   .delete table MyTable policy partitioning
   

2. マージ ポリシーを削除します。

   .delete table MyTable policy merge
   

3. キャッシュ ポリシーを削除または設定します。

   // Remove the caching policy
   .delete table MyTable policy caching
   // OR set the caching policy to your desired value
   .alter table MyTable policy caching hot = 90d
   

4. アイテム保持ポリシーを削除または設定します。

   // Remove the retention policy
   .delete table MyTable policy retention
   // OR set the retention policy to your desired value
   .alter-merge table MyTable policy retention softdelete = 30d recoverability = enabled
   

関連コンテンツ

• Azure Data Explorer でデータのクエリを実行する