Materialisierte Ansichten optimieren

Wechseln Sie zwischen Diensten über die Dropdown-Liste Version. Weitere Informationen zur Navigation.
Gilt für: ✅ Microsoft Fabric ✅ Azure Data Explorer

Eine materialisierte Ansicht besteht aus einem materialisierten Teil und neu erfassten Quelldatensätzen, die noch nicht materialisiert sind und als Delta bezeichnet werden. Die Materialisierungsleistung hängt weitgehend von der Überlappung zwischen dem Delta und dem materialisierten Teil ab. Die Abfrageleistung hängt auch davon ab, diese Teile zu kombinieren, wenn Sie die gesamte Ansicht abfragen. Weitere Informationen finden Sie unter "Funktionsweise materialisierter Ansichten".

Verwenden Sie die folgenden Optimierungen, nachdem Sie die materialisierte Ansicht überwacht und die Ursache des Leistungsproblems identifiziert haben.

Erhöhen Sie das Speicherlimit für die Materialisierung

Standardmäßig schränkt die $materialized-views Workloadgruppe den Speicher-Höchstwert jedes Materialisierungsvorgangs auf 15 GB pro Knoten oder 50% des gesamten physischen Speichers des Knotens ein, je nachdem, was niedriger ist. Wenn die Materialisierung fehlschlägt, weil dieses Limit erreicht wird, erhöhen Sie MaxMemoryPerQueryPerNode in der Workloadgruppe:

.alter-merge workload_group ['$materialized-views'] ```
{
  "RequestLimitsPolicy": {
    "MaxMemoryPerQueryPerNode": {
      "Value": 34359738368
    }
  }
}
```

Im vorherigen Beispiel wird der Grenzwert auf 32 GB pro Knoten erhöht. Überwachen Sie andere Workloads nach dem Erhöhen des Grenzwerts. Weitere Informationen finden Sie unter Workloadgruppe Materialisierte Sichten.

Note

MaxMemoryPerQueryPerNode darf 50% des gesamt verfügbaren Arbeitsspeichers auf jedem Knoten nicht überschreiten. Ein Befehl, der einen höheren Wert angibt, schlägt die Überprüfung fehl.

Anpassen von Cacherichtlinien

Die Materialisierung kann verlangsamt werden, wenn Daten gescannt werden, die sich nicht im heißen Cache befinden. Legen Sie eine Zwischenspeicherungsrichtlinie fest, die den Zeitraum abdeckt, in dem der Materialisierungsprozess überprüft werden soll. Weitere Informationen finden Sie unter Cachingrichtlinie, .alter materialized-view policy caching und .alter table policy caching.

Die Zwischenspeicherungsrichtlinie der materialisierten Ansicht gilt nur für den materialisierten Teil. Die Quelltabelle stellt das Delta bereit und nimmt auch an Abfragen teil. Konfigurieren Sie daher auch die Zwischenspeicherungsrichtlinie der Quelltabelle für den erforderlichen Zeitraum. Weitere Informationen finden Sie unter Aufbewahrungs- und Zwischenspeicherungsrichtlinie.

Verwenden Sie einen Gruppierungsschlüssel für Datum und Uhrzeit

Materialisierte Ansichten, die eine Spalte datetime als Gruppierungsschlüssel enthalten, können die Menge der in jedem Zyklus gescannten materialisierten Daten reduzieren. Fügen Sie einen Datums-/Uhrzeit-Gruppierungsschlüssel nur hinzu, wenn er die Aggregationssemantik nicht verändert und der Wert für jede eindeutige Entität unveränderlich ist.

Note

Sie können die Gruppenschlüssel einer vorhandenen materialisierten Ansicht nicht ändern. Um diese Optimierung anzuwenden, erstellen Sie eine neue materialisierte Ansicht.

Wenn beispielsweise jeder EventId immer denselben Timestamp Wert hat, ändern Sie Folgendes:

SourceTable | summarize take_any(*) by EventId

to:

SourceTable | summarize take_any(*) by EventId, Timestamp

Tip

Verspätet eintreffende Daten in einer Datums-/Zeitgruppierung können die Materialisierungsleistung negativ beeinflussen. Wenn z. B. eine Ansicht nach bin(Timestamp, 1d) gruppiert und einen Datensatz mit einem Timestamp von vor sechs Monaten empfängt, muss der Materialisierungsprozess möglicherweise die vorangegangenen sechs Monate des materialisierten Teils scannen. Wenn sich dieser Zeitraum im kalten Cache befindet, verpasst der Cache die weitere langsame Materialisierung.

Wenn verspätet eintreffende Datensätze zu erwarten sind, konfigurieren Sie die Caching-Richtlinien für die materialisierte Ansicht und die Quelltabelle so, dass auch die ältesten erwarteten Werte abgedeckt sind. Wenn sie nicht erwartet werden, filtern Sie diese Datensätze aus, oder normalisieren Sie ihre Zeitstempelwerte in der materialisierten Ansichtsabfrage auf die aktuelle Uhrzeit.

Hinzufügen einer unveränderlichen Erstellungszeitgruppe nach Schlüssel

Wenn die meisten Aktualisierungen bei kürzlich erstellten Entitäten erfolgen, fügen Sie den GROUP-BY-Schlüsseln eine unveränderliche Spalte für den Erstellungszeitpunkt hinzu. Der Materialisierungsprozess verwendet die erste Datums-/Zeitgruppierung nach Schlüssel, berechnet seinen Minimalwert über das Delta und verwendet diesen Wert als untere Grenze der Verknüpfung mit dem materialisierten Teil.

Diese Änderung erfordert eine neue materialisierte Sicht, da die Gruppierungsschlüssel einer bestehenden Sicht nicht geändert werden können.

Diese Optimierung ist nicht die Eigenschaft lookback. Ein Gruppenschlüssel ändert die Aggregations granularität, während ein falsch konfigurierter Schlüssel lookback doppelte Datensätze erzeugen kann.

Für diese Optimierung wird nur der erste Group-by-Schlüssel für Datum/Uhrzeit verwendet, sodass die Reihenfolge der Group-by-Schlüssel für Datum/Uhrzeit bestimmt, welcher davon angewendet wird. Wenn die ausgewählte Spalte im Delta einen Nullwert enthält, wird die Optimierung für den gesamten Materialisierungszyklus stillschweigend übersprungen. Verwenden Sie diese Optimierung nicht, wenn die Erstellungszeit nicht in jedem Update enthalten ist oder wenn sie die Aggregationsemantik ändert.

Spät ankommende Datensätze mit alten Erstellungszeitwerten können auch den Nutzen für einen Zyklus reduzieren oder beseitigen. Ein einzelner alter Wert verschiebt die untere Grenze der Verknüpfung nach hinten, wodurch der Zyklus einen viel größeren Teil des materialisierten Teils scannen kann, ohne einen Fehler zu erzeugen.

Ziehen Sie beispielsweise Ticketbuchungen in Betracht, die bis zu zwei Jahre geändert werden können, obwohl die meisten Änderungen innerhalb von zwei Monaten nach der Buchung auftreten. Wenn jedes Update ein unveränderliches Booking_CreationTimestamp enthält, ändern Sie Folgendes:

summarize arg_max(Timestamp, *) by BookingId

to:

summarize arg_max(Timestamp, *) by BookingId, Booking_CreationTimestamp

Der Materialisierungsprozess kann dann den frühesten Booking_CreationTimestamp Wert im Delta als untere Grenze für die Verknüpfung verwenden, anstatt den gesamten zeitraum von zwei Jahren zu scannen.

Definieren eines Nachschlagezeitraums

Die lookback Eigenschaft begrenzt, wie viel des materialisierten Teils bei jedem Materialisierungszyklus durchsucht wird. Es verbessert die Materialisierungsleistung, nicht die Abfrageleistung.

Legen Sie den Lookback so lange fest, dass alle erwarteten Duplikate oder Updates eingeschlossen werden. Ein Lookback, der zu kurz ist, kann doppelte Datensätze erzeugen. Details und Einschränkungen für die Konfiguration finden Sie unter Lookback-Zeitraum.

Häufig gefilterte Spalten als Gruppierungsschlüssel hinzufügen

Abfragen werden optimiert, wenn sie nach einem Gruppierungsschlüssel für materialisierte Sichten gefiltert werden. Wenn Abfragen häufig anhand einer Spalte gefiltert werden, die für jede eindeutige Entität unveränderlich ist, schließen Sie diese Spalte in die GROUP-BY-Schlüssel ein.

Sie können die Gruppenschlüssel einer vorhandenen materialisierten Ansicht nicht ändern. Um diese Optimierung anzuwenden, erstellen Sie eine neue materialisierte Ansicht.

Wenn z. B. eine ResourceId Immer zur gleichen SubscriptionIdgehört, definieren Sie die materialisierte Ansicht wie:

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

Diese Definition ist einer Gruppierung nur nach ResourceId vorzuziehen, wenn Abfragen häufig nach SubscriptionId filtern.

Nicht aggregierte Arbeit aus der Ansicht heraus verschieben

Wenn die Abfrage nur ein Nachschlagen in einer Dimensionstabelle benötigt, verwenden Sie die Eigenschaft dimensionTables. Weitere Informationen finden Sie unter "Abfrageparameter".

Verwenden Sie für andere Transformationen und Normalisierungen eine Aktualisierungsrichtlinie , um die Daten in einer Zieltabelle vorzubereiten und nur die Aggregation in der materialisierten Ansicht zu belassen. Definieren Sie beispielsweise eine Updaterichtlinie:

.alter-merge table Target policy update
@'[{"IsEnabled":true,"Source":"SourceTable","Query":"SourceTable | extend NormalizedResourceId = toupper(ResourceId)","IsTransactional":false,"PropagateIngestionProperties":false}]'

Definieren Sie dann die materialisierte Ansicht über der vorbereiteten Tabelle:

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

Wenn Sie die Transformation direkt in die materialisierte Ansichtsabfrage einschließen, muss sie während jedes Materialisierungszyklus ausgeführt werden und kann schlechter ausgeführt werden.

Anwenden einer Partitionierungsrichtlinie

Erwägen Sie eine Partitionierungsrichtlinie, wenn die meisten Abfragen nach einem der Gruppenschlüssel der materialisierten Ansicht filtern. Diese Optimierung ist für Mehrinstanzendaten üblich, bei denen ein Schlüssel den Mandanten identifiziert.

Die Partitionierung behält eine einzelne materialisierte Ansicht bei und kann verhindern, dass die Daten über mehrere Ansichten verteilt werden. Sie erhöht jedoch die Anzahl der Ausmaße und schafft mehr Arbeit für den Materialisierungsprozess.

Erhöhen der verfügbaren Ressourcen

Wenn das Eventhouse nicht über genügend Ressourcen verfügt, um materialisierte Ansichten funktionsfähig zu halten, aktivieren Sie die Mindestnutzung, um mehr Ressourcen bereitzustellen. Weitere Informationen finden Sie unter Aktivieren der Mindestnutzung.

Wenn mehrere materialisierte Ansichten gleichzeitig ausgeführt werden müssen, stellen Sie sicher, dass die Kapazitätsrichtlinie für materialisierte Ansichten eine ausreichende Parallelität zulässt. Erhöhen Sie ClusterMinimumConcurrentOperations erst, nachdem Sie die Auswirkungen auf andere Workloads bewertet haben. Weitere Informationen finden Sie unter Kapazitätsrichtlinie für materialisierte Ansichten.

Aufteilen in mehrere materialisierte Ansichten

Die Aufteilung kann helfen, wenn der Materialisierungszyklus einer einzelnen materialisierten Ansicht zu viel Arbeitsspeicher benötigt und die vorherigen Optimierungen nicht ausreichen. Die Aufteilung muss die Anzahl der Gruppen und die Zustandsmenge verringern, die jede materialisierte Ansicht verarbeitet. Teilen Sie die KQL nicht in Verarbeitungsphasen auf.

Während die Aufteilung die CPU-Auslastung erhöhen kann, reduziert sie den Speicherspitzen in Materialisierungszyklen. Stellen Sie sicher, dass ClusterMinimumConcurrentOperations die geteilten Ansichten parallel ausführen kann. Andernfalls können die Ansichten fortlaufend ausgeführt werden und verlieren den Vorteil der Aufteilung.

Stellen Sie für eine der beiden Aufteilungsmethoden folgendes sicher:

• Der Partitionsausdruck ist deterministisch und bleibt während der gesamten Lebensdauer der Ansichten unverändert.
• Der Partitionsschlüssel ist Teil des Gruppierungsschlüssels.
• Die Verteilung ist vernünftig ausgewogen.

Vermeiden Sie eine zufällige Aufteilung oder eine Aufteilung anhand eines Werts, der sich innerhalb derselben logischen Gruppe ändern kann.

Horizontal anhand eines stabilen Schlüssels partitionieren

Angenommen, die ursprüngliche materialisierte Ansicht lautet:

.create materialized-view UsageMV on table Events
{
    Events
    | summarize EventCount = count(), TotalBytes = sum(Bytes)
        by TenantId, Day = bin(Timestamp, 1d)
}

Die Mandanten werden deterministisch auf vier materialisierte Sichten aufgeteilt, indem hash_xxhash64() verwendet wird:

.create materialized-view UsageMV_0 on table Events
{
    Events
    | where hash_xxhash64(TenantId, 4) == 0
    | summarize EventCount = count(), TotalBytes = sum(Bytes)
        by TenantId, Day = bin(Timestamp, 1d)
}

Erstellen Sie entsprechende materialisierte Ansichten für Buckets 1, 2 und 3, und machen Sie sie über eine Funktion verfügbar:

.create-or-alter function Usage()
{
    union UsageMV_0, UsageMV_1, UsageMV_2, UsageMV_3
}

Da jede Gruppe zu genau einer materialisierten Ansicht gehört, ist keine endgültige Neuaggregation erforderlich. Die Hashfunktion und die Bucketanzahl müssen über die gesamte Lebensdauer der Ansichten festgelegt bleiben. Wenn Sie eine der beiden Optionen ändern, kann dadurch eine vorhandene Gruppe einer anderen Ansicht zugewiesen werden, sodass Sie alle Shard-Ansichten neu erstellen und neu auffüllen müssen.

Aufteilen nach einer natürlichen geschäftlichen Abgrenzung

Diese Methode ist in der Regel klarer als Hashing:

.create materialized-view Usage_EU on table Events
{
    Events
    | where Region == "EU"
    | summarize count(), sum(Bytes)
        by Region, TenantId, Day = bin(Timestamp, 1d)
}

Erstellen Sie entsprechende Ansichten für die anderen Regionen. Diese Methode funktioniert am besten, wenn Abfragen häufig nach dem Partitionsschlüssel gefiltert werden.

Optimieren von Abfragen

Wenn Sie einige Datenlatenz tolerieren können, verwenden Sie die materialized_view() Funktion , um nur den materialisierten Teil abzufragen. Bei diesem Ansatz wird vermieden, den materialisierten Teil zur Abfragezeit mit dem Delta zu kombinieren.

Beim Abfragen der gesamten Ansicht sollten Sie nach Möglichkeit nach Gruppierungsschlüsseln filtern. Sie können auch die Clientanforderungseigenschaft materialized_view_shuffle testen, um die Shuffle-Strategie für die Zusammenfassungs- und Verknüpfungsvorgänge zu steuern. Geben Sie Schlüssel an, um das Verhalten ähnlich hint.shufflekeyzu erhalten, oder lassen Sie die Tasten weg, um das Verhalten ähnlich zu hint.strategy=shuffleerhalten. Ausführliche Informationen und Beispiele finden Sie unter Materialized View Query Optimizer.

Verwandte Inhalte

• Materialisierte Ansichten
• Anwendungsfälle für materialisierte Ansichten
• Materialisierte Ansichten überwachen
• Richtlinien für materialisierte Ansichten