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

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

Unterstützte Eigenschaften

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

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:

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.

• 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 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, tritt für die Materialisierung Cachefehler auf, die sich negativ auf die Leistung der Ansicht auswirken.

  Wenn solche spät eingehenden Datensätze nicht erwartet werden, empfehlen wir, dass Sie in der materialisierten Ansichtsabfrage diese Datensätze herausfiltern oder ihre Zeitstempelwerte 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
  }
  

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 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 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, 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 dann zu erhöhen, wenn die CPU der Datenbsen 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. 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 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, 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.

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

Output

Beispiele

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

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