Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Einführung in materialisierte Ansichten

Materialisierte Ansichten in BigQuery sind vorausberechnete Tabellen, mit denen die Abfrageleistung optimiert und die Ausführungskosten für häufig ausgeführte, vorhersagbare Abfragen gesenkt werden. Durch das regelmäßige Speichern der Ergebnisse einer Abfrage können materialisierte Ansichten die Abfragelatenz und hohe Scan-Kosten reduzieren, wenn große Datasets mit vorhersehbaren Aggregationsmustern wiederholt abgefragt werden. Durch das automatische Zusammenführen von vorab berechneten Daten mit den letzten Änderungen in den Basistabellen garantieren materialisierte Ansichten aktuelle Abfrageergebnisse, ohne dass manuelle Datenpipelines erforderlich sind.

Dieses Dokument richtet sich an Data Engineers, Datenbankadministratoren und BI-Entwickler (Business Intelligence), die leistungsstarke Analysepipelines entwerfen. Damit Sie materialisierte Ansichten erfolgreich implementieren können, sollten Sie mit BigQuery-Datasetstrukturen, GoogleSQL-Aggregationsfunktionen und Abfragekostenstrukturen vertraut sein.

Vorteile von materialisierten Ansichten

In den folgenden Anwendungsfällen wird der Wert von materialisierten Ansichten erläutert:

Daten vorverarbeiten: Sie können die Abfrageleistung verbessern, indem Sie Aggregate, Filter, Joins und Cluster vorbereiten.
Dashboard-Beschleunigung BI-Tools wie Looker, die häufig dieselben aggregierten Messwerte abfragen, z. B. täglich aktive Nutzer, werden unterstützt.
Echtzeitanalysen für große Streams: Schnellere Antworten auf Tabellen mit Streamingdaten mit hoher Geschwindigkeit.
Kostenverwaltung Kosten für wiederholte, teure Abfragen großer Datasets senken

Wichtige Merkmale

Zu den wichtigsten Merkmalen von materialisierten Ansichten gehören:

Keinerlei Wartung erforderlich: BigQuery berechnet materialisierte Ansichten im Hintergrund vor, wenn sich Basistabellen ändern. BigQuery fügt inkrementelle Datenänderungen aus Basistabellen automatisch zu materialisierten Ansichten hinzu, ohne dass der Nutzer eingreifen muss.
Aktuelle Daten: Materialisierte Ansichten geben aktuelle Daten zurück. Wenn Änderungen an Basistabellen die materialisierte Ansicht ungültig machen, werden Daten direkt aus den Basistabellen gelesen. Wenn die Änderungen an den Basistabellen die materialisierte Ansicht nicht entwerten, liest BigQuery die restlichen Daten aus der materialisierten Ansicht und nur die Änderungen aus den Basistabellen.

Das folgende Diagramm zeigt die Logik, die zum Zusammenführen von Echtzeitdatenänderungen verwendet wird:
Intelligente Feinabstimmung. Wenn ein Teil einer Abfrage für eine Basistabelle durch die Abfrage der materialisierten Ansicht gelöst werden kann, leitet BigQuery die Abfrage um, um die materialisierte Ansicht für eine bessere Leistung und Effizienz zu verwenden. Informationen dazu, wie und wann die intelligente Feinabstimmung Abfragen verbessern kann, finden Sie unter Materialisierte Ansichten verwenden.

Das folgende Diagramm zeigt den Workflow für das Umleiten von Anfragen beim Smart Tuning:

Arten von materialisierten Ansichten

Es gibt zwei grundlegende Arten von materialisierten Ansichten:

Inkrementelle materialisierte Ansichten unterstützen nur eine begrenzte Anzahl von Funktionen. Weitere Informationen zur unterstützten SQL-Syntax für materialisierte Ansichten finden Sie unter Materialisierte Ansichten erstellen. Nur inkrementelle materialisierte Ansichten können von der intelligenten Abstimmung profitieren.
Nicht inkrementelle materialisierte Ansichten unterstützen die meisten Syntaxen, die von inkrementellen materialisierten Ansichten nicht unterstützt werden.

Wenn Sie materialisierte Ansichten erstellen, können Sie in BigQuery standardmäßig nur Ansichten auf Grundlage von inkrementellen Abfragen erstellen. Wenn Sie eine nicht inkrementelle Ansicht erstellen möchten, können Sie allow_non_incremental_definition = true in der Definition der materialisierten Ansicht angeben.

Welche Art von materialisierter Ansicht am besten geeignet ist, hängt von Ihrer Situation ab. In der folgenden Tabelle werden die Funktionen von inkrementellen und nicht inkrementellen materialisierten Ansichten verglichen:

Kategorie	Inkrementell	Nicht inkrementell
Abfrage wird unterstützt	Begrenzt	Die meisten Anfragen
Wartung	Kann die Kosten für häufig verwendete Abfragen senken. Informationen zum Aktualisieren materialisierter Ansichten finden Sie unter Inkrementelle Aktualisierungen.	Bei jeder Aktualisierung wird die vollständige Abfrage ausgeführt.
Unterstützung für die intelligente Feinabstimmung	Wird für die meisten Ansichtsabfragen unterstützt.	Nein
Immer aktuelle Ergebnisse	Unterstützt. Inkrementelle Ansichten geben aktuelle Abfrageergebnisse zurück, auch wenn sich die Basistabellen seit der letzten Aktualisierung geändert haben.	Nein

Autorisierte materialisierte Ansichten

Sie können eine autorisierte materialisierte Ansicht erstellen, um eine Teilmenge von Daten aus einem Quelldataset für eine Ansicht in einem sekundären Dataset freizugeben. Sie können diese Ansicht dann für bestimmte Nutzer und Gruppen (Identitäten) freigeben. Nutzer können die Daten abfragen, die Sie in einer Ansicht bereitstellen, aber nicht direkt auf das Quelldataset zugreifen.

Autorisierte Ansichten und autorisierte materialisierte Ansichten werden auf dieselbe Weise autorisiert. Weitere Informationen finden Sie unter Autorisierte Ansichten.

Interaktion mit anderen BigQuery-Features

Die folgenden BigQuery-Features funktionieren transparent mit materialisierten Ansichten:

Erläuterung des Abfrageplans: Der Abfrageplan gibt an, welche materialisierten Ansichten gescannt wurden (sofern vorhanden) und wie viele Bytes aus der materialisierten Ansicht und den Basistabellen insgesamt gelesen werden.
Abfrage-Caching: Die Ergebnisse einer Abfrage, die von BigQuery mit einer materialisierten Ansicht neu geschrieben werden, können im Rahmen der üblichen Beschränkungen (Verwendung deterministischer Funktionen, kein Streaming in die Basistabellen usw.) im Cache gespeichert werden.
Kostenbeschränkung: Wenn Sie die maximal berechneten Bytes angeben und eine Abfrage Daten über dieses Limit hinaus liest, schlägt die Abfrage fehl, ohne dass eine Gebühr anfällt. Das gilt unabhängig davon, ob die Abfrage materialisierte Ansichten, die Basistabellen oder beides verwendet.
Kostenschätzung mit Probelauf: Bei einem Probelauf wird die Logik für das Neuschreiben der Abfrage anhand der verfügbaren materialisierten Ansichten wiederholt und eine Kostenschätzung bereitgestellt. Mit dieser Funktion können Sie testen, ob eine bestimmte Abfrage materialisierte Ansichten verwendet.
Regionenübergreifende Datenreplikation: Materialisierte Ansichten können für BigQuery-Tabellen erstellt werden, für die die regionsübergreifende Replikation aktiviert ist, jedoch nur in der primären Region. Wenn Sie die sekundäre Region verwenden, kann die folgende Fehlermeldung angezeigt werden: The dataset replica of the cross region dataset {PROJECT}:{DATASET} in region {REGION} is read-only because it's not the primary replica.

Zusätzlich zu diesen Funktionen können Sie materialisierte Ansichten für Tabellen mit bestimmten Funktionen erstellen, wie in den folgenden Abschnitten beschrieben.

Tabellen mit aktivem Change Data Capture

Sie können materialisierte Ansichten für Tabellen mit aktivem Change Data Capture (CDC) erstellen. Dieses Muster wird verwendet, um Datenbank- oder Tabellenänderungen kontinuierlich aufzunehmen. Diese materialisierten Ansichten funktionieren wie materialisierte Ansichten über BigQuery-Tabellen, einschließlich der Vorteile einer automatischen Aktualisierung. Materialisierte Ansichten können keine Zusammenführungsabfragen zur Laufzeit ausführen. Sie müssen sie daher mit einem ausreichenden max_staleness konfigurieren, um Zusammenführungsjobs zur Laufzeit zu vermeiden. Weitere Informationen finden Sie unter Einschränkungen von materialisierten Ansichten über Tabellen mit aktivem Change Data Capture.

BigLake-Metadaten-Cache-fähige Tabellen

Materialisierte Ansichten über BigLake-Metadaten-Cache-fähige Tabellen können auf strukturierte Daten verweisen, die in Cloud Storage und Amazon Simple Storage Service (Amazon S3) gespeichert sind. Diese materialisierten Ansichten funktionieren wie materialisierte Ansichten über von BigQuery verwalteten Speichertabellen, einschließlich der Vorteile einer automatischen Aktualisierung und intelligenten Abstimmung. Weitere Vorteile sind die Vorabaggregation, ‑filterung und ‑verknüpfung von Daten, die außerhalb von BigQuery gespeichert sind. Materialisierte Ansichten über BigLake-Tabellen werden in einem von BigQuery verwalteten Speicher gespeichert und weisen alle Eigenschaften dieses Speichers auf.

Wenn Sie eine materialisierte Ansicht über eine Amazon S3-BigLake-Tabelle erstellen, sind die Daten in der materialisierten Ansicht nicht für Joins mit BigQuery-Daten verfügbar. Wenn Sie Amazon S3-Daten in einer materialisierten Ansicht für Joins verfügbar machen möchten, erstellen Sie ein Replikat für materialisierte Ansichten. Sie können Replikate für materialisierte Ansichten nur über autorisierte materialisierte Ansichten erstellen.

Beschränkungen

Für materialisierte Ansichten in BigQuery gelten die funktionalen und betrieblichen Einschränkungen, die in den folgenden Abschnitten beschrieben werden.

SQL- und Syntaxbeschränkungen

Dialect. Es wird nur der GoogleSQL-Dialekt unterstützt.
SQL-Syntax. Materialisierte Ansichten verwenden eine eingeschränkte SQL-Syntax und eine begrenzte Anzahl von Aggregationsfunktionen. Weitere Informationen finden Sie unter Unterstützung von Abfragen für materialisierte Ansichten.
Systemvariablen Materialisierte Ansichten unterstützen keine Systemvariablen, z. B. die Systemvariable @@session_id.
Parametrisierte Datentypen Materialisierte Ansichten können keine parametrisierten Datentypen wie STRING(n) übernehmen oder explizit definieren, da parametrisierte Datentypen nur für Spalten der Basistabelle und Skriptvariablen unterstützt werden.
Spaltenbeschreibungen Sie können Beschreibungen für materialisierte Ansichten festlegen, aber nicht für einzelne Spalten in der materialisierten Ansicht.
Abfrageänderungen Sie können die Abfrage für eine materialisierte Ansicht nach dem Erstellen nicht mehr aktualisieren.
Datenänderungen Sie können die Daten einer materialisierten Ansicht nicht direkt durch Vorgänge wie COPY, EXPORT, LOAD, WRITE oder DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) aktualisieren oder bearbeiten. CPU-intensive Operatoren: CPU-intensive Operatoren wie UNPIVOT oder umfangreiche UNNEST-Transformationen können bei der Abrechnung nach Bedarf zu Aktualisierungsfehlern führen. Um dieses Problem zu beheben, können Sie zum kapazitätsbasierten Preismodell wechseln, die transformierten Daten in der Basistabelle materialisieren, bevor Sie die Ansicht erstellen, oder geplante Abfragen verwenden.

Einschränkungen für Basistabellen und Verschachtelung

Verschachtelung Materialisierte Ansichten können nicht in anderen materialisierten Ansichten verschachtelt werden.
Quelltypen. Materialisierte Ansichten können keine externen Tabellen (außer BigLake-Tabellen), Platzhaltertabellen, logischen Ansichten¹ oder Snapshots abfragen.
Verhalten beim Löschen: Wenn Sie die Basistabelle löschen, ohne zuerst die materialisierte Ansicht zu löschen, schlagen Abfragen und Aktualisierungen der materialisierten Ansicht fehl. Wenn Sie die Basistabelle neu erstellen, müssen Sie auch die materialisierte Ansicht neu erstellen.
Externe Spanner-Datasets. Nur nicht inkrementelle materialisierte Ansichten können Basistabellen für externe Spanner-Datasets haben. Wenn die letzte Aktualisierung einer nicht inkrementellen materialisierten Ansicht außerhalb des Intervalls max_staleness erfolgt ist, werden die Basistabellen des externen Spanner-Datasets gelesen. Weitere Informationen finden Sie unter Materialisierte Ansichten für externe Spanner-Datasets erstellen.
Zwischenspeichern mit Spanner BigQuery speichert Abfrageergebnisse nicht im Cache, wenn die Abfrage für nicht inkrementelle materialisierte Ansichten ausgeführt wird, die auf externe Spanner-Dataset-Tabellen verweisen.

Umfang und regionale Einschränkungen

Organisationsgrenze. Eine materialisierte Ansicht muss sich im selben Projekt oder Organisationsblock wie ihre Basistabellen befinden.
Einstellungen für Veralterung Der Wert der Option max_staleness muss zwischen 30 Minuten und 3 Tagen liegen (einschließlich).
Ressourcenabfragen: Es können Limits für Basistabellenreferenzen und andere Einschränkungen gelten. Weitere Informationen finden Sie unter Kontingente und Limits.

¹ Die Unterstützung für logische Ansichtsreferenzen befindet sich in der Vorschau. Weitere Informationen finden Sie unter Logische Ansichten referenzieren.

Einschränkungen von materialisierten Ansichten über Tabellen mit aktivem CDC

Für materialisierte Ansichten mit aktiven CDC-Basistabellen (Change Data Capture) gelten die folgenden Einschränkungen:

Wenn eine materialisierte Ansicht eine Basistabelle mit aktiver Change Data Capture hat, können Sie nicht in einer Abfrage, die auch auf die materialisierte Ansicht verweist, auf diese Tabelle verweisen.
Wenn Sie eine materialisierte Ansicht für eine Tabelle mit aktivem Change Data Capture erstellen, können in der materialisierten Ansicht keine Laufzeitzusammenführungsjobs der zugrunde liegenden CDC-Tabelle ausgeführt werden. Legen Sie den max_staleness-Wert der materialisierten Ansicht auf mindestens das Doppelte des max_staleness-Werts der Basistabelle fest. Abfragen für eine materialisierte Ansicht schlagen fehl, wenn die aktuelle Version der zugrunde liegenden CDC-Tabelle älter als die max_staleness der materialisierten Ansicht ist.
Sie können die intelligente Abstimmung nicht für materialisierte Ansichten für Tabellen mit aktiver Erfassung von Änderungsdaten verwenden.

Einschränkungen von materialisierten Ansichten über BigLake-Tabellen

Für materialisierte Ansichten über BigLake-Tabellen gelten die folgenden Einschränkungen:

Sie können die materialisierte Ansicht nicht partitionieren. Die Basistabellen können die Apache Hive-Partitionierung verwenden, der Speicher der materialisierten Ansicht kann jedoch nicht in BigLake-Tabellen partitioniert werden. Dies bedeutet, dass jeder Löschvorgang in einer Basistabelle eine vollständige Aktualisierung der materialisierten Ansicht verursacht. Weitere Informationen finden Sie unter Inkrementelle Aktualisierungen.
Der Optionswert --max_staleness der materialisierten Ansicht muss größer sein als der Wert der BigLake-Basistabelle.
Sie können in der Definition einer einzelnen materialisierten Ansicht keinen Join zwischen von BigQuery verwalteten Tabellen und BigLake-Tabellen ausführen.
BigQuery BI Engine (ein schneller In-Memory-Analysedienst) unterstützt keine Beschleunigung von materialisierten Ansichten für BigLake-Tabellen.

Preise für materialisierte Ansichten

Für materialisierte Ansichten fallen Kosten auf folgende Weise an:

Abfragen von materialisierten Ansichten.
Pflegen von materialisierten Ansichten, z. B. wann materialisierte Ansichten aktualisiert werden. Die Kosten für die automatische Aktualisierung werden dem Projekt in Rechnung gestellt, in dem sich die Ansicht befindet. Die Kosten für die manuelle Aktualisierung werden dem Projekt in Rechnung gestellt, in dem der manuelle Aktualisierungsjob ausgeführt wird. Weitere Informationen zur Kostenkontrolle für Wartungen finden Sie unter Jobwartung aktualisieren.
Speichern von Tabellen materialisierter Ansichten.

In der folgenden Tabelle sind die Preiskomponenten für materialisierte Ansichten aufgeführt:

Komponente	On-Demand-Preise	Kapazitätsbasierte Preise
Abfragen	Byte, die von materialisierten Ansichten verarbeitet werden, und alle erforderlichen Teile der Basistabellen.¹	Slots werden während der Abfrage verbraucht.
Wartung	Während der Aktualisierung verarbeitete Byte.	Slots werden während der Aktualisierung benötigt.
Speicher	In materialisierten Ansichten gespeicherte Byte.	In materialisierten Ansichten gespeicherte Byte.

¹ Nach Möglichkeit liest BigQuery nur die Änderungen seit der letzten Aktualisierung der Ansicht. Weitere Informationen finden Sie unter Inkrementelle Aktualisierungen.

Details zu den Speicherkosten

Die Art und Weise, wie BigQuery bestimmte aggregierte Werte speichert, wirkt sich auf die Berechnung der Speichergröße aus. Bei aggregierten Werten für AVG, ARRAY_AGG und APPROX_COUNT_DISTINCT in einer materialisierten Ansicht wird der endgültige Wert nicht direkt gespeichert. BigQuery speichert stattdessen intern eine materialisierte Ansicht als Zwischenskizze. Diese wird verwendet, um den endgültigen Wert zu generieren.

Sehen Sie sich als Beispiel eine materialisierte Ansicht an, die mit dem folgenden Befehl erstellt wurde:

CREATE MATERIALIZED VIEW project-id.my_dataset.my_mv_table AS
SELECT date, AVG(net_paid) AS avg_paid
FROM project-id.my_dataset.my_base_table
GROUP BY date

Während die Spalte avg_paid als NUMERIC oder FLOAT64 angezeigt wird, wird sie intern als BYTES gespeichert. Der Inhalt ist dabei eine Zwischenskizze in einem proprietären Format. Für die Berechnung der Datengröße wird die Spalte als BYTES behandelt.

Workflow „Erste Schritte“

Das Einrichten materialisierter Ansichten umfasst den folgenden Workflow:

Abfrage entwerfen und überprüfen: Erstellen Sie Ihre Aggregationsabfrage anhand der GoogleSQL-Richtlinien.
Materialisierte Ansicht erstellen Führen Sie die CREATE MATERIALIZED VIEW-Anweisung mit der Google Cloud Console, dem bq-Befehlszeilentool oder der BigQuery API aus.
Intelligente Feinabstimmung ausführen BigQuery leitet Abfragen für die Basistabelle automatisch an die materialisierte Ansicht weiter. Es ist nicht erforderlich, dass Abfragen oder Anwendungen Ziele neu schreiben.

Materialisierte Ansichten erstellen