Materialisierte Ansichten verwenden

Dieses Dokument enthält zusätzliche Informationen zu materialisierten Ansichten und ihrer Verwendung. Bevor Sie dieses Dokument lesen, sollten Sie sich mit der Einführung in materialisierte Ansichten und dem Erstellen materialisierter Ansichten vertraut machen.

Materialisierte Ansichten abfragen

Sie können materialisierte Ansichten genauso wie eine normale Tabelle oder Standardansicht direkt abfragen. Abfragen für materialisierte Ansichten sind immer mit Abfragen für die Basistabellen der Ansicht konsistent, auch wenn sich diese Tabellen seit der letzten Aktualisierung der materialisierten Ansicht geändert haben. Die Abfrage löst nicht automatisch eine materialisierte Aktualisierung aus.

Hinweis: Wenn Sie eine Basistabelle löschen, ohne zuerst die materialisierte Ansicht zu löschen, schlagen Abfragen über die materialisierte Ansicht fehl. Sie müssen die materialisierte Ansicht neu erstellen, nachdem Sie die Basistabelle neu erstellt haben, um sie noch einmal abzufragen.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die BigQuery-Datenbetrachter-IAM-Rolle (roles/bigquery.dataViewer) für die Basistabelle der materialisierten Ansicht und der materialisierten Ansicht selbst zu gewähren, um die Berechtigungen zu erhalten, die Sie zum Abfragen einer materialisierten Ansicht benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die zum Abfragen einer materialisierten Ansicht erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind zum Abfragen einer materialisierten Ansicht erforderlich:

• bigquery.tables.get
• bigquery.tables.getData

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Diese Berechtigungen sind für Abfragen erforderlich, um von der intelligenten Abstimmung zu profitieren.

Weitere Informationen zu IAM-Rollen in BigQuery finden Sie unter Einführung in IAM.

Inkrementelle Aktualisierungen

BigQuery kombiniert die Daten der im Cache gespeicherten Ansicht mit neuen Daten, um konsistente Abfrageergebnisse bereitzustellen, wenn die materialisierte Ansicht verwendet wird. Bei materialisierten Ansichten mit einer einzelnen Tabelle ist dies möglich, wenn die Basistabelle seit der letzten Aktualisierung nicht geändert wurde oder nur neue Daten hinzugefügt wurden. Bei JOIN-Ansichten können nur Tabellen auf der linken Seite von JOIN angehängte Daten enthalten. Wenn sich eine der Tabellen auf der rechten Seite einer JOIN geändert hat, kann die Ansicht nicht schrittweise aktualisiert werden.

Wenn die Basistabelle seit der letzten Aktualisierung Änderungen oder Löschungen erfahren hat oder wenn sich die Basistabellen der materialisierten Ansicht auf der rechten Seite von JOIN geändert haben, nutzt BigQuery automatisch die ursprüngliche Abfrage. Weitere Informationen zu Joins und materialisierten Ansichten finden Sie unter Joins. Im Folgenden finden Sie Beispiele für die Google Cloud Console, das bq-Befehlszeilentool und API-Aktionen, die zum Aktualisieren oder Löschen führen können:

• UPDATE-, MERGE- oder DELETE-Anweisungen der Datenbearbeitungssprache (Data Manipulation Language, DML)
• Abgeschnittener Text
• Ablauf der Partition

Die folgenden Metadatenvorgänge verhindern ebenfalls, dass eine materialisierte Ansicht schrittweise aktualisiert wird:

• Ablauf der Partition ändern
• Spalte aktualisieren oder löschen

Wenn eine materialisierte Ansicht nicht schrittweise aktualisiert werden kann, werden ihre im Cache gespeicherten Daten von Abfragen erst verwendet, wenn die Ansicht automatisch oder manuell aktualisiert wurde. Weitere Informationen dazu, warum ein Job keine Daten von materialisierten Ansichten verwendet hat, finden Sie unter Warum materialisierte Ansichten abgelehnt wurden.

Partitionsausrichtung

Bei der Partitionierung einer materialisierten Ansicht sorgt BigQuery dafür, dass seine Partitionen an den Partitionen der Partitionierungsspalte der Basistabelle ausgerichtet sind. Ausgerichtet bedeutet, dass die Daten aus einer bestimmten Partition der Basistabelle zur selben Partition der materialisierten Ansicht beitragen. Beispielsweise würde eine Zeile aus der Partition 20220101 der Basistabelle nur zur Partition 20220101 der materialisierten Ansicht beitragen.

Bei der Partitionierung einer materialisierten Ansicht tritt bei jeder einzelnen Partition das Verhalten auf, das unter Inkrementelle Aktualisierungen beschrieben wird. Wenn beispielsweise Daten in einer Partition der Basistabelle gelöscht werden, kann BigQuery weiterhin die anderen Partitionen der materialisierten Ansicht verwenden.

Materialisierte Ansichten mit Inner-Joins können nur an einer ihrer Basistabellen ausgerichtet werden. Wenn sich eine der nicht ausgerichteten Basistabellen ändert, wirkt sich dies auf die gesamte Ansicht aus.

Intelligente Feinabstimmung

BigQuery schreibt Abfragen automatisch neu, um materialisierte Ansichten zu verwenden, wann immer dies möglich ist. Das automatische Umschreiben verbessert die Abfrageleistung und die Kosten und ändert die Abfrageergebnisse nicht. Die Abfrage löst nicht automatisch eine materialisierte Aktualisierung aus. Damit eine Abfrage neu geschrieben wird, muss die materialisierte Ansicht die folgenden Bedingungen erfüllen:

• Sie muss zum selben Dataset gehören wie eine der Basistabellen.
• Sie muss denselben Satz von Basistabellen wie die Abfrage verwenden.
• Sie muss alle gelesenen Spalten einschließen.
• Sie muss alle gelesenen Zeilen einschließen.

Beispiele für die intelligente Feinabstimmung

Betrachten Sie das folgende Beispiel für eine Abfrage der materialisierten Ansicht:

SELECT
  store_id,
  CAST(sold_datetime AS DATE) AS sold_date
  SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
  CAST(sold_datetime AS DATE) >= '2021-01-01' AND
  promo_id IS NOT NULL
GROUP BY 1, 2

Die folgenden Beispiele zeigen Abfragen und warum diese Abfragen automatisch anhand dieser Ansicht neu geschrieben werden oder nicht.

Abfrage	Neu schreiben?	Grund
SELECT SUM(net_paid) AS sum_paid, SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2021-01-01' AND promo_id IS NOT NULL	Nein	Die Ansicht muss alle gelesenen Spalten enthalten. Die Ansicht enthält „SUM_net_paid“ nicht.
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2021-01-01' AND promo_id IS NOT NULL	Ja
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2021-01-01' AND promo_id IS NOT NULL AND customer_id = 12345	Nein	Die Ansicht muss alle gelesenen Spalten enthalten. Die Ansicht enthält 'customer' nicht.
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE sold_datetime= '2021-01-01' AND promo_id IS NOT NULL	Nein	Die Ansicht muss alle gelesenen Spalten enthalten. 'sold_datetime' ist keine Ausgabe; 'CAST(sold_datetime AS DATE)' aber schon.
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2021-01-01' AND promo_id IS NOT NULL AND store_id = 12345	Ja
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2021-01-01' AND promo_id = 12345	Nein	Die Ansicht muss alle gelesenen Zeilen enthalten. 'promo_id' ist keine Ausgabe. Daher kann der restriktivere Filter nicht auf die Ansicht angewendet werden.
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'	Nein	Die Ansicht muss alle gelesenen Zeilen enthalten. Der Ansicht filtert für Datumsangaben im Jahr 2021 und danach, die Abfrage gibt aber Datumsangaben aus 2020 zurück.
SELECT SUM(net_profit) AS sum_profit FROM dataset.store_sales WHERE CAST(sold_datetime AS DATE) >= '2022-01-01' AND promo_id IS NOT NULL	Ja

Warum eine Abfrage neu geschrieben wurde

Prüfen Sie den Abfrageplan, um festzustellen, ob eine Abfrage durch intelligente Feinabstimmung umgeschrieben wurde, um eine materialisierte Ansicht zu verwenden. Wenn die Abfrage neu geschrieben wurde, enthält der Abfrageplan den Schritt READ my_materialized_view. Dabei ist my_materialized_view der Name der verwendeten materialisierten Ansicht. Informationen dazu, warum eine Abfrage keine materialisierte Ansicht verwendet hat, finden Sie unter Warum materialisierte Ansichten abgelehnt wurden.

Warum materialisierte Ansichten abgelehnt wurden

Abfragen können aus verschiedenen Gründen keine materialisierte Ansicht verwenden. Die Gründe für die Ablehnung einer materialisierten Ansicht hängen vom verwendeten Abfragetyp ab:

• Direkte Abfrage der materialisierten Ansicht
• Indirekte Abfrage, bei der die intelligente Abstimmung möglicherweise die materialisierte Ansicht verwendet

In den folgenden Abschnitten wird erläutert, warum eine materialisierte Ansicht abgelehnt worden sein kann.

Direkte Abfrage von materialisierten Ansichten

Direkte Abfragen von materialisierten Ansichten verwenden unter bestimmten Umständen möglicherweise keine im Cache gespeicherten Daten. Anhand der folgenden Schritte können Sie ermitteln, warum die Daten der materialisierten Ansicht nicht verwendet wurden:

1. Führen Sie die Schritte unter Nutzung von materialisierten Ansichten überwachen aus und suchen Sie im Feld materialized_view_statistics für die Abfrage die materialisierte Zielansicht.
2. Wenn chosen in den Statistiken vorhanden ist und der Wert TRUE ist, wird die materialisierte Ansicht von der Abfrage verwendet.
3. Informationen zu den nächsten Schritten finden Sie im Feld rejected_reason. In den meisten Fällen können Sie die materialisierte Ansicht manuell aktualisieren oder auf die nächste automatische Aktualisierung warten.

Abfrage mit intelligenter Feinabstimmung

1. Führen Sie die Schritte unter Nutzung von materialisierten Ansichten überwachen aus und suchen Sie die materialisierte Zielansicht im Feld materialized_view_statistics für die Abfrage.
2. Weitere Informationen finden Sie unter rejected_reason. Wenn der Wert für rejected_reason beispielsweise COST ist, hat die intelligente Feinabstimmung effizientere Datenquellen im Hinblick auf Kosten und Leistung identifiziert.
3. Wenn die materialisierte Ansicht nicht vorhanden ist, versuchen Sie eine direkte Abfrage der materialisierten Ansicht und führen Sie die Schritte unter Direkte Abfrage der materialisierten Ansichten aus.
4. Wenn die direkte Abfrage nicht die materialisierte Ansicht verwendet, stimmt die Form der materialisierten Ansicht nicht mit der Abfrage überein. Weitere Informationen zur intelligenten Feinabstimmung und zum Umschreiben von Abfragen mithilfe von materialisierten Ansichten finden Sie unter Beispiele für die intelligente Feinabstimmung.

Häufig gestellte Fragen

Wann sollte ich geplante Abfragen und wann materialisierte Ansichten verwenden?

Geplante Abfragen sind eine praktische Möglichkeit, beliebig komplexe Berechnungen regelmäßig durchzuführen. Eine solche Abfrage wird dabei immer vollständig ausgeführt. Die vorherigen Ergebnisse werden nicht verwendet und Sie zahlen den vollen Preis für die Abfrage. Geplante Abfragen eignen sich hervorragend, wenn Sie nicht die neuesten Daten benötigen und wenn eventuell veraltete Daten kein Problem darstellen.

Materialisierte Ansichten sind gut geeignet, wenn Sie immer die neuesten Daten abfragen und gleichzeitig Latenz sowie Kosten reduzieren möchten. Dazu können Sie das zuvor berechnete Ergebnis wiederverwenden. Materialisierte Ansichten lassen sich als Pseudoindexe nutzen, um Abfragen der Basistabelle zu beschleunigen, ohne bestehende Workflows zu ändern. Mit der Option --max_staleness können Sie eine akzeptable Veralterung für materialisierte Ansichten definieren und so bei der Verarbeitung großer, sich häufig ändernder Datasets eine dauerhaft hohe Leistung mit kontrollierten Kosten gewährleisten.

Als allgemeine Richtlinie gilt: Verwenden Sie materialisierte Ansichten, wann immer möglich und wenn keine beliebig komplexen Berechnungen ausgeführt werden müssen.

Einige Abfragen über materialisierte Ansichten sind langsamer als die gleichen Abfragen über manuell materialisierte Tabellen. Warum ist das so?

Im Allgemeinen ist eine Abfrage über eine materialisierte Ansicht nicht immer so leistungsfähig wie eine Abfrage über die entsprechende materialisierte Tabelle. Der Grund ist, dass eine materialisierte Ansicht garantiert, dass immer ein frisches Ergebnis zurückgegeben wird und dass Änderungen in den Basistabellen berücksichtigt werden, die seit der letzten Aktualisierung der Ansicht hinzugefügt wurden.

Stellen Sie sich Folgendes vor:

CREATE MATERIALIZED VIEW my_dataset.my_mv AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

CREATE TABLE my_dataset.my_materialized_table AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

Zum Beispiel diese Abfrage:

  SELECT * FROM my_dataset.my_mv LIMIT 10

wird in der Regel viel langsamer ausgeführt als diese Abfrage:

  SELECT * FROM my_dataset.my_materialized_table LIMIT 10

Um konsistente aktuelle Ergebnisse zurückzugeben, muss BigQuery neue Zeilen in der Basistabelle abfragen und diese in der materialisierten Ansicht zusammenführen, bevor das Prädikat „LIMIT 10“ angewendet wird. Daher bleibt die Langsamkeit, auch wenn die materialisierte Ansicht vollständig aktuell ist.

Auf der anderen Seite sind Aggregationen über materialisierte Ansichten in der Regel genauso schnell wie Abfragen für die materialisierte Tabelle. Beispiel:

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'

Sollte so schnell wie dies sein:

  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'