.create materialized-view

[アーティクル]
07/03/2024

具体化されたビューは、ソーステーブルに対する集計クエリです。これは単一の summarize ステートメントを表します。

コマンドの backfill オプションで示されているように、具体化されたビューを作成するには、次の 2 つの方法があります。

これから具体化されたビューを作成します。

具体化されたビューは空で作成されます。ビューの作成後に取り込まれたレコードのみが含まれます。この種類の作成はすぐに返され、ビューはすぐにクエリに使用できます。

ソーステーブルの既存のレコードに基づいて、具体化されたビューを作成する:

「具体化されたビューの埋め込みを参照してください。
ソーステーブル内のレコードの数によっては、作成が完了するまでに時間がかかる場合があります。バックフィルが完了するまで、ビューはクエリで使用できません。
このオプションを使用する場合は、create コマンドを asyncする必要があります。 .show operations コマンドを使用して実行を監視できます。
.cancel operation コマンドを使用して、バックフィルプロセスを取り消すことができます。

重要

大きなソーステーブルでは、バックフィルオプションの完了に時間がかかる場合があります。実行中にこのプロセスが一時的に失敗した場合、自動的には再試行されません。その後、create コマンドを再実行する必要があります。詳細については、「マテリアライズドビューのバックフィルを参照してください。

アクセス許可

このコマンドには、 Database Admin アクセス許可が必要です。具体化されたビューの作成者は、その管理者になります。

構文

.create [async] [ifnotexists] materialized-view [ with (PropertyName = PropertyValue,...)] MaterializedViewName on table SourceTableName { Query }

構文規則について詳しく知る。

パラメーター

件名	タイプ	Required	説明
PropertyName、 PropertyValue	`string`		サポートされるプロパティの一覧から、名前と値のペアの形式のプロパティの一覧。
MaterializedViewName	`string`	✔️	マテリアライズドビューの名。ビュー名は、同じデータベース内のテーブル名または関数名と競合することはできないため、 identifier の名前付け規則に従う必要があります。
SourceTableName	`string`	✔️	ビューが定義されているソーステーブルの名前。
クエリ	`string`	✔️	具体化されたビューのクエリ定義。詳細と制限事項については、「 Query パラメーター」セクションを参照してください。

Note

具体化されたビューが既に存在する場合:

ifnotexists フラグが指定されている場合、コマンドは無視されます。新しい定義が既存の定義と一致しない場合でも、変更は適用されません。
ifnotexists フラグが指定されていない場合は、エラーが返されます。
既存の具体化されたビューを変更するには、 .alter materialized-view コマンドを使用します。

サポートされているプロパティ

with (PropertyName = PropertyValue) 句では、次のプロパティがサポートされています。すべてのプロパティは省略可能です。

名前	種類	説明
backfill	`bool`	現在 `SourceTable` (`true`) にあるすべてのレコードに基づいてビューを作成するか、これから作成するか (`false`)。既定値は `false` です。詳細については、「マテリアライズドビューのバックフィルを参照してください。
effectiveDateTime	`datetime`	`backfill`を使用している場合にのみ関連します。設定されている場合、作成は datetime より後に取り込まれたレコードでのみバックフィルされます。 `backfill` も `true`に設定する必要があります。このプロパティには datetime リテラルが必要です。たとえば、 `effectiveDateTime=datetime(2019-05-01)`。
updateExtentsCreationTime	`bool`	`backfill`を使用している場合にのみ関連します。 `true`に設定されている場合、バックフィルプロセス中に datetime group-by キーに基づいて Extent Creation time が割り当てられます。詳細については、「マテリアライズドビューのバックフィルを参照してください。
lookback	`timespan`	具体化されたビュー `arg_max`/`arg_min`/`take_any` に対してのみ有効です。重複が予想される期間が制限されます。たとえば、 `arg_max` ビューで 6 時間のルックバックが指定されている場合、新しく取り込まれたレコードと既存のレコードの間の重複除去では、最大 6 時間前に取り込まれたレコードのみが考慮されます。ルックバックは、 `ingestion_time`に対する相対値です。ルックバック期間を誤って定義すると、具体化されたビューで重複が発生する可能性があります。たとえば、同じキーのレコードが取り込まれた 10 時間後に特定のキーのレコードが取り込まれ、ルックバックが 6 時間に設定されている場合、そのキーはビュー内で重複します。ルックバック期間は、マテリアル化時間およびクエリ時間の両方で適用されます。
autoUpdateSchema	`bool`	ソーステーブルの変更に関するビューを自動的に更新するかどうかを指定します。既定値は `false` です。このオプションは、 `arg_max(Timestamp, )`/`arg_min(Timestamp, )`/`take_any()` 型のビューに対してのみ有効です (列の引数が ``されている場合のみ)。このオプションを `true` に設定すると、ソーステーブルへの変更がマテリアライズドビューに自動的に反映されます。
dimensionTables	配列	ビュー内のディメンションテーブルの配列を含む動的引数。 Query パラメーターを参照してください。
フォルダー	`string`	具体化されたビューのフォルダー。
docString	`string`	具体化されたビューを文書化する文字列。
allowMaterializedViewsWithoutRowLevelSecurity	`bool`	行レベルのセキュリティポリシーが有効になっているテーブルに対して具体化されたビューを作成できるようにします。

警告

マテリアライズドビューのソーステーブルに対する変更やデータの変更により、マテリアライズドビュークエリと予想される具体化されたビュースキーマとの間に非互換性が生じる場合、システムはマテリアライズドビューを自動的に無効にします。
このエラーを回避するには、具体化されたビュークエリを決定論的にする必要があります。たとえば、 bag_unpack または pivot プラグインは、非決定的なスキーマになります。
arg_max(Timestamp, *)集計を使用していて、autoUpdateSchemaが false の場合、ソーステーブルを変更するとスキーマの不一致が発生する可能性もあります。ビュークエリを arg_max(Timestamp, Column1, Column2, ...) として定義するか、autoUpdateSchema オプションを使用して、このエラーを回避します。
autoUpdateSchemaを使用すると、ソーステーブル内の列が削除されると、元に戻せないデータが失われる可能性があります。
MaterializedViewResult メトリックを使用して、具体化されたビューの自動無効化を監視します。
非互換性の問題を修正したら、可能な具体化されたビューコマンドを使用して、ビューを明示的に再度有効にする必要があります。

具体化されたビューにマテリアライズドビューを作成する

別の具体化されたビューに対して具体化されたビューを作成できるのは、ソースマテリアライズドビューが take_any(*) 集計 (重複除去) である場合のみです。詳細については、「具体化されたビューの具体化されたビューおよび Examplesを参照してください。

構文：

.create [async] [ifnotexists] materialized-view [ with (PropertyName = PropertyValue,...)] MaterializedViewName on materialized-view SourceMaterializedViewName { Query }

パラメーター:

名前	タイプ	Required	説明
PropertyName、 PropertyValue	`string`		サポートされるプロパティの一覧から、名前と値のペアの形式のプロパティの一覧。
MaterializedViewName	`string`	✔️	マテリアライズドビューの名。ビュー名は、同じデータベース内のテーブル名または関数名と競合することはできないため、 identifier の名前付け規則に従う必要があります。
SourceMaterializedViewName	`string`	✔️	ビューが定義されているソースマテリアライズドビューの名前。
クエリ	`string`	✔️	具体化されたビューのクエリ定義。

例

今後取り込まれたレコードのみを具体化する空の arg_max ビューを作成します。
```
.create materialized-view ArgMax on table T
{
    T | summarize arg_max(Timestamp, *) by User
}
```

asyncを使用して、バックフィルオプションを使用して日次集計の具体化されたビューを作成します。

.create async materialized-view with (backfill=true, docString="Customer telemetry") CustomerUsage on table T
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day 
}

backfillとeffectiveDateTimeを使用して具体化されたビューを作成します。ビューは、datetime からのレコードのみに基づいて作成されます。

.create async materialized-view with (backfill=true, effectiveDateTime=datetime(2019-01-01)) CustomerUsage on table T 
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day
}

6 時間のルックバックを使用して、 EventId 列に基づいてソーステーブルを重複除去する具体化されたビューを作成します。レコードは、現在のレコードの 6 時間前に取り込まれたレコードのみに重複除去されます。
```
.create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}
```

前の DeduplicatedTable マテリアライズドビューに基づくダウンサンプリングマテリアライズドビューを作成します。

.create materialized-view DailyUsage on materialized-view DeduplicatedTable
{
    DeduplicatedTable
    | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
}

summarizeが最後の演算子である限り、定義には、summarize ステートメントの前に追加の演算子を含めることができます。

.create materialized-view CustomerUsage on table T 
{
    T 
    | where Customer in ("Customer1", "Customer2", "CustomerN")
    | parse Url with "https://contoso.com/" Api "/" *
    | extend Month = startofmonth(Timestamp)
    | summarize count(), dcount(User), max(Duration) by Customer, Api, Month
}

ディメンションテーブルと結合する具体化されたビューを次に示します。

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T
{
    T
    | lookup DimUsers on User  
    | summarize arg_max(Timestamp, *) by User 
}

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T 
{
    DimUsers | project User, Age, Address
    | join kind=rightouter hint.strategy=broadcast T on User
    | summarize arg_max(Timestamp, *) by User 
}

解説

Query parameter (クエリパラメーター)

次のルールでは、具体化されたビューのクエリパラメーターで使用されるクエリが制限されます。

クエリは、具体化されたビューのソースである 1 つのファクトテーブルを参照する必要があります。 1 つの summarize 演算子と、1 つ以上の aggregation 関数を含める必要があります式によって 1 つ以上のグループによって集計されます。 summarize演算子は、常にクエリの最後の演算子である必要があります。

1 つの arg_max/arg_min/take_any 集計のみを含むマテリアライズドビューは、これらの集計を他の集計 ( count/dcount/avg など) と共に含む具体化されたビューよりも優れたパフォーマンスを発揮する場合があります。これは、一部の最適化は、このような具体化されたビューにのみ関連するためです。ビューに混合集計関数が含まれている場合は適用されません ( ミックス は、同じビュー内の arg_max/arg_min/take_any とその他の集計の両方を意味します)。
クエリには、now() に依存する演算子を含めることはできません。たとえば、クエリに where Timestamp > ago(5d) を含めることはできません。具体化されたビューのアイテム保持ポリシーを使用して、ビューがカバーする期間を制限します。
具体化されたビュークエリでは、 sort、 top-nested、 top、 partition、 serializeの演算子はサポートされていません。
複合集計は、具体化されたビューの定義ではサポートされていません。たとえば、 SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Idを使用する代わりに、具体化されたビューを次のように定義 SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id。クエリの表示中に、 MaterializedViewName | project Id, Result=a/bを実行します。計算列 (a/b) を含むビューの必要な出力は、ストアド関数にカプセル化できます。具体化されたビューに直接アクセスするのではなく、ストアド関数にアクセスします。
クラスター間クエリとデータベース間クエリはサポートされていません。
external_table() と externaldata への参照はサポートされていません。
具体化されたビュークエリには、偽装を必要とする吹き出しを含めることはできません。具体的には、偽装を使用するすべてのクエリ接続プラグインは許可されません。
ビューのソーステーブルに加えて、クエリは 1 つ以上の dimension テーブルを参照できます。ディメンションテーブルは、ビュープロパティで明示的に呼び出す必要があります。ディメンションテーブルと結合するときは、次の動作を理解することが重要です。
- ビューのソーステーブル (ファクトテーブル) のレコードは、1 回だけ具体化されます。ディメンションテーブルの更新は、ファクトテーブルから既に処理されているレコードには影響しません。
- ファクトテーブルとディメンションテーブルの間でインジェストの待機時間が異なると、ビューの結果に影響する可能性があります。
  
  例: ビュー定義には、ディメンションテーブルとの内部結合が含まれます。具体化時には、ディメンションレコードは完全には取り込まれていませんでしたが、ファクトテーブルに既に取り込まれていませんでした。このレコードはビューから削除され、再び処理されることはありません。
  
  同様に、その結合が外部結合である場合、ファクトテーブルのレコードが処理され、ディメンションテーブル列の null 値と共にビューに追加されます。ビューに (null 値と共に) 既に追加されているレコードは、再度処理されません。ディメンションテーブルの列の値は null のままです。

サポートされている集計関数

サポートされている集計関数は次のとおりです。

パフォーマンスに関するヒント

datetime グループ化キーを使用する: datetime 列をグループ化キーの 1 つとして持つ具体化されたビューは、それ以外のキーよりも効率的です。理由は、datetime グループ化キーがある場合にのみ、一部の最適化を適用できることです。 datetime group-by キーを追加しても集計のセマンティクスが変更されない場合は、追加することをお勧めします。これは、datetime 列が一意のエンティティごとに 変更可能 場合にのみ実行できます。

たとえば、次のような集計の場合です。
```
    SourceTable | summarize take_any(*) by EventId
```
EventId常に同じTimestamp値を持っているため、Timestampを追加しても集計のセマンティクスが変更されない場合は、ビューを次のように定義することをお勧めします。
```
    SourceTable | summarize take_any(*) by EventId, Timestamp
```
ヒント

datetime グループ化キーの到着が遅れたデータは、具体化されたビューのパフォーマンスに悪影響を及ぼす可能性があります。たとえば、具体化されたビューでグループ化されたキーの 1 つとして bin(Timestamp, 1d) が使用され、データ内のいくつかの外れ値に非常に古い Timestamp 値があるとします。これらの外れ値は、具体化されたビューに悪影響を与える可能性があります。

具体化されたビュークエリでは、外れ値レコードを除外するか、これらのレコードを現在の時刻に正規化することをお勧めします。
ルックバック期間を定義する: シナリオに該当する場合、 lookback プロパティを追加すると、クエリのパフォーマンスが大幅に向上する可能性があります。詳細については、「サポートされるプロパティ」を参照してください。
グループ化キーとしてフィルター処理するために頻繁に使用される列を追加する: 具体化されたビューのクエリは、マテリアライズドビューのグループ化キーのいずれかでフィルター処理されるときに最適化されます。クエリパターンが、マテリアライズドビュー内の一意のエンティティに従って変更できない列でフィルター処理されることが多いことがわかっている場合は、具体化されたビューのグループ化キーに含めます。

たとえば、具体化されたビューでは、多くの場合、SubscriptionIdでフィルター処理されるResourceId値によってarg_maxが公開されます。 ResourceId値が常に同じSubscriptionId値に属していると仮定して、具体化されたビュークエリを次のように定義します。
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}
```
上記の定義は、次よりも優先されます。
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}
```

必要に応じて更新ポリシーを使用する: 具体化されたビューには、ディメンションテーブルの変換、正規化、および参照を含めることができます。ただし、これらの操作を update ポリシーに移動することをお勧めします。具体化されたビューの集計のみを残します。

たとえば、次の更新ポリシーを定義することをお勧めします。

.alter-merge table Target policy update 
@'[{"IsEnabled": true, 
    "Source": "SourceTable", 
    "Query": 
        "SourceTable 
        | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
        | lookup DimResources on ResourceId
        | mv-expand Events
    "IsTransactional": false}]'

次の具体化されたビューを定義します。

.create materialized-view Usage on table Events
{
    Target 
    | summarize count() by ResourceId 
}

代わりに、マテリアライズドビュークエリの一部として更新ポリシーを含めると、パフォーマンスが低下する可能性があるため、推奨されません。

.create materialized-view Usage on table SourceTable
{
    SourceTable
    | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
    | lookup DimResources on ResourceId
    | mv-expand Events
    | summarize count() by ResourceId
}

ヒント

クエリ時間のパフォーマンスが最適である必要があるが、データ待ち時間を許容できる場合は、 materialized_view() 関数を使用します。

具体化されたビューをバックフィルする

backfill プロパティを使用して具体化されたビューを作成する場合、具体化されたビューはソーステーブルで使用可能なレコードに基づいて作成されます。または、 effectiveDateTimeを使用する場合は、それらのレコードのサブセットに基づいて作成されます。

バックグラウンドでは、バックフィルプロセスによりデータが分割されて複数のバッチにバックフィルされ、いくつかの取り込み操作が実行されてビューがバックフィルされます。ソーステーブル内のレコードの数が多い場合、プロセスの完了に時間がかかる場合があります。プロセスの期間は、クラスターのサイズによって異なります。 .show operations コマンドを使用して、バックフィルの進行状況を追跡します。

バックフィルプロセス時に発生する一時的な失敗の場合は、再試行されます。すべての再試行が使い果たされると、コマンドは失敗し、create コマンドを手動で再実行する必要があります。

ソーステーブル内のレコードの数が number-of-nodes X 200 million を超える場合 (クエリの複雑さに応じて、さらに少ない場合があります) は、バックフィルを使用しないことをお勧めします。別の方法として、移動エクステントによるバックフィルオプションがあります。

コールドキャッシュ内のデータでは、バックフィルオプションの使用はサポートされていません。必要に応じて、ビューの作成中にホットキャッシュ期間を増やします。これにはスケールアウトが必要な場合があります。

ビューの作成でエラーが発生した場合は、次のプロパティを変更してみてください。

MaxSourceRecordsForSingleIngest: 既定では、バックフィル中の各取り込み操作のソースレコードの数は、ノードあたり 200 万です。このプロパティを目的のレコード数に設定することで、この既定値を変更できます。 (値は、各取り込み操作の合計レコード数です)。

この値を小さくすると、メモリ制限やクエリタイムアウトで作成が失敗した場合に役立ちます。この値を大きくすると、クラスターが既定よりも多くのレコードに対して集計関数を実行できることを前提として、ビューの作成を高速化できます。
Concurrency: バックフィルプロセスの一部として実行される取り込み操作は、同時に実行されます。既定では、コンカレンシーは min(number_of_nodes * 2, 5) です。このプロパティは、コンカレンシーを増減するように設定できます。この値は、クラスターの CPU 使用率が低い場合にのみ増やすことをお勧めします。これは、増加がクラスターの CPU 消費量に大きく影響する可能性があるためです。

たとえば、次のコマンドは、 2020-01-01から具体化されたビューをバックフィルします。各取り込み操作のレコードの最大数は 300 万です。このコマンドは、 2のコンカレンシーを使用して取り込み操作を実行します。

.create async materialized-view with (
        backfill=true,
        effectiveDateTime=datetime(2020-01-01),
        MaxSourceRecordsForSingleIngest=3000000,
        Concurrency=2
    )
    CustomerUsage on table T
{
    T
    | summarize count(), dcount(User), max(Duration) by Customer, bin(Timestamp, 1d)
}

具体化されたビューに datetime グループ化キーが含まれている場合、バックフィルプロセスでは、datetime 列に基づく拡張作成時刻のオーバーライドがサポートされます。これは、たとえば、古いレコードを最近のレコードより前に削除する場合に役立ちます。これは、再入ポリシーがエクステントの作成時間に基づいているためです。 updateExtentsCreationTime プロパティは、ビューに、bin()関数を使用する datetime グループ化キーが含まれている場合にのみサポートされます。たとえば、次のバックフィルでは、Timestamp グループ別キーに基づいて作成時間が割り当てられます。

.create async materialized-view with (
        backfill=true,
        updateExtentsCreationTime=true
    )
    CustomerUsage on table T
{
    T
    | summarize count() by Customer, bin(Timestamp, 1d)
}

エクステントの移動によるバックフィル

移動エクステントによるバックフィルオプションは、既存のテーブルに基づいて具体化されたビューをバックフィルします。これは、必ずしもマテリアライズドビューのソーステーブルであるとは限りません。指定したテーブルから基になる具体化されたビューテーブルにエクステントを移動バックフィルを実現します。このプロセスは、次のことを意味します。

指定したテーブル内のデータは、具体化されたビュースキーマと同じスキーマを持つ必要があります。
指定したテーブル内のレコードは、そのままビューに移動されます。これらは、具体化されたビューの定義に基づいて重複除去されると見なされます。

たとえば、具体化されたビューに次の集計があるとします。

T | summarize arg_max(Timestamp, *) by EventId

その後、移動エクステント操作のソーステーブル内のレコードは、既に EventID によって重複除去されている必要があります。

操作では .move エクステントを使用するため、バックフィル中に指定したテーブルからレコードが削除されます (移動され、コピーされません)。

移動エクステントによるバックフィルは、具体化されたビューでサポートされているすべての aggregation 関数ではサポートされていません。ビューに格納されている基になるデータが集計自体と異なる avg()、 dcount()などの集計では失敗します。

具体化されたビューは、指定されたテーブルに基づいて ''のみ'' バックフィルされます。ビューのソーステーブル内のレコードの具体化は、既定ではビューの作成日時から開始されます。

具体化されたビューのソーステーブルがデータを継続的に取り込む場合、移動エクステントを使用してビューを作成すると、データが失われる可能性があります。これは、ソーステーブルに取り込まれたレコードが、バックフィル元のテーブルを準備してからビューが作成されるまでの短い時間に、具体化されたビューに含まれないためです。このシナリオを処理するには、ソーステーブルに対する具体化されたビューの開始日時に source_ingestion_time_from プロパティを設定します。

ユースケース

移動エクステントによるバックフィルのオプションは、次の 2 つの主なシナリオで役立ちます。

具体化されたビューの重複除去されたソースデータを含むテーブルが既にあり、マテリアライズドビューのみを使用しているため、ビューの作成後にこのテーブルにこれらのレコードが必要ない場合。
具体化されたビューのソーステーブルが非常に大きく、ソーステーブルに基づくビューのバックフィルが、前述の制限のためにうまく機能しない場合。この場合は、クエリコマンドから最もを使用してバックフィルプロセスを一時テーブルに調整できますコミットされたオーケストレーションツールの 1 つ。一時テーブルにバックフィルのすべてのレコードが含まれている場合は、そのテーブルに基づいて具体化されたビューを作成します。

例:

次の例では、テーブル DeduplicatedTable には、 EventId インスタンスごとに 1 つのレコードが含まれており、具体化されたビューのベースラインとして使用されます。ビューの作成後に取り込まれる T 内のレコードのみが具体化されたビューに含まれます。
```
.create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
effectiveDateTime プロパティが move_extents_from プロパティと共に指定されている場合、MaxCreatedOn値が effectiveDateTime より大きいDeduplicatedTable内のエクステントのみがバックフィルに含まれます (具体化されたビューに移動されます)。
```
.create async materialized-view with 
    (move_extents_from=DeduplicatedTable, effectiveDateTime=datetime(2019-01-01)) 
    MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
次の例では、移動エクステントによるバックフィルオプションで source_ingestion_time_from プロパティを使用する方法を示します。 source_ingestion_time_fromとmove_extents_fromの両方を使用すると、具体化されたビューが 2 つのソースからバックフィルされることを示します。
- move_extents_from テーブル: 次の例でDeduplicatedTableします。このテーブルには、バックフィルするすべての履歴データが含まれている必要があります。必要に応じて、effectiveDateTime プロパティを使用して、MaxCreatedOn値がeffectiveDateTimeより大きいエクステントのみをDeduplicatedTableに含めることができます。
- 具体化されたビューのソーステーブル: 次の例で T 。このテーブルのバックフィルには、 ingestion_time() 値が source_ingestion_time_fromより大きいレコードのみが含まれます。
  
  source_ingestion_time_from プロパティは、(DeduplicatedTable) からバックフィルするテーブルを準備してからビューが作成されるまでの短い時間で、データ損失の可能性を処理するためにのみ使用する必要があります。このプロパティは、過去にあまり大きく設定しないでください。そうすると、具体化されたビューが大幅に遅れ、追いつくのが難しい場合があります。
次の例では、現在の時刻が 2020-01-01 03:00されていると仮定します。テーブル DeduplicatedTable は、T の重複除去されたテーブルです。これには、2020-01-01 00:00 まで重複除去されたすべての履歴データが含まれます。 create コマンドは、移動エクステントを使用して具体化されたビューをバックフィルするためにDeduplicatedTableを使用します。 create コマンドには、2020-01-01以降に取り込まれたT内のすべてのレコードも含まれます。
```
.create async materialized-view with (move_extents_from=DeduplicatedTable, source_ingestion_time_from=datetime(2020-01-01)) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```

具体化されたビューの作成を取り消す

バックフィルオプションを使用している場合は、具体化されたビューの作成プロセスをキャンセルできます。このアクションは、作成に時間がかかりすぎて、実行中に停止したい場合に便利です。

警告

このコマンドを実行した後、具体化されたビューを復元することはできません。

作成プロセスをすぐに取り消すことはできません。 cancel コマンドは具体化を停止するように通知します。作成時には、取り消しが要求されたかどうかが定期的に確認されます。 cancel コマンドは、具体化されたビュー作成プロセスが取り消されるまで最大 10 分間待機し、取り消しが成功したかどうかを報告します。

取り消しが 10 分以内に成功せず、キャンセルコマンドによってエラーが報告された場合でも、具体化されたビューは作成プロセスの後半でキャンセルされる可能性があります。 .show operations コマンドは操作が取り消されたかどうかを示します。

.cancel operation コマンドの発行時に操作が進行中でなくなった場合、コマンドはエラーを報告します。

構文

.cancel operationoperationId

構文規則について詳しく知る。

パラメーター

件名	タイプ	Required	説明
`operationId`	`guid`	✔️	`.create async materialized-view` コマンドから返される操作 ID。

出力

名前	種類	説明
OperationId	`guid`	`.create materialized-view` コマンドの操作 ID。
操作	`string`	操作の種類。
StartedOn	`datetime`	作成操作の開始時刻。
CancellationState	`string`	`Canceled successfully` (作成が取り消されました)、`Cancellation failed` (キャンセルがタイムアウトするまで待機)、`Unknown` (ビューの作成は実行されなくなりましたが、この操作では取り消されませんでした)。
ReasonPhrase	`string`	キャンセルが成功しなかった理由。

例

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e

OperationId	操作	StartedOn	CancellationState	ReasonPhrase
`c4b29441-4873-4e36-8310-c631c35c916e`	`MaterializedViewCreateOrAlter`	`2020-05-08 19:45:03.9184142`	`Canceled successfully`

取り消しが 10 分以内に完了していない場合、 CancellationState は失敗を示します。その後、作成を取り消すことができます。

次の方法で共有

.create materialized-view

アクセス許可

構文

パラメーター

サポートされているプロパティ

具体化されたビューにマテリアライズドビューを作成する

例

解説

Query parameter (クエリパラメーター)

サポートされている集計関数

パフォーマンスに関するヒント

具体化されたビューをバックフィルする

エクステントの移動によるバックフィル

ユースケース

具体化されたビューの作成を取り消す

構文

パラメーター

出力

例

フィードバック

フィードバック

その他のリソース

次の方法で共有

.create materialized-view

アクセス許可

構文

パラメーター

サポートされているプロパティ

具体化されたビューにマテリアライズド ビューを作成する

例

解説

Query parameter (クエリ パラメーター)

サポートされている集計関数

パフォーマンスに関するヒント

具体化されたビューをバックフィルする

エクステントの移動によるバックフィル

ユース ケース

具体化されたビューの作成を取り消す

構文

パラメーター

出力

例

フィードバック

フィードバック

その他のリソース

具体化されたビューにマテリアライズドビューを作成する

Query parameter (クエリパラメーター)

ユースケース