Materialisierung für metrische Ansichten

Important

Dieses Feature befindet sich in der Public Preview.

Die Materialisierung für metrische Ansichten beschleunigt Abfragen mithilfe materialisierter Ansichten zur Vorberechnung von Aggregationen. Lakeflow-Pipelines orchestrieren benutzerdefinierte materialisierte Ansichten für eine gegebene Metrikansicht. Zum Abfragezeitpunkt leitet der Abfrageoptimierer Abfragen mithilfe der automatischen aggregatbewussten Abfragezuordnung (Abfrageumschreibung) an die am besten geeignete materialisierte Ansicht weiter. Sie fragen die Metrikansicht wie gewohnt ohne zusätzlichen manuellen Aufwand ab. Databricks aktualisiert die Materialisierungen, um sie auf dem neuesten Stand zu halten. Außerdem wählt es aus, welche Materialisierung für schnellere Abfragen bei geringeren Kosten verwendet wird.

Funktionsweise der Materialisierung

Die Materialisierung für metrische Ansichten umfasst zwei Phasen: Definieren der Materialisierung und Ausführen von Abfragen.

Definitionsphase

Wenn Sie eine Metrikansicht mit Materialisierung definieren, geben Sie Ihre Felder, Measures und Aktualisierungszeitpläne in der Metrikansicht YAML an. Mit dieser Definition erstellt Databricks eine verwaltete Lakeflow-Pipeline , die die materialisierten Ansichten erstellt und verwaltet.

Dadurch bleibt die Definition der Metrik davon getrennt, wie sie gespeichert wird:

• Die Metrikansicht ist ein Unity Catalog-Objekt, das die Felder, Measures und Verknüpfungen der Metrik sowie die Materialisierungskonfiguration (Zeitplan und Granularität) definiert. Es ist die einzige Quelle der Wahrheit für das, was die Metrik bedeutet.
• Die Pipeline setzt diese Definition als eine oder mehrere materialisierte Ansichten um, die jeweils auf einer bestimmten Granularitätsebene vorab berechnet werden. Databricks wählt aus, welcher zur Abfragezeit gelesen werden soll.

Abfrageausführung

Wenn Sie SELECT ... FROM <metric_view> ausführen, verwendet der Abfrageoptimierer die aggregatbasierte Abfrageüberschreibung, um die Leistung zu optimieren.

• Schneller Pfad: Liest aus vordefinierten materialisierten Ansichten, wenn eine geeignete Materialisierung vorhanden ist.
• Fallbackpfad: Liest direkt aus Quelldaten, wenn keine geeignete Materialisierung verfügbar ist.

Der Abfrageoptimierer gleicht die Leistung und Aktualität automatisch aus, indem zwischen materialisierten und Quelldaten ausgewählt wird. Sie erhalten unabhängig davon, welchen Pfad der Optimierer verwendet, transparent Ergebnisse. Weitere Informationen zum Ausführen von Abfragen für Metrikansichten finden Sie unter Abfragemetrikansichten.

Anforderungen

So verwenden Sie die Materialisierung für Metrikansichten:

• Ihr Arbeitsbereich muss serverlose Berechnungen aktiviert haben. Dies ist erforderlich, um Lakeflow-Pipelines auszuführen.
• Ein SQL Warehouse oder eine Computeressource mit Databricks Runtime 17.3 oder höher.

Note

Für die Materialisierung ist Databricks Runtime 17.3 oder höher erforderlich. Das Erstellen einer Metrikansicht ohne Materialisierung wird in Databricks Runtime 16.4 und höher unterstützt. Die Mindestlaufzeit für jedes Feature finden Sie unter Verfügbarkeit der Metrikansichtsfeatures.

Konfigurationsreferenz

Sie konfigurieren die Materialisierung in einem Feld auf oberster Ebene materialization in der YAML-Definition der Metrikansicht. Dieses Feld legt die Abfrageumschreibung mode (immer relaxed), eine optionale Aktualisierung schedule und eine Liste von materialized_views, die beibehalten werden sollen, fest. Jede materialisierte Ansicht ist entweder aggregated, die bestimmte Dimensionen und Measures vorab berechnet, oder unaggregated, die das vollständige Datenmodell materialisiert.

Die vollständige Feld-nach-Feld-Spezifikation, einschließlich erforderlicher und optionaler Felder, zulässiger Werte und der schedule Klauseleinschränkungen, finden Sie unter Materialization.

Beispieldefinition

Im folgenden Beispiel wird eine Metrikansicht mit einer nicht aggregierten und zwei aggregierten Materialisierungen definiert:

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

Note

Der materialization-Block verwendet das Schlüsselwort dimensions:, um Felder aufzulisten, die materialisiert werden sollen, obwohl die Definition auf oberster Ebene fields: verwendet. Die beiden Schlüsselwörter sind gleichwertig. Siehe Felder.

Die Materialisierung mit revenue_breakdown verwendet cluster_by und partition_by, um zu steuern, wie die materialisierten Daten physisch gespeichert werden, genauso wie die Klauseln CLUSTER BY und PARTITION BY für eine materialisierte Ansicht. Die vollständige Feldspezifikation finden Sie unter Materialisierung.

Erstellen der Metrikansicht mit SQL

Um diese Metrikansicht außerhalb des Katalog-Explorers zu erstellen, schließen Sie das YAML in CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS ein und platzieren Sie die Definition zwischen den Trennzeichen $$:

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Abfrageumschreibungsmodus

Im relaxed-Modus überprüft die automatische Abfrageumschreibung nur, ob die als Kandidaten infrage kommenden materialisierten Ansichten die erforderlichen Felder und Kennzahlen enthalten, um die Abfrage zu bedienen.

Die folgenden Prüfungen werden übersprungen:

• Aktualität: Es wird nicht überprüft, ob die Materialisierung auf dem neuesten Stand ist.
• SQL-Einstellungen: Es wird nicht überprüft, ob Einstellungen wie TIMEZONE z. B. übereinstimmen ANSI_MODE .
• Determinismus: Es wird nicht überprüft, ob die materialisierten Ergebnisse vollständig deterministisch sind.

Abfragen, die mit einer Materialisierung übereinstimmen, greifen auf den letzten Aktualisierungsstand zurück. Abfragen, die nicht übereinstimmen, greifen auf die Quelldaten zurück und geben Live-Daten zurück. Daher kann die Aktualität der Daten variieren, je nachdem, ob eine Abfrage für die Neuschreibung qualifiziert ist. Um die Konsistenz zu überprüfen, richten Sie den Aktualisierungszeitplan für die Materialisierung mit Ihrer Quellpipeline aus. Wenn Ihre Quelle beispielsweise täglich über eine Batchpipeline aktualisiert wird, planen Sie die Aktualisierungen der Materialisierung so, dass sie erst nach Abschluss dieser Pipeline durchgeführt werden. Verwenden Sie alternativ eine nicht aggregierte Materialisierung, um sicherzustellen, dass alle Abfragen aus derselben Momentaufnahme gelesen werden.

Sie können keine Materialisierung erstellen, wenn die Metrikansicht oder eine der Quelltabellen folgendes verwendet:

• Sicherheit auf Zeilenebene (RLS),Maskierung auf Spaltenebene (CLM) oder ABAC-Richtlinien. Vorab berechnete Ergebnisse können benutzerspezifische Zugriffskontrollen umgehen, die zur Abfragezeit erzwungen werden sollen.
• Aufruferabhängige Ausdrücke, deren Ergebnis sich danach richtet, wer die Abfrage ausführt (zum Beispiel current_user() oder is_member()). Eine Materialisierung wird einmal vorkonfiguriert und freigegeben, sodass die Bereitstellung an einen anderen Benutzer falsche oder unsichere Ergebnisse zurückgibt.

Databricks überprüft diese Einschränkung, wenn Sie eine Materialisierung erstellen, ändern oder aktualisieren. Diese Vorgänge schlagen mit der Fehlerbedingung METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E) fehl. Siehe METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Arten von Materialisierungen für metrische Ansichten

In den folgenden Abschnitten werden die Für Metrikansichten verfügbaren Typen von materialisierten Ansichten erläutert und Anleitungen zum Auswählen der geeigneten Konfiguration für Ihre Datenquellen und Abfragemuster bereitgestellt.

Aggregierter Typ

Dieser Typ berechnet Aggregationen für angegebene Metrik- und Feldkombinationen im Voraus, um eine gezielte Abdeckung zu erreichen.

Verwenden Sie einen Aggregationstyp, wenn bestimmte Dimensions- und Kennzahlkombinationen häufig abgefragt werden. Bei aggregierten Materialisierungen gelten sowohl strategien für genaue Übereinstimmungen als auch Rollup-Übereinstimmungen , die die beste Abfrageleistung für diese Muster bieten.

Für optimale Aggregationen:

• Schließen Sie die am häufigsten verwendeten Dimensionen in GROUP BY Klauseln ein.
• Fügen Sie alle potenziellen Filterspalten hinzu (Spalten, die in WHERE zum Abfragezeitpunkt verwendet werden).
• Materialisieren Sie auf der detailliertesten Ebene, die Ihre Abfragen benötigen. Beispielsweise kann eine Materialisierung bei (region, sku, event_day) allen folgenden Zwecken dienen:
  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku mit WHERE region = 'US'
• Vermeiden Sie zu fein aufgelöste Dimensionen, die überwiegend Gruppen mit nur einer Zeile erzeugen (z. B. einen unverarbeiteten Zeitstempel mit Millisekundengenauigkeit). Dies hat keinen Vorteil und überblasen Speicher.
• Achten Sie auf Maßnahmen, die nicht additiv sind. Nicht-additive Kennzahlen können nicht aus Teilergebnissen erneut aggregiert werden (z. B. COUNT(DISTINCT), MEDIAN und Perzentile) und erfordern eine exakte Übereinstimmung mit einer Materialisierung.

Eine einzelne Aggregation kann nur Abfragen bereitstellen, die ihren spezifischen Dimensionen (genaue Übereinstimmung) oder einer Teilmenge ihrer Dimensionen (Rollupübereinstimmung) entsprechen. Databricks empfiehlt das Erstellen mehrerer aggregierter Materialisierungen für verschiedene Abfrage-Shapes.

Nicht aggregierter Typ

Dieser Typ materialisiert das gesamte nicht aggregierte Datenmodell (die Felder source, joins, filter und fields) für eine umfassendere Abdeckung mit geringerem Leistungsaufwand im Vergleich zum aggregierten Typ.

Verwenden Sie einen nicht aggregierten Typ, wenn einer der folgenden Werte zutrifft:

• Ihre Metrikansicht umfasst teure Quelltransformationen oder Verknüpfungen.
• Abfragemuster sind unvorhersehbar oder vielfältig.
• Alle Benutzer, die die Metrikansicht abfragen, müssen die Konsistenz innerhalb der Daten sehen.

Bei nicht aggregierten Materialisierungen werden teure Quellansichten und Verknüpfungen nur bei der Aktualisierung einmal berechnet, statt bei jeder Abfrage. Wenn sowohl aggregierte als auch nicht aggregierte Materialisierungen vorhanden sind, berechnet Databricks die aggregierten Materialisierungen aus dem nicht aggregierten Material. Dadurch wird eine konsistente Momentaufnahme bereitgestellt und eine redundante Neukompilierung der Quelle vermieden. Eine nicht aggregierte Übereinstimmung ist unabhängig von der Abfragestruktur immer zulässig, vorbehaltlich der in Modus zur Abfrageumschreibung beschriebenen Einschränkungen.

Eine nicht aggregierte Materialisierung hilft nicht, wenn es sich bei der Quelle um einen direkten Tabellenverweis ohne selektiven Filter handelt. In diesem Fall hat es keinen Vorteil, die Quelle direkt zu abfragen.

Weitere Hinweise dazu, wie und wann diese Materialisierungstypen verwendet werden, finden Sie unter Einen Materialisierungstyp für Metrikansichten auswählen.

Automatische Abfragenneuschreibung

Wenn Sie eine Metrikansicht abfragen, leitet die Abfrageumschreibung Ihre Abfrage automatisch an die beste verfügbare Materialisierung weiter. Es verwendet drei Abfrageumschreibungsstrategien: genaue Übereinstimmung, Rollup-Übereinstimmung und nicht aggregierte Übereinstimmung.

Die Abfrage wird automatisch für die beste Materialisierung anstelle der Basistabellen mit diesem Algorithmus ausgeführt:

1. Zuerst versucht der Abfrageoptimierer eine genaue Übereinstimmung.
2. Wenn es keine genaue Übereinstimmung gibt, versucht der Abfrageoptimierer eine Rollup-Übereinstimmung.
3. Wenn es keine Rollup-Übereinstimmung gibt und eine nicht aggregierte Materialisierung vorhanden ist, versucht der Abfrageoptimierer eine nicht aggregierte Übereinstimmung.
4. Wenn keine nicht aggregierte Übereinstimmung vorhanden ist, liest die Abfrage direkt aus den Quelltabellen.

In den folgenden Abschnitten wird erläutert, wie jede Strategie funktioniert.

Note

Materialisierungen müssen abgeschlossen werden, bevor die Abfrage-Neuschreibung wirksam werden kann.

Genaue Übereinstimmung

Die Abfrage fragt genau, was in der Materialisierung vorab berechnet wurde. Die Abfrage schreibt das gespeicherte Ergebnis ohne zusätzliche Arbeit um und ermöglicht schnelle Ergebnisse.

Um sich für eine exakte Übereinstimmung zu qualifizieren:

• Die Ausdrücke der GROUP BY Abfrage müssen exakt den Materialisierungsdimensionen entsprechen.
• Die Kennzahlen der Abfrage müssen eine Teilmenge der Kennzahlen der Materialisierung sein.

Beispielsweise verfügt eine Materialisierung über Dimensionen [region, order_date] und Maße [total_revenue, order_count]. Eine Abfrage, die nach region und order_date gruppiert und total_revenue abfragt, ist eine exakte Übereinstimmung, da die Dimensionen identisch sind und die Kennzahl vorab berechnet wurde.

Rollup-Übereinstimmung

Die Abfrage fordert eine Zusammenfassung auf einer groberen Ebene als das, was zuvor berechnet wurde. Der Optimierer liest das vorab berechnete Ergebnis und aggregiert es bis zur Ebene, die die Abfrage benötigt.

So erfüllen Sie die Voraussetzungen für den Rollup-Abgleich:

• Gröbere Granularität: Die Abfrage gruppiert nach weniger Dimensionen oder einer gröberen Zeitgranularität, als die Materialisierung aufweist.
• Alle Kennzahlen sind additiv: Jede Kennzahl, die Ihre Abfrage anfordert, muss sich durch das Kombinieren von Teilergebnissen korrekt neu berechnen lassen (z. B. SUM von SUMs oder MAX von MAXes). MEDIAN kann nicht zusammengefasst werden, da dies von der Gruppenverteilung abhängt.
• Alle teilnehmenden Filter müssen deterministische Ausdrücke sein: Wenn Ihre Abfrage über eine WHERE Klausel verfügt, muss der Filter immer dasselbe Ergebnis für dieselbe Eingabe erzeugen. Beispielsweise ist WHERE region = 'US' deterministisch, Ausdrücke wie rand() oder uuid() sind es jedoch nicht.

Ein Rollup-Abgleich ist für nicht additive Kennzahlen nicht geeignet, da diese aus Teilergebnissen nicht korrekt erneut aggregiert werden können. Siehe Additive Maßnahmen.

Wenn Sie beispielsweise dieselbe Materialisierung mit den Dimensionen [region, order_date] und den Messwerten [total_revenue, order_count] verwenden, ist eine Abfrage, die nur nach region gruppiert und total_revenue anfordert, eine Rollup-Übereinstimmung. Die Abfrage benötigt weniger Dimensionen als materialisiert, sodass das Modul die täglichen Summen in Summen auf Regionsebene reduziert.

Additive Maßnahmen

Eine Kennzahl ist additiv, wenn ihr aggregiertes Ergebnis durch erneute Aggregation bereits vorhandener aggregierter Materialisierungen korrekt neu berechnet werden kann. Dies ist die Kernanforderung für den Rollupabgleich.

Jede Aggregation mit DISTINCT (zum Beispiel COUNT(DISTINCT), SUM(DISTINCT)) ist nicht additiv und kann nicht hochgerollt werden.

Die folgenden Funktionen sind additiv:

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

Zusätzliche Einschränkungen gelten für additive Maßnahmen:

• Die Measuredefinition muss genau eine Aggregatfunktion enthalten. Ein Maß, dessen Definition mehrere Aggregate kombiniert (zum Beispiel sum(cost) + min(revenue)), ist nicht für den Rollupabgleich geeignet.
• Wenn die Measuredefinition eine FILTER Klausel enthält, muss sie deterministisch sein.
• Die Kennzahl darf keine Fensterkennzahl sein (z. B. eine rollierende 7-Tage-Summe oder ein Vorjahresvergleich, der mit einem Fensterblock definiert ist).

Nicht aggregierter Treffer

Die Abfrage stimmt nicht mit einer vorab berechneten Aggregation überein, aber die teure Vorbereitung (Verknüpfungen und Filter) ist bereits abgeschlossen. Die Abfrageumschreibung beginnt mit dem vorbereiteten Dataset der nicht aggregierten Materialisierung, anstatt zu den Quelltabellen zurückzukehren.

Wenn eine nicht-aggregierte Materialisierung vorhanden ist, steht diese Strategie immer als Fallback zur Verfügung, bevor auf die Quelle zurückgegriffen wird. Jedes Abfrage-Shape kann es verwenden, vorbehaltlich der im Abfrageumschreibmodus beschriebenen Einschränkungen.

Ihre Abfrage gruppiert zum Beispiel nach category und fragt unique_customers ab, aber keine aggregierte Materialisierung umfasst diese Felder und Messwerte. Es existiert jedoch eine nicht aggregierte Materialisierung, bei der der verknüpfte, gefilterte Datensatz bereits vorliegt. Der Abfrageoptimierer liest aus diesem vorbereiteten Datensatz und führt zur Abfragezeit GROUP BY category, COUNT(DISTINCT customer_id) aus, anstatt die Rohdaten-Tabellen von Grund auf neu zu verknüpfen.

Überprüfen, ob eine Abfrage materialisierte Ansichten verwendet

Es gibt zwei Möglichkeiten, zu überprüfen, ob eine Abfrage eine materialisierte Ansicht verwendet:

• Wenden Sie EXPLAIN EXTENDED auf Ihre Abfrage an, um den Abfrageplan anzuzeigen. Wenn die Materialisierung verwendet wurde, enthält der Blattknoten __materialization_mat_<pipeline ID>___metric_view_mat_ sowie den Namen der Materialisierung aus der YAML-Datei.
• Sehen Sie sich das Abfrageprofil an, wie unten dargestellt.

Materialisierungslebenszyklus

In diesem Abschnitt wird erläutert, wie Materialisierungen während des gesamten Lebenszyklus erstellt, verwaltet und aktualisiert werden.

Erstellen und Ändern

Wenn Sie eine Metrikansicht erstellen oder ändern (mit CREATE, ALTER oder dem Catalog Explorer), wird die Definition der Metrikansicht sofort aktualisiert. Materialisierte Ansichten werden mithilfe einer verwalteten Pipeline asynchron im Hintergrund aktualisiert.

So definieren Sie eine neue Materialisierung im Katalog-Explorer-Editor:

1. Klicken Sie auf Materialisierungen.
2. Klicken Sie auf "Zeitplan ", um einen Zeitplan festzulegen. Sie können einen Intervallzeitraum auswählen oder die Materialisierung festlegen, die zu einem bestimmten Zeitpunkt ausgeführt werden soll.
3. Wählen Sie einen Typ aus. Pro Metrikansicht ist nur eine nicht aggregierte Materialisierung zulässig. Weitere Informationen finden Sie unter Typen von Materialisierungen für Metrikansichten.
4. Verwenden Sie die Dropdownliste "Felder ", um die Felder auszuwählen, die in die Materialisierung einbezogen werden sollen.
5. Verwenden Sie die Dropdown-Liste Measures, um die einzuschließenden Kennzahlen auszuwählen.

Wenn Sie eine Metrikansicht erstellen, erstellt Databricks eine Lakeflow-Pipeline und plant sofort ein erstes Update, wenn materialisierte Ansichten definiert sind. Die Metrikansicht bleibt ohne Materialisierungen abfragbar, indem sie auf die Abfrage der Quelldaten zurückgreift.

Wenn Sie eine Metrikansicht ändern, plant Databricks keine neuen Updates, es sei denn, Sie aktivieren die Materialisierung zum ersten Mal. Materialisierte Ansichten werden erst dann für die automatische Umschreibung von Abfragen verwendet, wenn die nächste geplante Aktualisierung abgeschlossen ist.

Das Ändern des Materialisierungszeitplans löst keine Aktualisierung aus.

Ohne Zeitplan führt die Pipeline bei der Erstellung eine erste Aktualisierung aus, nachfolgende Aktualisierungen müssen jedoch manuell ausgelöst werden, andernfalls veralten die Daten. Databricks empfiehlt, immer einen Zeitplan zu definieren, sodass Daten aktuell bleiben, es sei denn, Sie testen oder prototypieren.

Weitere Informationen finden Sie unter "Manuelle Aktualisierung ", um das Aktualisierungsverhalten genauer zu steuern.

Untersuchen der zugrunde liegenden Pipeline

Die Materialisierung für Metrikansichten wird mithilfe von Lakeflow-Pipelines implementiert. Sie können auf zwei Arten auf die Pipeline zugreifen:

• Im Katalog-Explorer: Die Registerkarte "Übersicht " für die Metrikansicht enthält einen direkten Link unter der Überschrift "Zeitplan aktualisieren ". Informationen zum Zugreifen auf den Katalog-Explorer finden Sie unter Was ist der Katalog-Explorer?.
• Verwenden von SQL: Ausführen DESCRIBE EXTENDED. Der Abschnitt "Aktualisierungsinformationen" enthält den Pipelinelink und den aktuellen Aktualisierungsstatus.

DESCRIBE EXTENDED my_metric_view;

Beispielausgabe:

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Manuelle Aktualisierung

Über den Link zur Lakeflow-Pipeline-Seite können Sie manuell eine Pipeline-Aktualisierung starten, um die Materialisierungen zu aktualisieren. Sie können eine manuelle Aktualisierung auch mit dem folgenden SQL-Befehl auslösen:

REFRESH MATERIALIZED VIEW <metric-view-name>

Schrittweise Aktualisierung

Die materialisierten Ansichten verwenden nach Möglichkeit eine inkrementelle Aktualisierung und haben dieselben Einschränkungen wie standardmaterialisierte Ansichten in Bezug auf Datenquellen und Planstruktur.

Ausführliche Informationen zu Voraussetzungen und Einschränkungen finden Sie unter Inkrementelles Aktualisieren von materialisierten Ansichten.

Abrechnung

Für das Aktualisieren von materialisierten Ansichten fallen Nutzungsgebühren für Lakeflow Pipelines an. Informationen zum DBU-Verbrauch der Pipeline finden Sie unter Was ist der DBU-Verbrauch einer serverlosen Pipeline?.

Bekannte Einschränkungen

Die folgenden Einschränkungen gelten für die Materialisierung für Metrikansichten:

• Sie können keine Metrikansicht materialisieren, die Parameter definiert.
• Nachdem eine Materialisierung für eine Metrikansicht erstellt wurde, können Sie den Besitzer nicht mehr ändern.
• Databricks unterstützt keinen Gruppenbesitz materialisierter Metrikansichten.
• Nur die Strategie für exakte Übereinstimmung ist für Metrikansichten mit 1:n-Verknüpfungen zulässig.