具体化されたビューのユース ケース
具体化されたビュー、ソース テーブルまたは別の具体化されたビューに対して 集計 クエリを公開します。 この記事では、具体化されたビューの一般的なユース ケースと高度なユース ケースについて説明します。
一般的なユース ケース
具体化されたビューを使用して対処できる一般的なシナリオを次に示します。
データの更新:
arg_max()(集計関数)を使用してエンティティごとの最後のレコードを返すことによってデータを更新します。 たとえば、これから取り込まれたレコードのみを具体化するビューを作成します。.create materialized-view ArgMax on table T { T | summarize arg_max(Timestamp, *) by User }データの解像度を下げる 生データに対する定期的な統計を計算することで、データの解像度を下げることができます。 期間ごとに さまざまな
集計関数を使用します。 たとえば、1 日あたりの個別のユーザーの up-to-date スナップショットを保持します。 .create materialized-view UsersByDay on table T { T | summarize dcount(User) by bin(Timestamp, 1d) }重複除去レコード:
take_any()(集計関数)を使用してテーブル内のレコードを重複除去 します。 たとえば、6 時間のルックバックを使用して、EventId列に基づいてソース テーブルを重複除去する具体化されたビューを作成します。 レコードは、現在のレコードの 6 時間前に取り込まれたレコードのみに重複除去されます。.create materialized-view with(lookback=6h) DeduplicatedTable on table T { T | summarize take_any(*) by EventId }手記
具体化されたビューを参照するテーブルと同じ名前の関数を作成することで、ソース テーブルを隠すことができます。 このパターンにより、テーブルに対してクエリを実行する呼び出し元は、重複除去されたマテリアライズド ビューにアクセスできるようになります。これは、関数が同じ名前のテーブルオーバーライドするためです。 ビュー定義で循環参照を回避するには、table() 関数を使用してソース テーブルを参照します。
.create materialized-view DeduplicatedTable on table T { table('T') | summarize take_any(*) by EventId }
その他の例については、.create materialized-view コマンドを参照してください。
高度なシナリオ
具体化されたビューを使用して、イベントの作成/更新/削除処理を行うことができます。 各列に不完全または古い情報が含まれるレコードの場合、マテリアライズド ビューでは、削除されたエンティティを除き、各列の最新の更新を提供できます。
Eventsという名前の次の入力テーブルについて考えてみましょう。
入力
| タイムスタンプ | cud | 身分証明書 | col1 | col2 | col3 |
|---|---|---|---|---|---|
| 2023-10-24 00:00:00.0000000 | C | 1 | 1 | 2 | |
| 2023-10-24 01:00:00.0000000 | U | 1 | 22 | 33 | |
| 2023-10-24 02:00:00.0000000 | U | 1 | 23 | ||
| 2023-10-24 00:00:00.0000000 | C | 2 | 1 | 2 | |
| 2023-10-24 00:10:00.0000000 | U | 2 | 4 | ||
| 2023-10-24 02:00:00.0000000 | D | 2 |
arg_max() 集計関数を使用して、列ごとの最新の更新を取得する具体化されたビューを作成します。
クエリ を実行する
.create materialized-view ItemHistory on table Events
{
Events
| extend Timestamp_col1 = iff(isnull(col1), datetime(1970-01-01), Timestamp),
Timestamp_col2 = iff(isnull(col2), datetime(1970-01-01), Timestamp),
Timestamp_col3 = iff(isnull(col3), datetime(1970-01-01), Timestamp)
| summarize arg_max(Timestamp_col1, col1), arg_max(Timestamp_col2, col2), arg_max(Timestamp_col3, col3), arg_max(Timestamp, cud) by id
}
出力
| 身分証明書 | Timestamp_col1 | col1 | Timestamp_col2 | col2 | Timestamp_col3 | col3 | タイムスタンプ | cud |
|---|---|---|---|---|---|---|---|---|
| 2 | 2023-10-24 00:00:00.0000000 | 1 | 2023-10-24 00:10:00.0000000 | 4 | 1970-01-01 00:00:00.0000000 | 2023-10-24 02:00:00.0000000 | D | |
| 1 | 2023-10-24 00:00:00.0000000 | 1 | 2023-10-24 02:00:00.0000000 | 23 | 2023-10-24 01:00:00.0000000 | 33 | 2023-10-24 02:00:00.0000000 | U |
ストアド関数 を作成して、結果をさらにクリーンアップできます。
ItemHistory
| project Timestamp, cud, id, col1, col2, col3
| where cud != "D"
| project-away cud
最終的な出力 を
ID 2 が削除されたため、ID 1の各列の最新の更新。
| タイムスタンプ | 身分証明書 | col1 | col2 | col3 |
|---|---|---|---|---|
| 2023-10-24 02:00:00.0000000 | 1 | 1 | 23 | 33 |
具体化されたビューと更新ポリシー
具体化されたビューと更新ポリシーは動作が異なり、さまざまなユース ケースに対応します。 次のガイドラインを使用して、使用する必要があるガイドラインを特定します。
具体化されたビューは 集計に適していますが、更新ポリシーには適していません。 更新ポリシーはインジェスト バッチごとに個別に実行されるため、同じインジェスト バッチ内でのみ集計を実行できます。 集計クエリが必要な場合は、常に具体化されたビューを使用します。
更新ポリシーは、データ変換、ディメンション テーブルを使用したエンリッチメント (通常は 参照演算子を使用) や、単一のインジェストのスコープで実行できるその他のデータ操作に役立ちます。
更新ポリシーは、インジェスト時に実行されます。 すべての更新ポリシーが実行されるまで、ソース テーブルまたはターゲット テーブルのクエリではデータを使用できません。 一方、具体化されたビューはインジェスト パイプラインの一部ではありません。 具体化プロセス インジェスト後にバックグラウンドで定期的に実行されます。 ソース テーブル内のレコードは、具体化される前にクエリで使用できます。
更新ポリシーと具体化されたビューの両方に 結合組み込むことができますが、その有効性は特定のシナリオに限定されます。 具体的には、結合は、更新ポリシーまたは具体化プロセスの時点で、両側からの結合に必要なデータにアクセスできる場合にのみ適しています。 更新ポリシーまたは具体化の実行時に一致するエンティティが取り込まれると、データが見落とされるリスクがあります。 マテリアライズド ビュー クエリ パラメーター とファクト テーブルとディメンション テーブル
の詳細を参照してください。
手記
更新ポリシーや具体化されたビューに適していない 結合