.create materialized-view

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 erst für Abfragen 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

Für diesen Befehl sind Datenbankadministratorberechtigungen erforderlich. Der Ersteller der materialisierten Ansicht wird zum Administrator der Ansicht.

Syntax

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

Erfahren Sie mehr über Syntaxkonventionen.

Parameter

Name	Type	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 sie festgelegt ist, füllt die Erstellung nur datensätze aus, die nach der Datumszeit 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 sie festgelegt trueist, wird die Zeit für die Erstellung des Umfangs basierend auf dem Schlüssel "datetime" während des Backfill-Prozesses zugewiesen. Weitere Informationen finden Sie unter "Zurückfüllen einer materialisierten Ansicht".
Lookback	timespan	Nur für arg_max//arg_mintake_any materialisierte Ansichten gültig. Er begrenzt den Zeitraum, in dem Duplikate erwartet werden. Wenn beispielsweise ein Lookback von 6 Stunden in einer arg_max Ansicht angegeben ist, berücksichtigt die Deduplizierung zwischen neu aufgenommenen Datensätzen und vorhandenen Datensätzen nur Datensätze, die vor bis zu 6 Stunden aufgenommen wurden. Lookback ist relativ zu ingestion_time. Das Falsche Definieren des Lookbackzeitraums kann zu Duplikaten in der materialisierten Ansicht führen. Wenn z. B. ein Datensatz für einen bestimmten Schlüssel 10 Stunden nach aufnahme eines Datensatzes für denselben Schlüssel aufgenommen wurde und der Lookback auf 6 Stunden festgelegt ist, wird dieser Schlüssel in der Ansicht ein Duplikat sein. Der Lookbackzeitraum wird sowohl während der Materialisierungszeit als auch während der Abfragezeit angewendet.
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.
folder	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 "Materialisierte Ansicht aktivieren" verwenden.

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,...] )MaterializedViewName SourceMaterializedViewName { Query on materialized-view }

Parameter:

Name	Type	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 ab jetzt 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 6 Stunden dedupliziert. Datensätze werden nur mit Datensätzen dedupliziert, die 6 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, die auf der vorherigen DeduplicatedTable materialisierten Ansicht basiert:

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

• 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_mintake_any Aggregation enthält, kann besser als eine materialisierte Ansicht sein, die diese Aggregationen zusammen mit anderen Aggregationen (zavgcount/dcount/. 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 auchtake_any//arg_maxarg_min andere Aggregationen in derselben Ansicht verwendet werden).

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

• Clusterübergreifende 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, wird der Datensatz 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 Gruppierungen nach Schlüsseln verwendet bin(Timestamp, 1d) wird und mehrere Ausreißer in den Daten sehr alte Timestamp Werte aufweisen. Diese Ausreißer können sich negativ auf die materialisierte Ansicht auswirken.

  Es wird empfohlen, dass Sie in der materialisierten Ansichtsabfrage entweder die Ausreißereinträge herausfiltern oder diese Datensätze auf die aktuelle Uhrzeit normalisieren.

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

  Eine materialisierte Ansicht wird arg_max z. B. durch einen ResourceId Wert verfügbar gemacht, nach SubscriptionIddem häufig gefiltert 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 sie 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 Clustergröß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 Erstellungsbefehls.

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, falls erforderlich, für die Dauer 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, dass der Cluster die Aggregationsfunktion für mehr Datensätze ausführen kann 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 des Clusters niedrig ist, da sich die Erhöhung erheblich auf den CPU-Verbrauch des Clusters 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. Der folgende Backfill weist z. B. erstellungszeit basierend auf dem Timestamp Schlüssel "Gruppieren nach" zu:

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

Für alle Aggregationsfunktionen, die in materialisierten Ansichten unterstützt werden, wird das Ausfüllen durch Verschiebungsausdehnungen nicht unterstützt. Für Aggregationen wie avg(), dcount()in denen die in der Ansicht gespeicherten zugrunde liegenden Daten anders sind als die Aggregation selbst, tritt ein Fehler auf.

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 die materialisierte Ansicht einbezogen werden. 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 koordinieren, indem Sie abfragebefehle und eines der empfohlenen Orchestrierungstools verwenden. 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, werden in die materialisierte Ansicht einbezogen.

  .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 DeduplicatedTable MaxCreatedOn 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_from move_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 DeduplicatedTable MaxCreatedOn 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, und er meldet, ob 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, der dies sagt.

Syntax

.cancel operationoperationId

Erfahren Sie mehr über Syntaxkonventionen.

Parameter

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

Output

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 wurde, CancellationState wird ein Fehler angezeigt. Die Erstellung kann dann abgebrochen werden.