Freigeben über

Verwenden materialisierter Sichten in Databricks SQL

In diesem Artikel wird beschrieben, wie Sie materialisierte Ansichten in Databricks SQL erstellen und aktualisieren, um die Leistung zu verbessern und die Kosten Ihrer Datenverarbeitungs- und Analyseworkloads zu reduzieren.

Was sind materialisierte Sichten?

In Databricks SQL sind materialisierte Ansichten verwaltete Tabellen im Unity-Katalog, die die Ergebnisse einer Abfrage physisch speichern. Im Gegensatz zu Standardansichten, die Ergebnisse bei Bedarf berechnen, speichern materialisierte Ansichten die Ergebnisse zwischen und aktualisieren sie, wenn sich die zugrunde liegenden Quelltabellen ändern – entweder nach einem Zeitplan oder automatisch.

Materialisierte Ansichten eignen sich gut für Datenverarbeitungs-Workloads wie Extrahieren, Transformieren und Laden (ETL-Verarbeitung). Materialisierte Sichten bieten eine einfache, deklarative Möglichkeit zur Datenverarbeitung im Rahmen der Einhaltung von Richtlinien, Korrekturen, Aggregationen oder allgemeinem Change Data Capture (CDC). Materialisierte Sichten unterstützen zudem benutzerfreundliche Transformationen, indem sie Basistabellen bereinigen, anreichern und denormalisieren. Durch die Vorberechnung von teuren oder häufig verwendeten Abfragen reduzieren materialisierte Sichten die Abfragelatenz und den Ressourcenverbrauch. In vielen Fällen können sie inkrementelle Änderungen aus Quelltabellen berechnen, die Effizienz und die Endbenutzerfreundlichkeit weiter verbessern.

Im Folgenden finden Sie häufig verwendete Anwendungsfälle für materialisierte Ansichten:

  • Halten Sie ein BI-Dashboard auf dem neuesten Stand, während die Anfragelatenz der Endbenutzer minimal bleibt.
  • Reduzieren der komplexen ETL-Orchestrierung mit einfacher SQL-Logik.
  • Erstellen komplexer, geschichteter Transformationen.
  • Alle Anwendungsfälle, die eine einheitliche Leistung mit aktuellen Erkenntnissen erfordern.

Wenn Sie eine materialisierte Ansicht in einem Databricks SQL Warehouse erstellen, wird eine serverlose Pipeline erstellt, um die Erstellung und Aktualisierung der materialisierten Ansicht zu verarbeiten. Sie können den Status der Aktualisierungsvorgänge im Katalog-Explorer überwachen. Siehe "Details anzeigen" mit DESCRIBE EXTENDED.

Anforderungen

Materialisierte Ansichten, die in Databricks SQL erstellt wurden, werden von einer serverlosen Pipeline unterstützt. Ihr Arbeitsbereich muss serverlose Pipelines unterstützen, um diese Funktionalität zu verwenden.

Anforderungen zum Erstellen oder Aktualisieren von materialisierten Ansichten:

  • Sie müssen ein Unity Catalog-fähiges Pro- oder serverloses SQL Warehouse verwenden.

  • Um eine materialisierte Sicht zu aktualisieren, müssen Sie sich im Arbeitsbereich befinden, in dem diese erstellt wurde.

  • Um eine materialisierte Ansicht aus Delta-Tabellen inkrementell zu aktualisieren, müssen die Quelltabellen die Zeilennachverfolgung aktiviert haben.

  • Der Besitzer (der Benutzer, der die materialisierte Ansicht erstellt) muss über die folgenden Berechtigungen verfügen:

    • SELECT-Berechtigung für die Basistabellen, auf die die materialisierte Sicht verweist.
    • USE CATALOG- und USE SCHEMA-Berechtigungen für den Katalog und das Schema, das die Quelltabellen für die materialisierte Ansicht enthält.
    • USE CATALOG- und USE SCHEMA-Berechtigungen für den Zielkatalog und das Schema für die materialisierte Sicht.
    • CREATE TABLE- und CREATE MATERIALIZED VIEW-Berechtigungen für das Schema, das die materialisierte Sicht enthält.

  • Um eine materialisierte Ansicht zu aktualisieren, müssen Sie über die REFRESH Berechtigung für die materialisierte Ansicht verfügen.

Anforderungen für die Abfrage materialisierter Sichten:

  • Sie müssen Besitzer der materialisierten Sicht sein oder in der materialisierten Sicht SELECT sowie USE SCHEMA und USE CATALOG auf der übergeordneten Ebene haben.
  • Sie müssen eine der folgenden Computeressourcen verwenden:

    • SQL Warehouse

    • Lakeflow Spark Declarative Pipelines-Schnittstellen

    • Berechnen des Standardzugriffsmodus (früher gemeinsam genutzter Zugriffsmodus)

    • Dedizierter Zugriffsmodus (ehemals Einzelbenutzerzugriffsmodus) für Databricks Runtime 15.4 und höher, solange der Arbeitsbereich für die serverlose Berechnung aktiviert ist. Siehe Feingranulare Zugriffssteuerung auf dedizierten Rechenressourcen.

      Wenn Sie der Eigentümer der materialisierten Ansicht sind, können Sie eine dedizierte Rechnerressource im Zugriffsmodus verwenden, die auf der Databricks Runtime ab Version 14.3 läuft.

Informationen zu anderen Einschränkungen bei der Verwendung materialisierter Sichten finden Sie unter Einschränkungen.

Erstellen einer materialisierten Sicht

CREATE-Vorgänge zum Erstellen einer materialisierten Databricks SQL-Sicht verwenden ein Databricks SQL-Warehouse, um Daten in der materialisierten Sicht zu erstellen und zu laden. Das Erstellen einer materialisierten Ansicht ist ein synchroner Vorgang, was bedeutet, dass der CREATE MATERIALIZED VIEW Befehl blockiert, bis die materialisierte Ansicht erstellt und der anfängliche Datenladevorgang abgeschlossen ist. Für jede materialisierte SQL-Ansicht von Databricks wird automatisch eine serverlose Pipeline erstellt. Wenn die materialisierte Ansicht aktualisiert wird, verarbeitet die Pipeline die Aktualisierung.

Zum Erstellen einer materialisierten Sicht verwenden Sie die Anweisung CREATE MATERIALIZED VIEW. Verwenden Sie zum Übermitteln einer Erstellungsanweisung den SQL-Editor in der Azure Databricks-Benutzeroberfläche, die Databricks SQL CLI oder die Databricks SQL API.

Der Benutzer, der eine materialisierte Ansicht erstellt, ist deren Eigentümer.

Im folgenden Beispiel wird die materialisierte Sicht mv1 von der Basistabelle base_table1 erstellt:

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Wenn Sie mithilfe der CREATE OR REPLACE MATERIALIZED VIEW Anweisung eine materialisierte Ansicht erstellen, beginnt die anfängliche Datenaktualisierung und -population sofort. Dies verbraucht keine SQL Warehouse-Rechenleistung. Stattdessen wird eine serverlose Pipeline für die Erstellung und nachfolgende Aktualisierungen verwendet.

Spaltenkommentare in einer Basistabelle werden automatisch nur bei der Erstellung in die neue materialisierte Sicht übertragen. Um einen Zeitplan, Tabelleneinschränkungen oder andere Eigenschaften hinzuzufügen, ändern Sie die materialisierte Ansichtsdefinition (die SQL-Abfrage).

Die gleiche SQL-Anweisung aktualisiert eine materialisierte Ansicht, wenn sie später oder in einem Zeitplan aufgerufen wird. Eine Auffrischung auf diese Weise funktioniert wie jede andere Aktualisierung. Ausführliche Informationen finden Sie unter Aktualisieren einer materialisierten Ansicht.

Weitere Informationen zum Konfigurieren einer materialisierten Ansicht finden Sie unter Konfigurieren materialisierter Ansichten in Databricks SQL. Informationen zur vollständigen Syntax zum Erstellen einer materialisierten Ansicht finden Sie unter CREATE MATERIALIZED VIEW. Informationen zum Laden von Daten in verschiedenen Formaten und von verschiedenen Stellen finden Sie unter Laden von Daten in Pipelines.

Laden von Daten aus externen Systemen

Materialisierte Ansichten können für externe Daten mithilfe der Lakehouse Federation für unterstützte Datenquellen erstellt werden. Informationen zum Laden von Daten aus Quellen, die von Lakehouse Federation nicht unterstützt werden, finden Sie unter Datenformatoptionen. Allgemeine Informationen zum Laden von Daten, einschließlich Beispielen, finden Sie unter Laden von Daten in Pipelines.

Ausblenden vertraulicher Daten

Sie können materialisierte Ansichten verwenden, um vertrauliche Daten von Benutzern auszublenden, die auf die Tabelle zugreifen. Eine Möglichkeit hierzu besteht darin, die Abfrage zu erstellen, sodass sie diese Daten nicht an erster Stelle enthält. Sie können aber auch Spalten maskieren oder Zeilen basierend auf den Berechtigungen des Abfragebenutzers filtern. Sie könnten beispielsweise die tax_id Spalte für Benutzer ausblenden, die sich nicht in der Gruppe HumanResourcesDeptbefinden. Verwenden Sie dazu die ROW FILTER und MASK Syntax während der Erstellung der materialisierten Ansicht. Weitere Informationen finden Sie unter Zeilenfilter und Spaltenmasken.

Aktualisieren einer materialisierten Ansicht

Beim Aktualisieren einer materialisierten Ansicht wird die Ansicht aktualisiert, um die neuesten Änderungen an der Basistabelle zum Zeitpunkt der Aktualisierung widerzuspiegeln.

Wenn Sie eine materialisierte Ansicht definieren, wird die CREATE OR REPLACE MATERIALIZED VIEW Anweisung zum Erstellen der Ansicht und zum Aktualisieren für alle geplanten Aktualisierungen verwendet. Sie können die REFRESH MATERIALIZED VIEW Anweisung auch verwenden, um die materialisierte Ansicht zu aktualisieren, ohne die Abfrage erneut bereitstellen zu müssen. Einzelheiten zur SQL-Syntax und zu den Parametern für diesen Befehl finden Sie unter REFRESH (MATERIALIZED VIEW oder STREAMING TABLE). Weitere Informationen zu den Typen materialisierter Ansichten, die inkrementell aktualisiert werden können, finden Sie unter Inkrementelle Aktualisierung für materialisierte Ansichten.

Verwenden Sie zum Übermitteln einer Aktualisierungsanweisung den SQL-Editor in der Azure Databricks-Benutzeroberfläche, ein an ein SQL-Warehouse angeschlossenes Notebook, die Databricks SQL CLI oder die Databricks SQL-API.

Der Besitzer und jeder Benutzer, dem die REFRESH Berechtigung für die Tabelle gewährt wurde, kann die materialisierte Ansicht aktualisieren.

Im folgenden Beispiel wird die materialisierte Sicht mv1 aktualisiert:

REFRESH MATERIALIZED VIEW mv1;

Der Vorgang ist standardmäßig synchron, d. h., der Befehl blockiert, bis der Aktualisierungsvorgang abgeschlossen ist. Um asynchron zu aktualisieren, können Sie das ASYNC Schlüsselwort hinzufügen:

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Wie werden materialisierte Databricks SQL-Sichten aktualisiert?

Materialisierte Ansichten erstellen automatisch serverlose Pipelines, um Aktualisierungsvorgänge zu verarbeiten. Die Aktualisierung wird von der Pipeline verwaltet, und das Update wird vom Databricks SQL Warehouse überwacht, das zum Erstellen der materialisierten Ansicht verwendet wird. Materialisierte Ansichten können mithilfe einer Pipeline aktualisiert werden, die in einem Zeitplan ausgeführt wird. Von Databricks SQL erstellte materialisierte Sichten werden immer im Modus „ausgelöst“ ausgeführt. Siehe Ausgelöste vs. Continuous Pipeline-Modus.

Materialisierte Ansichten werden mit einer von zwei Methoden aktualisiert.

  • Inkrementelle Aktualisierung – Das System wertet die Abfrage der Ansicht aus, um Änderungen zu identifizieren, die nach der letzten Aktualisierung aufgetreten sind, und führt nur die neuen oder geänderten Daten zusammen.
  • Vollständige Aktualisierung : Wenn eine inkrementelle Aktualisierung nicht ausgeführt werden kann oder nicht kosteneffektiv ist, führt das System die gesamte Abfrage aus und ersetzt die vorhandenen Daten in der materialisierten Ansicht durch die neuen Ergebnisse.

Die Struktur der Abfrage und der Typ der Quelldaten bestimmen, ob die inkrementelle Aktualisierung unterstützt wird. Um die inkrementelle Aktualisierung zu unterstützen, sollten Quelldaten in Delta-Tabellen gespeichert werden, wobei Zeilennachverfolgung und Änderungsdatenfeed aktiviert sind. Um festzustellen, ob eine Abfrage inkrementell ist, verwenden Sie die Databricks SQL-Anweisung EXPLAIN CREATE MATERIALIZED VIEW . Nachdem Sie eine materialisierte Ansicht erstellt haben, können Sie das Aktualisierungsverhalten überwachen, um zu überprüfen, ob sie inkrementell oder über eine vollständige Aktualisierung aktualisiert wird.

Standardmäßig verwendet Azure Databricks ein Kostenmodell, um die kostengünstigere Option zwischen vollständiger und inkrementeller Aktualisierung auszuwählen. Sie können dieses Verhalten außer Kraft setzen, um entweder inkrementelle oder vollständige Aktualisierungen zu bevorzugen, indem Sie eine REFRESH POLICY in der SQL-Definition der materialisierten Ansicht festlegen.

Ausführliche Informationen zu Aktualisierungstypen und zur Optimierung für inkrementelle Aktualisierungen finden Sie unter "Inkrementelle Aktualisierung für materialisierte Ansichten".

Asynchrone Aktualisierungen

Aktualisierungsvorgänge werden standardmäßig synchron ausgeführt. Sie können auch einen Aktualisierungsvorgang so festlegen, dass er asynchron ausgeführt wird. Dies kann mithilfe des Aktualisierungsbefehls mit dem ASYNC Schlüsselwort festgelegt werden. Siehe REFRESH (MATERIALIZED VIEW oder STREAMING TABLE). Das verhalten, das den einzelnen Ansätzen zugeordnet ist, lautet wie folgt:

  • Synchron: Eine synchrone Aktualisierung verhindert, dass andere Vorgänge fortgesetzt werden, bis die Aktualisierung abgeschlossen ist. Wenn das Ergebnis für den nächsten Schritt erforderlich ist, z. B. beim Sequenzieren von Aktualisierungsvorgängen in Orchestrierungstools wie Lakeflow-Aufträgen, verwenden Sie eine synchrone Aktualisierung. Um materialisierte Ansichten mit einem Auftrag zu koordinieren, verwenden Sie den SQL-Aufgabentyp . Siehe Lakeflow Jobs.
  • Asynchron: Eine asynchrone Aktualisierung startet einen Hintergrundauftrag auf serverloser Berechnung, wenn eine materialisierte Ansichtsaktualisierung beginnt, sodass der Befehl zurückgegeben werden kann, bevor die Daten geladen werden. Dieser Aktualisierungstyp kann Kosten sparen, da der Vorgang nicht unbedingt Rechenkapazität im Lager enthält, in dem der Befehl initiiert wird. Wenn die Aktualisierung inaktiv wird und keine anderen Aufgaben ausgeführt werden, kann das Lager heruntergefahren werden, während die Aktualisierung andere verfügbare Rechenressourcen verwendet. Darüber hinaus unterstützen asynchrone Aktualisierungen das Starten mehrerer Vorgänge parallel.

Planen der Aktualisierung materialisierter Sichten

Sie können eine sql-materialisierte Databricks-Ansicht so konfigurieren, dass sie automatisch basierend auf einem definierten Zeitplan aktualisiert oder ausgelöst wird, wenn upstream-Daten geändert werden. In der folgenden Tabelle sind die verschiedenen Optionen für die Planung von Aktualisierungen aufgeführt.

Methode Description Beispiel eines Anwendungsfalls
Manuell Aktualisierung bei Bedarf mithilfe einer SQL-Anweisung REFRESH oder über die Arbeitsbereichs-UI. Entwicklung, Tests, Ad-hoc-Updates.
TRIGGER ON UPDATE Definieren Sie die materialisierte Ansicht, die beim Ändern der Upstreamdaten automatisch aktualisiert werden soll. Produktionsworkloads mit Datenfrischungs-SLAs oder unvorhersehbaren Aktualisierungszeiträumen.
SCHEDULE Definieren Sie die materialisierte Ansicht, die in definierten Zeitintervallen aktualisiert werden soll. Vorhersehbare, zeitbasierte Aktualisierungsanforderungen.
SQL-Aufgabe in einem Auftrag Die Aktualisierung wird durch Lakeflow Jobs orchestriert. Komplexe Pipelines mit systemübergreifenden Abhängigkeiten.

Manuelle Aktualisierung

Um eine materialisierte Ansicht manuell zu aktualisieren, können Sie eine Aktualisierung aus Databricks SQL aufrufen oder die Arbeitsbereichsbenutzeroberfläche verwenden.

REFRESH-Anweisung

So aktualisieren Sie eine Pipeline mit Databricks SQL:

  1. Im Abfrage-Editor-Symbol im SQL-Editor führen Sie die folgende Anweisung aus:

    REFRESH MATERIALIZED VIEW <mv-name>;

Weitere Informationen finden Sie unter REFRESH (MATERIALIZED VIEW oder STREAMING TABLE).

Benutzeroberfläche des Arbeitsbereichs

So aktualisieren Sie eine Pipeline in der Arbeitsbereichs-UI:

  1. Klicken Sie im Azure Databricks-Arbeitsbereich auf das Symbol Aufträge & Pipelines.
  2. Wählen Sie die Pipeline aus, die Sie aus der Liste aktualisieren möchten.
  3. Klicken Sie auf die Schaltfläche Start.

Während die Pipeline aktualisiert wird, werden Aktualisierungen in der Benutzeroberfläche angezeigt.

Auslösen bei Aktualisierung

Die TRIGGER ON UPDATE Klausel aktualisiert automatisch eine materialisierte Ansicht, wenn sich die Upstream-Quelldaten ändern. Dies beseitigt die Notwendigkeit, Zeitpläne über Pipelines hinweg zu koordinieren. Die materialisierte Ansicht bleibt aktuell, ohne dass der Benutzer wissen muss, wann vorgelagerte Aufträge abgeschlossen sind oder komplexe Planungslogik einzuhalten ist.

Dies ist der empfohlene Ansatz für Produktionsworkloads, insbesondere, wenn vorherige Abhängigkeiten nicht nach vorhersehbaren Zeitplänen ablaufen. Nach der Konfiguration überwacht die materialisierte Ansicht die Quelltabellen und aktualisiert sich automatisch, wenn Änderungen in einer der upstream-Quellen erkannt werden.

Einschränkungen

  • Upstream-Abhängigkeitsgrenzwerte: Eine materialisierte Ansicht kann maximal 10 upstream-Tabellen und 30 upstream-Ansichten überwachen. Bei zusätzlichen Abhängigkeiten teilen Sie die Logik auf mehrere materialisierte Ansichten auf.
  • Arbeitsbereichsbeschränkungen: Pro Arbeitsbereich können maximal 1.000 materialisierte Ansichten TRIGGER ON UPDATE vorhanden sein. Wenden Sie sich an den Databricks-Support, wenn mehr als 1.000 materialisierte Ansichten erforderlich sind.
  • Minimales Intervall: Das minimale Auslöserintervall beträgt 1 Minute.

In den folgenden Beispielen wird gezeigt, wie sie beim Definieren einer materialisierten Ansicht einen Trigger für die Aktualisierung festlegen.

Erstellen einer materialisierten Ansicht mit Trigger beim Aktualisieren

Wenn Sie eine materialisierte Ansicht erstellen möchten, die beim Ändern von Quelldaten automatisch aktualisiert wird, schließen Sie die TRIGGER ON UPDATE Klausel in die CREATE MATERIALIZED VIEW Anweisung ein.

Im folgenden Beispiel wird eine materialisierte Ansicht erstellt, die Kundenbestellungen aggregiert und aktualisiert, wenn die Quelle customers oder orders Tabellen aktualisiert werden:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Aktualisierungsfrequenz der Drosselung

Wenn Upstream-Daten häufig aktualisiert werden, verwenden Sie AT MOST EVERY, um zu steuern, wie oft die Ansicht aktualisiert wird, und die Berechnungskosten zu reduzieren. Dies ist nützlich, wenn Quelltabellen häufig aktualisiert werden, aber nachgeschaltete Verbraucher benötigen keine Echtzeitdaten. Das INTERVAL Schlüsselwort ist vor dem Zeitwert erforderlich.

Im folgenden Beispiel wird die materialisierte Ansicht so begrenzt, dass sie höchstens alle 5 Minuten aktualisiert wird, auch wenn sich Quelldaten häufiger ändern:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Geplante Aktualisierung

Aktualisierungszeitpläne können direkt in der materialisierten Ansichtsdefinition definiert werden, um die Ansicht in festen Zeitintervallen zu aktualisieren. Dieser Ansatz ist nützlich, wenn der Datenaktualisierungsrhythmen bekannt ist und eine vorhersagbare Aktualisierungszeitdauer gewünscht wird.

Wenn ein Aktualisierungszeitplan vorhanden ist, können Sie jederzeit eine manuelle Aktualisierung ausführen, wenn Sie aktualisierte Daten benötigen.

Databricks unterstützt zwei Planungssyntaxen: SCHEDULE EVERY für einfache Intervalle und SCHEDULE CRON für präzise Planung. Die SCHEDULE Schlüsselwörter und SCHEDULE REFRESH Schlüsselwörter sind semantisch gleichwertig.

Ausführliche Informationen zur Syntax und Verwendung der SCHEDULE Klausel finden Sie unter CREATE MATERIALIZED VIEW SCHEDULE-Klausel.

Beim Erstellen eines Zeitplans wird automatisch ein neuer Databricks-Auftrag konfiguriert, um die Aktualisierung zu verarbeiten.

Führen Sie zum Anzeigen des Zeitplans einen der folgenden Schritte aus:

  • Führen Sie die DESCRIBE EXTENDED Anweisung aus dem SQL-Editor in der Azure Databricks-Benutzeroberfläche aus. Siehe DESCRIBE TABLE.
  • Verwenden Sie den Katalog-Explorer, um die materialisierte Ansicht anzuzeigen. Der Zeitplan wird auf der Registerkarte Übersicht unter Aktualisierungsstatus aufgeführt. Siehe Was ist der Katalog-Explorer?.

Die folgenden Beispiele zeigen, wie Sie eine materialisierte Ansicht mit einem Zeitplan erstellen:

Jedes Zeitintervall planen

In diesem Beispiel wird einmal jede Stunde eine Aktualisierung geplant:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

Planen mit Cron

In diesem Beispiel wird eine Aktualisierung alle 15 Minuten in der Quartalsstunde der UTC-Zeitzone geplant:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

SQL-Aufgabe in einem Auftrag

Die Aktualisierung der materialisierten Ansicht kann über Databricks-Aufträge koordiniert werden, indem SQL-Aufgaben erstellt werden, die Befehle wie REFRESH MATERIALIZED VIEW enthalten. Dieser Ansatz integriert materialisierte Ansichtsaktualisierungen in vorhandene Auftrags-Orchestrierungsworkflows.

Es gibt zwei Möglichkeiten zum Erstellen eines Auftrags zum Aktualisieren materialisierter Ansichten:

  • Schreiben Sie im SQL-Editor den REFRESH MATERIALIZED VIEW Befehl, und klicken Sie auf die Schaltfläche "Zeitplan ", um einen Auftrag direkt aus der Abfrage zu erstellen.
  • In der Jobs-Benutzeroberfläche eine Aufgabe erstellen: Erstellen Sie einen neuen Auftrag, fügen Sie einen SQL-Aufgabentyp hinzu und hängen Sie eine SQL-Abfrage oder ein Notizbuch mit dem REFRESH MATERIALIZED VIEW Befehl an.

Das folgende Beispiel zeigt die SQL-Anweisung in einer SQL-Aufgabe, die eine materialisierte Ansicht aktualisiert:

REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

Dieser Ansatz ist geeignet, wenn:

  • Komplexe mehrstufige Pipelines weisen Abhängigkeiten auf allen Systemen auf.
  • Es ist eine Integration mit vorhandener Job-Orchestrierung erforderlich.
  • Warnungen und Überwachung auf Auftragsebene sind erforderlich.

SQL-Aufgaben verwenden sowohl das SQL Warehouse, das an den Auftrag angefügt ist, als auch die serverlose Berechnung, die die Aktualisierung ausführt. Wenn die Verwendung der ansichtsdefinitionsbasierten Planung die Anforderungen erfüllt, kann das Wechseln zu TRIGGER ON UPDATE oder SCHEDULE den Workflow vereinfachen.

Hinzufügen eines Zeitplans zu einer vorhandenen materialisierten Ansicht

Verwenden Sie die ALTER MATERIALIZED VIEW Anweisung, um den Zeitplan nach der Erstellung festzulegen:

-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales
  ADD TRIGGER ON UPDATE;

Ändern eines vorhandenen Zeitplans oder Triggers

Wenn einer materialisierten Ansicht bereits ein Zeitplan oder Trigger zugeordnet ist, verwenden Sie oder , um die Aktualisierungskonfiguration zu ändern. Dies gilt sowohl für den Wechsel von einem Zeitplan zu einem anderen als auch von einem Trigger zu einem anderen sowie beim Wechsel zwischen einem Zeitplan und einem Trigger.

Im folgenden Beispiel wird ein vorhandener Zeitplan so geändert, dass er alle 4 Stunden aktualisiert wird:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

Löschen eines Plans oder Triggers

Verwenden Sie ALTER ... DROPfolgendes, um einen Zeitplan zu entfernen:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

Beenden einer aktiven Aktualisierung

Um eine aktive Aktualisierung in der Azure Databricks-Benutzeroberfläche zu beenden, klicken Sie auf der Seite "Pipelinedetails " auf "Beenden ", um die Pipelineaktualisierung zu beenden. Sie können die Aktualisierung auch über die Databricks CLI oder den Vorgang POST /api/2.0/pipelines/{pipeline_id}/stop in der Pipelines-API beenden.

Timeouts bei Aktualisierungen

Lange ausgeführte Aktualisierungen können zu einem Timeout führen. Materialisierte Ansichten, die nach dem 14. August 2025 erstellt oder aktualisiert wurden, verwenden das Timeout, das dem SQL-Warehouse zugeordnet ist, mit dem die Aktualisierung ausgeführt wird. Wenn für das Lager kein Timeout festgelegt ist, wird der Standardwert von 2 Tagen verwendet.

Hinweis

Die materialisierte Ansicht synchronisiert nur das Timeout, wenn Sie eine CREATE OR REFRESH Anweisung manuell ausführen. Geplante Updates behalten das Timeout aus der letzten CREATE OR REFRESH.

Sie können das Timeout explizit mit einer STATEMENT_TIMEOUT Konfiguration in Sql für die Aktualisierung festlegen. Siehe STATEMENT_TIMEOUT.

Datensätze dauerhaft aus einer materialisierten Ansicht entfernen, wobei Löschvektoren aktiviert sind

Von Bedeutung

Die Unterstützung für die REORG-Anweisung mit materialisierten Sichten befindet sich in der Public Preview.

Hinweis

  • Die Verwendung einer REORG-Anweisung mit einer materialisierten Sicht erfordert Databricks Runtime 15.4 und höher.
  • Obwohl Sie die REORG Anweisung mit einer beliebigen materialisierten Ansicht verwenden können, ist sie nur erforderlich, wenn Datensätze aus einer materialisierten Ansicht gelöscht werden, wobei Löschvektoren aktiviert sind. Der Befehl hat keine Auswirkung, wenn er bei einer materialisierten Ansicht ohne aktivierte Löschvektoren verwendet wird.

Um Datensätze physisch aus dem zugrunde liegenden Speicher für eine materialisierte Ansicht mit aktivierten Löschvektoren zu löschen, z. B. für die DSGVO-Compliance, müssen zusätzliche Schritte ausgeführt werden, um sicherzustellen, dass ein VACUUM Vorgang für die Daten der materialisierten Ansicht ausgeführt wird.

So löschen Sie Datensätze physisch:

  1. Führen Sie eine REORG-Anweisung für die materialisierte Ansicht aus, und geben Sie den APPLY (PURGE)-Parameter an. Beispiel: REORG TABLE <materialized-view-name> APPLY (PURGE);. Siehe REORG TABLE.
  2. Warten Sie, bis der Datenaufbewahrungszeitraum der materialisierten Ansicht überschritten wird. Der Standardzeitraum für die Datenaufbewahrung beträgt sieben Tage, kann jedoch mit der delta.deletedFileRetentionDuration Tabelleneigenschaft konfiguriert werden. Siehe Konfigurieren der Datenaufbewahrung für Zeitreiseabfragen.
  3. REFRESH die materialisierte Sicht. Siehe Aktualisieren einer materialisierten Sicht. Innerhalb von 24 Stunden nach dem REFRESH Vorgang werden die Pipelinewartungsaufgaben automatisch ausgeführt, einschließlich des VACUUM Vorgangs, der erforderlich ist, um sicherzustellen, dass Datensätze endgültig gelöscht werden.

Löschen einer materialisierten Sicht

Hinweis

Um den Befehl zum Ablegen einer materialisierten Ansicht zu übermitteln, müssen Sie der Besitzer dieser materialisierten Ansicht sein oder über die MANAGE Berechtigungen für die materialisierte Ansicht verfügen.

Verwenden Sie zum Löschen einer materialisierten Sicht die DROP VIEW-Anweisung. Zum Übermitteln einer DROP-Anweisung können Sie den SQL-Editor in der Azure Databricks-Benutzeroberfläche, die Databricks SQL CLI oder die Databricks SQL-API verwenden. Im folgenden Beispiel wird die materialisierte Sicht mv1 gelöscht:

DROP MATERIALIZED VIEW mv1;

Sie können auch den Katalogexplorer verwenden, um eine materialisierte Ansicht zu entfernen.

  1. Klicken Sie auf das Symbol Katalog in der Randleiste.
  2. Öffnen Sie im Katalog-Explorer-Baum links den Katalog, und wählen Sie das Schema aus, in dem sich die materialisierte Ansicht befindet.
  3. Öffnen Sie das Element Tabelle unter dem ausgewählten Schema, und klicken Sie auf die materialisierte Sicht.
  4. Wählen Sie im Kebab-Menüsymbol " die Option "Löschen" aus.

Verstehen der Kosten einer materialisierten Ansicht

Da eine materialisierte Sicht in serverlosem Rechnen ausgeführt wird, also außerhalb der Berechnungsumgebung, die Sie für ein Notizbuch oder einen Auftrag eingerichtet haben, fragen Sie sich vielleicht, wie Sie die damit verbundenen Kosten nachvollziehen können. Die Nutzung von materialisierten Sichten wird durch den DBU-Verbrauch erfasst. Weitere Informationen finden Sie unter Was ist der DBU-Verbrauch einer materialisierten Ansicht oder Streamingtabelle?

Aktivieren der Zeilenverfolgung

Um inkrementelle Aktualisierungen aus Delta-Tabellen zu unterstützen, muss die Zeilennachverfolgung für diese Quelltabellen aktiviert sein. Wenn Sie eine Quelltabelle neu erstellen, müssen Sie die Zeilennachverfolgung erneut aktivieren.

Das folgende Beispiel zeigt, wie Sie die Zeilenverfolgung in einer Tabelle aktivieren:

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Weitere Details finden Sie unter Zeilenverfolgung in Databricks

Einschränkungen

  • Um die Anforderungen an Rechenleistung und Arbeitsumgebung zu erfahren, siehe Anforderungen.
  • Informationen zu inkrementellen Aktualisierungsanforderungen finden Sie unter Inkrementelle Aktualisierung für materialisierte Ansichten.
  • Materialisierte Sichten unterstützen keine Identitätsspalten oder Ersatzschlüssel.
  • Wenn eine materialisierte Sicht ein Summenaggregat über eine NULL-fähige Spalte verwendet und nur NULL-Werte in dieser Spalte verbleiben, lautet der resultierende Aggregatwert der materialisierten Sicht 0 anstelle von NULL.
  • Sie können einen Datenänderungsfeed nicht aus einer materialisierten Sicht lesen.
  • Zeitreiseabfragen werden für materialisierte Sichten nicht unterstützt.
  • Die zugrunde liegenden Dateien, die materialisierte Sichten unterstützen, können Daten aus Upstreamtabellen (einschließlich möglicher personenbezogener Informationen) enthalten, die in der Definition der materialisierten Sicht nicht angezeigt werden. Diese Daten werden automatisch zum zugrunde liegenden Speicher hinzugefügt, um die inkrementelle Aktualisierung materialisierter Sichten zu unterstützen. Da die zugrunde liegenden Dateien einer materialisierten Sicht möglicherweise das Risiko bergen, dass Daten aus Upstreamtabellen verfügbar gemacht werden, die nicht Teil des Schemas der materialisierten Sicht sind, empfiehlt Databricks, den zugrunde liegenden Speicher nicht für nicht vertrauenswürdige Downstreamconsumer freizugeben. Nehmen wir an, die Definition einer materialisierten Sicht beinhaltet eine COUNT(DISTINCT field_a)-Klausel. Obwohl die Definition der materialisierten Sicht nur die Aggregatklausel COUNT DISTINCT enthält, enthalten die zugrunde liegenden Dateien eine Liste der tatsächlichen Werte von field_a.
  • Es können einige Kosten für serverlose Berechnung anfallen, selbst wenn Sie diese Funktionen auf dediziertem Rechenbetrieb verwenden.
  • Wenn Sie eine Azure Private Link-Verbindung mit Ihrer materialisierten Ansicht verwenden müssen, wenden Sie sich an Ihren Databricks-Mitarbeiter.

Zugreifen auf materialisierte Ansichten von externen Clients

Um auf materialisierte Ansichten von externen Delta Lake- oder Iceberg-Clients zuzugreifen, die offene APIs nicht unterstützen, können Sie den Kompatibilitätsmodus verwenden. Der Kompatibilitätsmodus erstellt eine schreibgeschützte Version Ihrer materialisierten Ansicht, die von jedem Delta Lake- oder Iceberg-Client zugänglich ist.

  • Last updated on