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.

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 auf Projekte, Ordner und Organisationen 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

Zum Abfragen einer materialisierten Ansicht sind die folgenden Berechtigungen 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, siehe Einführung in IAM

Inkrementelle Aktualisierungen

Inkrementenelle Aktualisierungen erfolgen, wenn BigQuery die Daten der im Cache gespeicherten Ansicht mit neuen Daten kombiniert, um konsistente Abfrageergebnisse bereitzustellen, während die materialisierte Ansicht verwendet wird. Bei materialisierten Ansichten mit einer einzelnen Tabelle ist dies möglich, wenn sich die Basistabelle seit der letzten Aktualisierung nicht geändert hat oder nur neue Daten hinzugefügt wurden. Bei JOIN-Aufrufen können nur Tabellen auf der linken Seite von JOIN angehängte Daten enthalten. Wenn sich eine der Tabellen auf der rechten Seite von 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, werden in BigQuery keine inkrementellen Aktualisierungen verwendet. Stattdessen wird automatisch zur ursprünglichen Abfrage zurückgekehrt. 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. Außerdem können materialisierte Ansichten nicht inkrementell aktualisiert werden, wenn sich in ihrer Basistabelle über einen Zeitraum hinweg unverarbeitete Änderungen angesammelt haben, der länger als das Intervall für die Zeitreise der Tabelle ist.

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, ohne dass die gesamte materialisierte Ansicht vollständig aktualisiert werden muss.

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.

Die intelligente Feinabstimmung wird für Folgendes nicht unterstützt:

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

Wenn Sie die automatische Aktualisierung für Ihre materialisierte Ansicht deaktiviert haben und die Tabelle unbearbeitete Änderungen enthält, ist die Abfrage möglicherweise einige Tage lang schneller, kehrt dann aber zur ursprünglichen Abfrage zurück, was zu einer geringeren Verarbeitungsgeschwindigkeit führt. Wenn Sie von materialisierten Ansichten profitieren möchten, aktivieren Sie die automatische Aktualisierung oder aktualisieren Sie die Ansichten regelmäßig manuell. Überwachen Sie außerdem die Aktualisierungsjobs für materialisierte Ansichten, um sicherzustellen, dass sie erfolgreich sind.

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. Jede Ausführung der Abfrage ist vollständig und es werden keine vorherigen Ergebnisse berücksichtigt. Sie zahlen die vollen Rechenkosten 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 eignen sich am besten, wenn Sie die neuesten Daten mit minimaler Latenz und Kosten abfragen und dabei das zuvor berechnete Ergebnis wiederverwenden möchten. 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, um bei der Verarbeitung großer, sich häufig ändernder Datasets eine konsistent hohe Leistung mit kontrollierten Kosten zu erzielen.

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 materialisierte Ansichten immer aktuelle Ergebnisse zurückgeben und Änderungen an ihren Basistabellen seit der letzten Aktualisierung der Ansicht berücksichtigen müssen.

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'