.create materialized-view

Gilt für: ✅Microsoft Fabric✅Azure Data Explorer

Eine materialisierte Ansicht ist eine Aggregationsabfrage über eine Quelltabelle. Sie stellt eine einzelne summarize-Anweisung dar.

Es gibt zwei möglichkeiten, eine materialisierte Ansicht zu erstellen, wie in der Option "Rückfüllen " im Befehl angegeben:

Erstellen Sie die materialisierte Ansicht ab jetzt:

• Die materialisierte Ansicht wird leer erstellt. Sie enthält nur Datensätze, die nach der Erstellung der Ansicht aufgenommen wurden. Die Erstellung dieser Art wird sofort zurückgegeben, und die Ansicht ist sofort für die Abfrage verfügbar.

Erstellen Sie die materialisierte Ansicht basierend auf vorhandenen Datensätzen in der Quelltabelle:

• Siehe Hintergrundausfüllen einer materialisierten Ansicht.
• Die Erstellung kann je nach Anzahl der Datensätze in der Quelltabelle eine lange Zeit dauern. Die Ansicht ist für Abfragen erst verfügbar, wenn das Ausfüllen abgeschlossen ist.
• Wenn Sie diese Option verwenden, muss der Befehl "Erstellen" sein async. Sie können die Ausführung mithilfe des .show operations Befehls überwachen.
• Sie können den Vorgang zum Zurückfüllen mithilfe des .cancel operation Befehls abbrechen.

Wichtig

Bei großen Quelltabellen kann die Option "Zurückfüllen" eine lange Zeit in Anspruch nehmen. Wenn dieser Prozess während der Ausführung vorübergehend fehlschlägt, wird er nicht automatisch wiederholt. Anschließend müssen Sie den Befehl "Erstellen" erneut ausführen. Weitere Informationen finden Sie unter "Zurückfüllen einer materialisierten Ansicht".

Berechtigungen

Sie müssen mindestens über Datenbankadministrator- Berechtigungen zum Ausführen dieses Befehls verfügen. Der materialisierte Ansichtsersteller wird zu seinem Administrator.

Syntax

.create[] [asyncifnotexists] materialized-view [ with(PropertyName= PropertyValue,...] )MaterializedViewName SourceTableName-Abfrageon table{}

Erfahren Sie mehr über Syntaxkonventionen.

Parameter

Name	Typ	Erforderlich	Beschreibung
PropertyName, PropertyValue	string		Liste der Eigenschaften in Form von Namen- und Wertpaaren aus der Liste der unterstützten Eigenschaften.
MaterializedViewName-	string	✔️	Name der materialisierten Ansicht. Der Ansichtsname kann nicht mit Tabellen- oder Funktionsnamen in derselben Datenbank in Konflikt geraten und muss den Benennungsregeln des Bezeichners entsprechen.
SourceTableName	string	✔️	Name der Quelltabelle, für die die Ansicht definiert ist.
Abfrage	string	✔️	Abfragedefinition der materialisierten Ansicht. Weitere Informationen und Einschränkungen finden Sie im Abschnitt "Abfrageparameter ".

Hinweis

Wenn die materialisierte Ansicht bereits vorhanden ist:

• Wenn das ifnotexists Flag angegeben ist, wird der Befehl ignoriert. Es wird keine Änderung angewendet, auch wenn die neue Definition nicht mit der vorhandenen Definition übereinstimmt.
• Wenn das ifnotexists Flag nicht angegeben ist, wird ein Fehler zurückgegeben.
• Verwenden Sie den Befehl ".alter materialized-view", um eine vorhandene materialisierte Ansicht zu ändern.

Unterstützte Eigenschaften

Die folgenden Eigenschaften werden in der with(PropertyName= PropertyValue-Klausel) unterstützt. Alle Eigenschaften sind optional.

Name	Typ	Beschreibung
auffüllen	bool	Gibt an, ob die Ansicht basierend auf allen Datensätzen erstellt werden soll, die sich aktuell in SourceTable (true) befinden, oder ob sie von jetzt an (false) erstellt werden sollen. Der Standardwert ist false. Weitere Informationen finden Sie unter "Zurückfüllen einer materialisierten Ansicht".
effectiveDateTime	datetime	Nur relevant, wenn Sie verwenden backfill. Wenn dieser Wert festgelegt ist, wird die Erstellung nur wieder mit Datensätzen gefüllt, die nach der Datumstime aufgenommen wurden. backfill muss auch auf true. Diese Eigenschaft erwartet ein Datetime-Literal; beispiel: effectiveDateTime=datetime(2019-05-01).
updateExtentsCreationTime	bool	Nur relevant, wenn Sie verwenden backfill. Wenn dieser Wert auf " Festgelegt" festgelegt trueist, wird die Erstellungszeit basierend auf dem Datetime-Gruppen-nach-Schlüssel während des Backfill-Prozesses zugewiesen. Weitere Informationen finden Sie unter "Zurückfüllen einer materialisierten Ansicht".
Lookback	timespan	Die Zeitspanne, die den Zeitraum begrenzt, in dem Duplikate oder Updates erwartet werden. Weitere Informationen finden Sie unter Lookback-Zeitraum.
lookback_column	string	Eine string Spalte in der Ansicht, die als Verweis für den Nachschlagezeitraum dient. Wenn diese Spalte leer ist, der lookback Wert jedoch einen Wert aufweist, verwendet die materialisierte Ansicht einen Standard-Lookback. Weitere Informationen finden Sie unter Lookback-Zeitraum.
autoUpdateSchema	bool	Gibt an, ob die Ansicht bei Änderungen der Quelltabelle automatisch aktualisiert werden soll. Der Standardwert ist false. Diese Option ist nur für Ansichten des Typs arg_max(Timestamp, *)/arg_min(Timestamp, *)/take_any(*) gültig (nur wenn das Argument der Spalte lautet).* Wenn diese Option auf true festgelegt ist, werden Änderungen an der Quelltabelle automatisch in der materialisierten Ansicht angezeigt.
dimensionTables	Array	Ein dynamisches Argument, das ein Array von Dimensionstabellen in der Ansicht enthält. Siehe Abfrageparameter.
Ordner	string	Der Ordner der materialisierten Ansicht.
docString	string	Eine Zeichenfolge, die die materialisierte Ansicht dokumentiert.
allowMaterializedViewsWithoutRowLevelSecurity	bool	Ermöglicht das Erstellen einer materialisierten Ansicht über einer Tabelle mit aktivierter Sicherheitsrichtlinie auf Zeilenebene.

Warnung

• Das System deaktiviert automatisch eine materialisierte Ansicht, wenn Änderungen an der Quelltabelle der materialisierten Ansicht oder Änderungen in Daten zu einer Inkompatibilität zwischen der materialisierten Ansichtsabfrage und dem erwarteten materialisierten Ansichtsschema führen.
• Um diesen Fehler zu vermeiden, muss die materialisierte Ansichtsabfrage deterministisch sein. Beispielsweise führt das bag_unpack- oder Pivot-Plug-In zu einem nicht deterministischen Schema.
• Wenn Sie eine arg_max(Timestamp, *) Aggregation verwenden und wenn autoUpdateSchema "false" ist, können Änderungen an der Quelltabelle auch zu Schemakonflikten führen. Vermeiden Sie diesen Fehler, indem Sie die Ansichtsabfrage als arg_max(Timestamp, Column1, Column2, ...)oder mithilfe der autoUpdateSchema Option definieren.
• Die Verwendung autoUpdateSchema kann zu unwiderruflichen Datenverlusten führen, wenn Spalten in der Quelltabelle gelöscht werden.
• Überwachen Sie die automatische Deaktivierung von materialisierten Ansichten mithilfe der MaterializedViewResult-Metrik.
• Nachdem Sie Inkompatibilitätsprobleme behoben haben, sollten Sie die Ansicht explizit erneut aktivieren, indem Sie den Befehl ".enable materialized-view " verwenden.

Rückblickperiode

Ein Lookback gibt den maximalen erwarteten Zeitraum zwischen zwei Datensätzen derselben Gruppen-nach-Tastenkombination in der materialisierten Ansichtsquelltabelle an. Das Festlegen eines Lookbacks kann die Leistung der materialisierten Ansicht erheblich verbessern.

Betrachten Sie beispielsweise eine materialisierte Ansicht, die zum Speichern des letzten Ereignisses für jede Sitzung eines Webdiensts verwendet wird. Die Ansicht wird wie folgt definiert:

Events | summarize arg_max(ReceivedTime, *) by SessionId

Wenn klar ist, dass eine Sitzung nicht länger als einen Tag dauert, kann der Zeitraum festgelegt lookback_column werden, um die lookback Leistung zu verbessern:

.create materialized-view with(lookback=1d, lookback_column = "ReceivedTime") SessionEvents on table Events
{
    Events
    | summarize arg_max(ReceivedTime, *) by SessionId
}

Wenn Sie einen Lookback für eine materialisierte Ansicht festlegen, wird der Teil der während der Materialisierung gescannten Ansicht reduziert. Anstatt die gesamte materialisierte Ansicht zu scannen, wird nur der Teil, der innerhalb des Lookbackzeitraums liegt, mit dem Delta während der Materialisierung kombiniert. Weitere Informationen finden Sie unter "Funktionsweise materialisierter Ansichten". Während dieser Schritt die Leistung der materialisierten Ansicht erheblich verbessern kann, kann das Festlegen eines falschen Lookbackzeitraums zu doppelten Datensätzen führen. Wenn im vorherigen Beispiel zwei Tage nach einem Datensatz für denselben SessionIdDatensatz aufgenommen wird, enthält die materialisierte Ansicht doppelte Datensätze dafür SessionId.

Lookbackspalte

Der Nachschlagezeitraum ist immer relativ zu einer datetime Spalte in der materialisierten Ansicht. Es gibt zwei Möglichkeiten, diese Spalte zu definieren:

• Vorgabe: Relativ zur ingestion_time() des Datensatzes in der Quelltabelle. Datensätze werden nur für Datensätze dedupliziert, die nach einem Nachschlagezeitraum relativ zu den aktuellen Datensätzen in die Quelltabelle aufgenommen werden. Diese Art von Lookback ist nur für arg_maxAnsichten gültig, arg_minoder take_any materialisierte Ansichten und nur für Ansichten, die die Aufnahmezeit beibehalten. Weitere Informationen finden Sie unter Einschränkungen für materialisierte Ansichten und bekannte Probleme. Sie können die Standardoption konfigurieren, indem Sie die lookback Eigenschaft ohne die lookback_column Eigenschaft festlegen.

• lookback_column (Vorschau): Relativ zu einer datetime Spalte in der materialisierten Ansicht. Der Lookback wird explizit in der materialisierten Ansichtsdefinition mithilfe der lookback_column Eigenschaft angegeben. Weitere Informationen finden Sie unter Bekannte Einschränkungen. Sie können die Lookbackspaltenoption konfigurieren, indem Sie sowohl die Eigenschaften als auch die lookbacklookback_column Eigenschaften festlegen.

Bekannte Einschränkungen

• Nachdem ein lookback_column Wert definiert wurde, können Sie den Wert nicht mehr ändern.
• Die Verwendung eines lookback_column Steuerelements kann zu Duplikaten führen, wenn die Spalte Werte enthält datetime(null) . In solchen Fällen kann die Ansicht für eine bestimmte Kombination von Gruppenschlüsseln mit einem Datensatz mit einem datetime(null) Wert und einem anderen mit einem Wert ungleich NULL enden.

Materialisierte Ansicht über materialisierte Ansicht erstellen

Sie können eine materialisierte Ansicht nur dann über eine andere materialisierte Ansicht erstellen, wenn es sich bei der materialisierten Quellansicht um eine take_any(*) Aggregation (Deduplizierung) handelt. Weitere Informationen finden Sie unter Materialisierte Ansicht über materialisierte Ansicht und Beispiele.

Syntax:

.create[] [asyncifnotexists] materialized-view [ with(PropertyName= PropertyValue,...] )

Parameter:

Name	Typ	Erforderlich	Beschreibung
PropertyName, PropertyValue	string		Liste der Eigenschaften in Form von Namen- und Wertpaaren aus der Liste der unterstützten Eigenschaften.
MaterializedViewName-	string	✔️	Name der materialisierten Ansicht. Der Ansichtsname kann nicht mit Tabellen- oder Funktionsnamen in derselben Datenbank in Konflikt geraten und muss den Benennungsregeln des Bezeichners entsprechen.
SourceMaterializedViewName	string	✔️	Name der materialisierten Quellansicht, für die die Ansicht definiert ist.
Abfrage	string	✔️	Abfragedefinition der materialisierten Ansicht.

Beispiele

• Erstellen Sie eine leere arg_max Ansicht, die nur datensätze materialisiert, die von jetzt an aufgenommen wurden:

  .create materialized-view ArgMax on table T
  {
      T | summarize arg_max(Timestamp, *) by User
  }
  

• Erstellen Sie eine materialisierte Ansicht für tägliche Aggregate mit der Option "Rückfüllen", indem Sie Folgendes verwenden 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 
  } 
  

• Erstellen Sie eine materialisierte Ansicht mit backfill und effectiveDateTime. Die Ansicht wird basierend auf Datensätzen nur aus datumszeit erstellt.

  .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
  } 
  

• Erstellen Sie eine materialisierte Ansicht, die die Quelltabelle basierend auf der EventId Spalte mithilfe eines Lookbacks von sechs Stunden dedupliziert. Datensätze werden nur für Datensätze dedupliziert, die sechs Stunden vor den aktuellen Datensätzen aufgenommen wurden.

  .create materialized-view with(lookback=6h) DeduplicatedTable on table T
  {
      T
      | summarize take_any(*) by EventId
  }
  

• Erstellen Sie eine materialisierte Downsampling-Ansicht basierend auf der DeduplicatedTable materialisierten Ansicht:

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

• Erstellen Sie eine materialisierte Ansicht, die die Quelltabelle basierend auf der EventId Spalte mithilfe eines Lookbacks von sechs Stunden dedupliziert. Datensätze werden mit Datensätzen dedupliziert, deren Timestamp maximale sechs Stunden Unterschied zu den aktuellen Datensätzen beträgt.

  .create materialized-view with(lookback=6h, lookback_column = "Timestamp") LatestEventID on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  }
  

• Die Definition kann zusätzliche Operatoren vor der summarize Anweisung enthalten, sofern summarize die letzte ist:

  .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
  }
  

• Hier sind materialisierte Ansichten, die mit einer Dimensionstabelle verknüpft werden:

  .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 
  }
  

Hinweise

Query parameter (Abfrageparameter)

Die folgenden Regeln beschränken die Abfrage, die im parameter für die materialisierte Ansichtsabfrage verwendet wird:

• Die Abfrage sollte auf eine einzelne Faktentabelle verweisen, die die Quelle der materialisierten Ansicht ist. Sie sollte einen einzelnen summarize Operator und eine oder mehrere Aggregationsfunktionen enthalten, die von einer oder mehreren Gruppen nach Ausdrücken aggregiert werden. Der summarize Operator muss immer der letzte Operator in der Abfrage sein.

  Eine materialisierte Ansicht, die nur eine einzelne arg_max/arg_min/take_any Aggregation enthält, kann besser als eine materialisierte Ansicht sein, die diese Aggregationen zusammen mit anderen Aggregationen (zcount/dcount/avg. B. ) enthält. Dies liegt daran, dass einige Optimierungen nur für diese Arten materialisierter Ansichten relevant sind. Sie gelten nicht, wenn die Ansicht gemischte Aggregationsfunktionen enthält (wobei gemischte Mittel sowohl als aucharg_max/arg_min/ andere Aggregationen in derselben Ansicht verwendet werden).take_any

• Die Abfrage sollte keine Operatoren enthalten, von now()denen abhängig ist. Die Abfrage sollte z. B. nicht enthalten where Timestamp > ago(5d)sein. Verwenden Sie die Aufbewahrungsrichtlinie für die materialisierte Ansicht, um den Zeitraum zu begrenzen, den die Ansicht abdeckt.

• Die folgenden Operatoren werden in der materialisierten Ansichtsabfrage nicht unterstützt: sort, , top-nested, top, . partitionserialize

• Zusammengesetzte Aggregationen werden in der Definition der materialisierten Ansicht nicht unterstützt. Definieren Sie z. B. anstelle der Verwendung SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Iddie materialisierte Ansicht als: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Führen Sie während der Ansichtsabfragezeit die Ausführung aus MaterializedViewName | project Id, Result=a/b. Die erforderliche Ausgabe der Ansicht, einschließlich der berechneten Spalte (a/b), kann in einer gespeicherten Funktion gekapselt werden. Greifen Sie auf die gespeicherte Funktion zu, anstatt direkt auf die materialisierte Ansicht zuzugreifen.

• Cross-Eventhouse- und datenbankübergreifende Abfragen werden nicht unterstützt.

• Verweise auf external_table() und externe Daten werden nicht unterstützt.

• Die materialisierte Ansichtsabfrage kann keine Beschriftungen enthalten, die einen Identitätswechsel erfordern. Insbesondere sind alle Abfragekonnektivitäts-Plug-Ins , die Identitätswechsel verwenden, nicht zulässig.

• Zusätzlich zur Quelltabelle der Ansicht darf die Abfrage auf eine oder mehrere Dimensionstabellen verweisen. Bemaßungstabellen müssen in den Ansichtseigenschaften explizit aufgerufen werden. Es ist wichtig, das folgende Verhalten zu verstehen, wenn Sie mit Dimensionstabellen verknüpfen:

  • Datensätze in der Quelltabelle der Ansicht (die Faktentabelle) werden nur einmal materialisiert. Aktualisierungen der Dimensionstabellen haben keine Auswirkungen auf Datensätze, die bereits aus der Faktentabelle verarbeitet wurden.

  • Eine andere Aufnahmelatenz zwischen der Faktentabelle und der Dimensionstabelle kann sich auf die Ansichtsergebnisse auswirken.

    Beispiel: Eine Ansichtsdefinition enthält eine innere Verknüpfung mit einer Dimensionstabelle. Zum Zeitpunkt der Materialisierung wurde der Dimensionsdatensatz nicht vollständig aufgenommen, aber er wurde bereits in die Faktentabelle aufgenommen. Dieser Datensatz wird aus der Ansicht gelöscht und nie wieder verarbeitet.

    Wenn es sich bei der Verknüpfung um eine äußere Verknüpfung handelt, werden die Datensätze aus der Faktentabelle verarbeitet und zum Anzeigen mit einem Nullwert für die Dimensionstabellenspalten hinzugefügt. Datensätze, die der Ansicht bereits hinzugefügt wurden (mit NULL-Werten), werden nicht erneut verarbeitet. Ihre Werte in Spalten aus der Dimensionstabelle bleiben null.

Unterstützte Aggregationsfunktionen

Die folgenden Aggregationsfunktionen werden unterstützt:

• count
• countif
• dcount
• dcountif
• min
• max
• avg
• avgif
• sum
• sumif
• arg_max
• arg_min
• take_any
• take_anyif
• hll
• make_set
• make_list
• make_bag
• percentile, percentiles
• tdigest

Leistungstipps

• Verwenden Sie eine Datetime-Gruppe nach Schlüssel: Materialisierte Ansichten, die eine datetime Spalte als eine ihrer Schlüssel gruppieren, sind effizienter als diejenigen, die nicht. Der Grund dafür ist, dass einige Optimierungen nur angewendet werden können, wenn eine Datetime-Gruppe nach Schlüssel vorhanden ist. Wenn das Hinzufügen eines Datetime-nach-Schlüssels die Semantik Ihrer Aggregation nicht ändert, empfehlen wir, sie hinzuzufügen. Dies ist nur möglich, wenn die datetime Spalte für jede eindeutige Entität unveränderlich ist.

  Beispiel: In der folgenden Aggregation:

      SourceTable | summarize take_any(*) by EventId
  

  Wenn EventId immer derselbe Timestamp Wert vorhanden ist und daher das Hinzufügen Timestamp die Semantik der Aggregation nicht ändert, ist es besser, die Ansicht zu definieren als:

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  Tipp

  Verspätete Daten in einer Datetime-Gruppe nach Schlüssel können sich negativ auf die Leistung der materialisierten Ansicht auswirken. Gehen Sie beispielsweise davon aus, dass eine materialisierte Ansicht als eine ihrer Gruppenschlüssel verwendet bin(Timestamp, 1d) wird und neu aufgenommene Datensätze in der Quelltabelle alte Timestamp Werte aufweisen. Diese Datensätze können sich negativ auf die materialisierte Ansicht auswirken.

  Wenn Sie erwarten, dass die eingehenden Datensätze spät in die Quelltabelle aufgenommen wurden, passen Sie die Zwischenspeicherungsrichtlinie der materialisierten Ansicht entsprechend an. Wenn z. B. Datensätze mit dem Zeitstempel vor sechs Monaten in die Quelltabelle aufgenommen werden sollen, muss der Materialisierungsprozess die materialisierte Ansicht für die vorherigen sechs Monate scannen. Wenn sich dieser Zeitraum im kalten Cache befindet, fehlt der Cache für materialisierungsfunktionen, die sich negativ auf die Leistung der Ansicht auswirken.

  Wenn solche spät eingehenden Datensätze nicht erwartet werden, empfehlen wir dies in der materialisierten Ansichtsabfrage. Filtern Sie diese Datensätze aus, oder normalisieren Sie deren Zeitstempelwerte auf die aktuelle Uhrzeit.

• Definieren Sie einen Lookbackzeitraum: Falls für Ihr Szenario zutreffend, kann das Hinzufügen einer lookback Eigenschaft die Abfrageleistung erheblich verbessern. Ausführliche Informationen finden Sie unter "Unterstützte Eigenschaften".

• Hinzufügen von Spalten, die häufig zum Filtern als Gruppenschlüssel verwendet werden: Materialisierte Ansichtsabfragen werden optimiert, wenn sie nach einer der materialisierten Schlüssel gefiltert werden. Wenn Sie wissen, dass Ihr Abfragemuster häufig nach einer Spalte gefiltert wird, die gemäß einer eindeutigen Entität in der materialisierten Ansicht unveränderlich ist, fügen Sie es in die Gruppenschlüssel der materialisierten Ansicht ein.

  Beispielsweise wird eine materialisierte Ansicht durch einen arg_max Wert verfügbar ResourceId gemacht, der häufig nach SubscriptionIdgefiltert wird. Wenn angenommen wird, dass ein ResourceId Wert immer zum gleichen SubscriptionId Wert gehört, definieren Sie die materialisierte Ansichtsabfrage wie:

  .create materialized-view ArgMaxResourceId on table FactResources
  {
      FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
  }
  

  Die vorangehende Definition ist vorzuziehen:

  .create materialized-view ArgMaxResourceId on table FactResources
  {
      FactResources | summarize arg_max(Timestamp, *) by ResourceId 
  }
  

• Verwenden Sie ggf. Aktualisierungsrichtlinien: Die materialisierte Ansicht kann Transformationen, Normalisierungen und Nachschlagevorgänge in Dimensionstabellen enthalten. Es wird jedoch empfohlen, diese Vorgänge in eine Updaterichtlinie zu verschieben. Lassen Sie nur die Aggregation für die materialisierte Ansicht.

  Beispielsweise ist es besser, die folgende Updaterichtlinie zu definieren:

  .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}]'  
  

  Und definieren Sie die folgende materialisierte Ansicht:

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

  Die Alternative, die Aktualisierungsrichtlinie als Teil der materialisierten Ansichtsabfrage einzuführen, kann schlimmer und daher nicht empfohlen werden:

  .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
  }
  

Tipp

Wenn Sie die beste Abfragezeitleistung benötigen, aber einige Datenlatenz tolerieren können, verwenden Sie die funktion materialized_view()

Zurückfüllen einer materialisierten Ansicht

Wenn Sie mithilfe der backfill Eigenschaft eine materialisierte Ansicht erstellen, wird die materialisierte Ansicht basierend auf den in der Quelltabelle verfügbaren Datensätzen erstellt. Oder es wird basierend auf einer Teilmenge dieser Datensätze erstellt, wenn Sie diese verwenden effectiveDateTime.

Hinter den Kulissen teilt der Backfill-Prozess die Daten in mehrere Batches auf und führt mehrere Aufnahmevorgänge aus, um die Ansicht zu sichern. Der Vorgang kann lange dauern, bis die Anzahl der Datensätze in der Quelltabelle groß ist. Die Prozessdauer hängt von der Datenbankgröße ab. Verfolgen Sie den Fortschritt des Ausfüllvorgangs mithilfe des .show operations Befehls.

Vorübergehende Fehler, die im Rahmen des Rückfüllvorgangs auftreten, werden wiederholt. Wenn alle Wiederholungen erschöpft sind, schlägt der Befehl fehl und erfordert eine manuelle erneute Ausführung des Befehls "Erstellen".

Es wird nicht empfohlen, dass Sie backfill verwenden, wenn die Anzahl der Datensätze in der Quelltabelle überschritten wird number-of-nodes X 200 million (manchmal sogar weniger, abhängig von der Komplexität der Abfrage). Eine Alternative ist die Option "Backfill by move extents ".

Die Verwendung der Option "Rückfüllen" wird für Daten in einem kalten Cache nicht unterstützt. Erhöhen Sie den heißen Cachezeitraum bei Bedarf während der Ansichtserstellung. Dies kann eine Skalierung erfordern.

Wenn fehler beim Erstellen der Ansicht auftreten, versuchen Sie, diese Eigenschaften zu ändern:

• MaxSourceRecordsForSingleIngest: Standardmäßig beträgt die Anzahl der Quelldatensätze bei jedem Aufnahmevorgang während des Rückfüllvorgangs 2 Millionen pro Knoten. Sie können diese Standardeinstellung ändern, indem Sie diese Eigenschaft auf die gewünschte Anzahl von Datensätzen festlegen. (Der Wert ist die Gesamtanzahl der Datensätze in jedem Aufnahmevorgang.)

  Das Verringern dieses Werts kann hilfreich sein, wenn die Erstellung bei Speicherlimits oder Abfragetimeouts fehlschlägt. Wenn Sie diesen Wert erhöhen, kann die Erstellung der Ansicht beschleunigt werden, vorausgesetzt, die Datenbank kann die Aggregationsfunktion für mehr Datensätze ausführen als die Standardeinstellung.

• Concurrency: Die Aufnahmevorgänge, die als Teil des Backfill-Prozesses ausgeführt werden, werden gleichzeitig ausgeführt. Standardmäßig ist min(number_of_nodes * 2, 5)die Parallelität . Sie können diese Eigenschaft festlegen, um die Parallelität zu erhöhen oder zu verringern. Es wird empfohlen, diesen Wert nur zu erhöhen, wenn die CPU der Datenbank niedrig ist, da sich die Erhöhung erheblich auf den CPU-Verbrauch der Datenbank auswirken kann.

Beispielsweise füllt der folgende Befehl die materialisierte Ansicht aus 2020-01-01. Die maximale Anzahl von Datensätzen in jedem Aufnahmevorgang beträgt 3 Millionen. Der Befehl führt die Aufnahmevorgänge mit Parallelität von 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)
} 

Wenn die materialisierte Ansicht einen Datetime-nach-Schlüssel enthält, unterstützt der Backfill-Prozess das Überschreiben der Erstellungszeit auf der Grundlage der Datetime-Spalte. Dies kann z. B. hilfreich sein, wenn ältere Datensätze vor den letzten Datensätzen verworfen werden sollen, da die Aufbewahrungsrichtlinie auf dem Umfang der Erstellungszeit basiert. Die updateExtentsCreationTime Eigenschaft wird nur unterstützt, wenn die Ansicht eine Datetime-Gruppe nach Schlüssel enthält, die die bin() Funktion verwendet. Mit dem folgenden Backfill wird z. B. die Erstellungszeit basierend auf dem Timestamp Schlüssel "Gruppieren nach" zugewiesen:

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

Zurückfüllen nach Verschiebungsausdehnungen

Die Option zum Zurückfüllen durch Verschieben von Ausmaßen füllt die materialisierte Ansicht basierend auf einer vorhandenen Tabelle, die nicht unbedingt die Quelltabelle der materialisierten Ansicht ist. Sie erreichen das Ausfüllen, indem Sie Ausdehnungen aus der angegebenen Tabelle in die zugrunde liegende materialisierte Ansichtstabelle verschieben. Dieser Prozess impliziert Folgendes:

• Die Daten in der angegebenen Tabelle sollten dasselbe Schema wie das materialisierte Ansichtsschema aufweisen.
• Datensätze in der angegebenen Tabelle werden wie folgt in die Ansicht verschoben. Es wird angenommen, dass sie basierend auf der Definition der materialisierten Ansicht dedupt werden.

Beispiel: Wenn die materialisierte Ansicht die folgende Aggregation aufweist:

T | summarize arg_max(Timestamp, *) by EventId

Dann sollten die Datensätze in der Quelltabelle für den Vorgang "Verschiebungsausdehnungen" bereits dedupt EventIDwerden.

Da der Vorgang ".move extents" verwendet, werden die Datensätze während des Nachfüllvorgangs (verschoben, nicht kopiert) aus der angegebenen Tabelle entfernt .

Das Ausfüllen durch Verschiebungsausdehnungen wird für alle Aggregationsfunktionen, die in materialisierten Ansichten unterstützt werden, nicht unterstützt. Es schlägt bei Aggregationen wie avg(), dcount()in denen die zugrunde liegenden Daten, die in der Ansicht gespeichert sind, nicht von der Aggregation selbst ab.

Die materialisierte Ansicht wird nur basierend auf der angegebenen Tabelle ausgefüllt. Die Materialisierung von Datensätzen in der Quelltabelle der Ansicht beginnt standardmäßig mit der Erstellungszeit der Ansicht.

Wenn die Quelltabelle der materialisierten Ansicht kontinuierlich Daten erfasst, kann das Erstellen der Ansicht mithilfe von Verschiebungsausdehnungen zu einem Datenverlust führen. Dies liegt daran, dass Datensätze, die in die Quelltabelle aufgenommen wurden, in kürzester Zeit zwischen dem Zeitpunkt der Vorbereitung der Tabelle zum Zurückfüllen und der Zeit, aus der die Ansicht erstellt wird, nicht in der materialisierten Ansicht enthalten sind. Um dieses Szenario zu behandeln, können Sie die source_ingestion_time_from Eigenschaft auf die Startzeit der materialisierten Ansicht über die Quelltabelle festlegen.

Anwendungsfälle

Die Option zum Zurückfüllen nach Verschiebungsumfang kann in zwei Hauptszenarien nützlich sein:

• Wenn Sie bereits über eine Tabelle verfügen, die die deduplizierten Quelldaten für die materialisierte Ansicht enthält, und Sie diese Datensätze in dieser Tabelle nach der Erstellung der Ansicht nicht benötigen, da Sie nur die materialisierte Ansicht verwenden.

• Wenn die Quelltabelle der materialisierten Ansicht sehr groß ist und das Ausfüllen der Ansicht basierend auf der Quelltabelle aufgrund der oben genannten Einschränkungen nicht gut funktioniert. In diesem Fall können Sie den Backfill-Prozess selbst in einer temporären Tabelle mithilfe von Abfragebefehlen koordinieren. Wenn die temporäre Tabelle alle Datensätze für das Rückfüllen enthält, erstellen Sie die materialisierte Ansicht basierend auf dieser Tabelle.

Beispiele:

• Im folgenden Beispiel enthält die Tabelle DeduplicatedTable einen einzelnen Datensatz pro EventId Instanz und wird als Basisplan für die materialisierte Ansicht verwendet. Nur Datensätze, die T nach der Erstellungszeit der Ansicht aufgenommen werden, sind in der materialisierten Ansicht enthalten.

  .create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  } 
  

• Wenn die effectiveDateTime Eigenschaft zusammen mit der move_extents_from Eigenschaft angegeben wird, werden nur Erweiterungen verwendet, deren DeduplicatedTableMaxCreatedOn Wert größer ist als effectiveDateTime in der Backfill-Ansicht (in die materialisierte Ansicht verschoben):

  .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
  } 
  

• Im folgenden Beispiel wird die Verwendung der source_ingestion_time_from Eigenschaft in der Option zum Zurückfüllen durch Verschiebungsausdehnungen veranschaulicht. Verwenden Sie beide und source_ingestion_time_frommove_extents_from gibt an, dass die materialisierte Ansicht aus zwei Quellen ausgefüllt wird:

  • Die move_extents_from Tabelle: DeduplicatedTable im folgenden Beispiel. Diese Tabelle sollte alle historischen Daten enthalten, die zurückgefüllt werden sollen. Optional können Sie die effectiveDateTime Eigenschaft verwenden, um nur Erweiterungen einzuschließen, deren DeduplicatedTableMaxCreatedOn Wert größer als effectiveDateTimeist.

  • Die Quelltabelle der materialisierten Ansicht: T im folgenden Beispiel. Das Ausfüllen aus dieser Tabelle enthält nur Datensätze, deren ingestion_time()- Wert größer als source_ingestion_time_fromist.

    Die source_ingestion_time_from Eigenschaft sollte nur verwendet werden, um den möglichen Datenverlust in kürzester Zeit zwischen der Vorbereitung der Tabelle für das Zurückfüllen von (DeduplicatedTable) und der Zeit, zu der die Ansicht erstellt wird, zu behandeln. Legen Sie diese Eigenschaft in der Vergangenheit nicht zu weit fest. Dies würde die materialisierte Ansicht mit einem erheblichen Verzögerung beginnen, was schwierig sein könnte, aufzuholen.

  Gehen Sie im folgenden Beispiel davon aus, dass die aktuelle Uhrzeit lautet 2020-01-01 03:00. Tabelle DeduplicatedTable ist eine dedupte Tabelle von T. Es enthält alle historischen Daten, die bis zum Deduplizieren dedupliziert wurden 2020-01-01 00:00. Der create Befehl wird zum Zurückfüllen der materialisierten Ansicht mithilfe von Verschiebungsausdehnungen verwendet DeduplicatedTable . Der create Befehl enthält auch alle Datensätze, die T seitdem 2020-01-01aufgenommen wurden.

  .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
  } 
  

Materialisierte Ansichtserstellung abbrechen

Sie können den Prozess der materialisierten Ansichtserstellung abbrechen, wenn Sie die Option "Rückfüllen" verwenden. Diese Aktion ist nützlich, wenn die Erstellung zu lange dauert und Sie sie während der Ausführung beenden möchten.

Warnung

Die materialisierte Ansicht kann nicht wiederhergestellt werden, nachdem Sie diesen Befehl ausgeführt haben.

Der Erstellungsprozess kann nicht sofort abgebrochen werden. Der Befehl "Abbrechen" signalisiert die Materialisierung, und die Erstellung überprüft regelmäßig, ob ein Abbruch angefordert wurde. Der Befehl "Abbrechen" wartet auf einen maximalen Zeitraum von 10 Minuten, bis der materialisierte Ansichtserstellungsprozess abgebrochen wird. Er meldet zurück, wenn der Abbruch erfolgreich war.

Auch wenn der Abbruch nicht innerhalb von 10 Minuten erfolgreich ist und der Fehler des Abbruchbefehls meldet, wird die materialisierte Ansicht wahrscheinlich später im Erstellungsprozess abgebrochen. Der .show operations Befehl gibt an, ob der Vorgang abgebrochen wurde.

Wenn der Vorgang nicht mehr ausgeführt wird, wenn der .cancel operation Befehl ausgegeben wird, meldet der Befehl einen Fehler.

Syntax

.cancel operation operationId

Erfahren Sie mehr über Syntaxkonventionen.

Parameter

Name	Typ	Erforderlich	Beschreibung
operationId	guid	✔️	Die vom Befehl zurückgegebene Vorgangs-ID .create async materialized-view .

Ausgabe

Name	Typ	Beschreibung
OperationId	guid	Die Vorgangs-ID des .create materialized-view Befehls.
Vorgang	string	Der Typ des Vorgangs.
StartedOn	datetime	Die Startzeit des Erstellungsvorgangs.
CancellationState	string	Einer von: Canceled successfully (Die Erstellung wurde abgebrochen), Cancellation failed (Auf Abbruchzeit warten), Unknown (die Erstellung der Ansicht wird nicht mehr ausgeführt, wurde aber von diesem Vorgang nicht abgebrochen).
ReasonPhrase	string	Der Grund, warum die Stornierung nicht erfolgreich war.

Beispiele

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

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

Wenn der Abbruch nicht innerhalb von 10 Minuten abgeschlossen ist, CancellationState wird ein Fehler angezeigt. Die Erstellung kann dann abgebrochen werden.

Verwandte Inhalte

• Materialisierte Ansichten
• Materialisierte Ansichten Anwendungsfälle
• .alter materialized-view
• .drop materialized-view
• .show materialized-view(s)