Fehlerbehebung bei materialisierten Ansichten

In diesem Dokument erfahren Sie, wie Sie häufige Probleme mit materialisierten Ansichten in BigQuery beheben, z. B. Fehler beim Erstellen materialisierter Ansichten, Aktualisierungsfehler und unerwartete Abfrageleistung.

Diagnose-Workflow

Wenn Sie ein Problem mit einer materialisierten Ansicht untersuchen, führen Sie die folgenden Diagnoseschritte aus, um die Ursache zu ermitteln:

  1. Tabellentyp und Metadaten prüfen Prüfen Sie, ob die Zieltabelle eine materialisierte Ansicht ist, und sehen Sie sich die Konfigurationsoptionen an:

    SELECT
 table_name,
 table_type
FROM
 `PROJECT_ID.DATASET`.INFORMATION_SCHEMA.TABLES
WHERE
 table_name = 'MATERIALIZED_VIEW';

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Das Projekt, das die materialisierte Ansicht enthält.
    • DATASET: das Dataset, das die materialisierte Ansicht enthält.
    • MATERIALIZED_VIEW: der Name der materialisierten Ansicht.

    Wenn Sie Konfigurationsoptionen wie enable_refresh, refresh_interval_minutes und max_staleness prüfen möchten, fragen Sie die INFORMATION_SCHEMA.TABLE_OPTIONS-Ansicht ab:

    SELECT
 table_name,
 option_name,
 option_value
FROM
 `PROJECT_ID.DATASET`.INFORMATION_SCHEMA.TABLE_OPTIONS
WHERE
 table_name = 'MATERIALIZED_VIEW';

  2. Status der letzten Aktualisierung prüfen Fragen Sie die Ansicht INFORMATION_SCHEMA.MATERIALIZED_VIEWS ab, um zu prüfen, wann die Ansicht zuletzt aktualisiert wurde und ob beim letzten automatischen Aktualisieren Fehler aufgetreten sind:

    SELECT
 table_name,
 last_refresh_time,
 refresh_watermark,
 last_refresh_status
FROM
 `PROJECT_ID.DATASET`.INFORMATION_SCHEMA.MATERIALIZED_VIEWS
WHERE
 table_name = 'MATERIALIZED_VIEW';

    Wenn last_refresh_status nicht NULL ist, ist der letzte automatische Aktualisierungsjob fehlgeschlagen. Wenn last_refresh_time NULL oder älter ist, wurde die materialisierte Ansicht noch nie erfolgreich aktualisiert oder die Aktualisierung ist fehlgeschlagen.

  3. Aktualisierungsjobverlauf und Fehler prüfen Fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS_BY_PROJECT ab, um aktuelle automatische Aktualisierungsjobs zu prüfen:

    SELECT
 job_id,
 creation_time,
 end_time,
 state,
 error_result.reason AS error_reason,
 error_result.message AS error_message,
 total_slot_ms,
 total_bytes_processed
FROM
 `region-REGION`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
 job_id LIKE '%materialized_view_refresh_%'
 AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
 creation_time DESC
LIMIT 50;

    Ersetzen Sie REGION durch die Region Ihres Datasets, z. B. us oder europe-west3.

  4. Statistiken zur Abfrageausführung und zur intelligenten Optimierung ansehen: Wenn eine Abfrage langsamer als erwartet ausgeführt wird, prüfen Sie das Feld materialized_view_statistics in den Jobstatistiken, um festzustellen, ob die materialisierte Ansicht vom Abfrageoptimierungstool verwendet wurde:

    SELECT
 job_id,
 total_slot_ms,
 total_bytes_billed,
 materialized_view_statistics
FROM
 `region-REGION`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
 job_id = 'JOB_ID';

    Ersetzen Sie JOB_ID durch die ID des Abfragejobs.

Fehler beim Erstellen materialisierter Ansichten beheben

In diesem Abschnitt werden Fehler beschrieben, die beim Erstellen von materialisierten Ansichten auftreten können, sowie ihre Ursachen und Schritte zur Fehlerbehebung.

Nicht unterstützter SQL-Operator oder nicht unterstützte SQL-Syntax

Fehlermeldung:

Unsupported operator in materialized view: KEYWORD

oder

Materialized view queries do not support FEATURE

Ursache:

Inkrementelle materialisierte Ansichten unterstützen eine eingeschränkte Teilmenge der SQL-Syntax, um die inkrementelle Aktualisierung und intelligente Optimierung zu ermöglichen. Dieser Fehler kann auftreten, wenn die Abfrage, mit der Ihre materialisierte Ansicht definiert wird, nicht unterstützte Funktionen enthält, z. B.:

  • Nicht deterministische Funktionen (z. B. CURRENT_TIMESTAMP(), RAND() oder SESSION_USER())
  • Analyse-Fensterfunktionen mit OVER()
  • ORDER BY- oder LIMIT-Klauseln
  • DISTINCT ohne Aggregation
  • Unterabfragen in den WHERE- oder SELECT-Klauseln
  • Nutzerdefinierte Funktionen (UDFs)

Lösung:

  • Sehen Sie sich die Liste der nicht unterstützten SQL-Funktionen an.

  • Wenn für Ihre Abfrage erweiterte SQL-Funktionen erforderlich sind, können Sie eine nicht inkrementelle materialisierte Ansicht erstellen, indem Sie allow_non_incremental_definition = true festlegen und ein max_staleness-Intervall definieren:

    CREATE MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 60,
max_staleness = INTERVAL "4" HOUR,
allow_non_incremental_definition = true
) AS
SELECT
...

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Das Projekt, das die materialisierte Ansicht enthält.
    • DATASET: das Dataset, das die materialisierte Ansicht enthält.
    • MATERIALIZED_VIEW: der Name der materialisierten Ansicht.

    Nicht inkrementelle materialisierte Ansichten unterstützen eine größere Anzahl von SQL-Abfragen, führen aber immer vollständige Aktualisierungen durch und unterstützen keine intelligente Optimierung.

  • Wenn die erforderliche SQL-Syntax in nicht inkrementellen materialisierten Ansichten nicht unterstützt wird, verwenden Sie eine logische Ansicht oder eine geplante Abfrage, um Ergebnisse in eine Zieltabelle zu schreiben.

Ungültiger „max_staleness“-Wert bei CDC-Basistabelle

Fehlermeldung:

Materialized view PROJECT_ID:DATASET.MATERIALIZED_VIEW has a CDC table as base table PROJECT_ID:DATASET.TABLE but does not have valid max_staleness. Materialized views over CDC tables must have max_staleness set at least 2 times the base table's max_staleness: 0-0 0 0:0:0

Ursache:

Wenn Sie eine materialisierte Ansicht für eine CDC-Basistabelle (Change Data Capture) erstellen, muss die Option max_staleness der materialisierten Ansicht auf mindestens das Doppelte des Werts der Option max_staleness der Basistabelle konfiguriert werden.

Lösung:

  1. Prüfen Sie den max_staleness-Wert der CDC-Basistabelle, indem Sie die Ansicht INFORMATION_SCHEMA.TABLE_OPTIONS abfragen.
  2. Legen Sie die Option max_staleness der materialisierten Ansicht auf einen Wert fest, der mindestens doppelt so hoch ist wie der max_staleness-Wert der Basistabelle. Wenn die Basis-CDC-Tabelle beispielsweise einen max_staleness-Wert von 15 Minuten hat, legen Sie den max_staleness-Wert der materialisierten Ansicht auf mindestens 30 Minuten fest. Weitere Informationen finden Sie unter DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) in GoogleSQL im Abschnitt zur ALTER MATERIALIZED VIEW SET OPTIONS-Anweisung.

Partitionierte materialisierte Ansicht über nicht partitionierte Basistabelle

Fehlermeldung:

Partitioned incremental materialized view must be created on top of partitioned managed storage base table.

Ursache:

Wenn Sie eine partitionierte inkrementelle materialisierte Ansicht erstellen möchten, muss auch die zugrunde liegende Basistabelle partitioniert sein und die Partitionierungsspalte der materialisierten Ansicht muss mit der Partitionierungsspalte der Basistabelle übereinstimmen.

Lösung:

  • Wenn die materialisierte Ansicht partitioniert werden soll, muss die Basistabelle partitioniert sein. Konfigurieren Sie die materialisierte Ansicht so, dass dieselbe Partitionierungsspalte verwendet wird. Weitere Informationen zu Partitionsausrichtung.
  • Wenn die Basistabelle nicht partitioniert ist, erstellen Sie die materialisierte Ansicht ohne PARTITION BY-Klausel.
  • Wenn Sie eine partitionierte Ansicht für eine nicht partitionierte Tabelle benötigen, erstellen Sie eine nicht inkrementelle materialisierte Ansicht mit allow_non_incremental_definition = true und max_staleness. Bei nicht inkrementellen materialisierten Ansichten ist keine Partitionsausrichtung mit Basistabellen erforderlich.

Regionsübergreifendes Dataset-Replikat ist schreibgeschützt

Fehlermeldung:

The dataset replica of the cross region dataset 'PROJECT_ID:DATASET' in region 'REGION' is read-only because it's not the primary replica.

Ursache:

Wenn Sie die regionsübergreifende Dataset-Replikation verwenden, sind sekundäre Replikate schreibgeschützt. Sie können keine materialisierte Ansicht in einer sekundären Replikatregion erstellen.

Lösung:

Erstellen Sie die materialisierte Ansicht in der primären Region des replizierten Datasets. Wenn Sie die materialisierte Ansicht in der Replikatregion benötigen, erstellen Sie ein Replikat der materialisierten Ansicht in dieser Region. Weitere Informationen finden Sie unter Replikate von materialisierten Ansichten verwalten.

Limit für die Basistabelle überschreiten

Fehlermeldung:

Materialized views support at most 10 source tables, query has NUMBER_OF_SOURCE_TABLES

Ursache:

Materialisierte BigQuery-Ansichten unterstützen Joins für maximal 10 Basistabellen.

Lösung:

Refaktorieren Sie die Abfrage, mit der die materialisierte Ansicht definiert wird, sodass sie auf maximal 10 Basistabellen verweist. Wenn in Ihrer Architektur mehr als 10 Tabellen verknüpft werden müssen, sollten Sie statische Tabellen oder Dimensionstabellen in Zwischentabellen vorab verknüpfen oder eine geplante Abfrage oder eine Dataform-Pipeline verwenden.

Ressourcenüberschreitung beim Erstellen einer materialisierten Ansicht

Fehlermeldung:

Resources exceeded during query execution: The data accessed in this query is too large; consider accessing fewer tables, or for partitioned tables, fewer partitions.

Ursache:

Wenn Sie eine materialisierte Ansicht erstellen, führt BigQuery eine erste vollständige Aktualisierung durch, um die Ansicht zu füllen. Wenn die zugrunde liegende Basistabelle sehr viele nicht partitionierte Daten enthält oder die Ansicht Zwischenaggregationen mit hoher Kardinalität erzeugt, kann die erste Aktualisierung die Slot-Arbeitsspeicher- oder Abfragelimits überschreiten.

Lösung:

  • Fügen Sie der WHERE-Klausel der materialisierten Ansicht Filterbedingungen hinzu, um den Umfang der gescannten Daten auf die erforderliche Teilmenge zu beschränken.
  • Richten Sie die Partitionierung der materialisierten Ansicht an der Partitionierung der Basistabelle aus, um Partitionen bei Aktualisierungen zu entfernen.
  • Wenn Sie On-Demand-Rechenleistung verwenden, sollten Sie BigQuery-Editionen mit dedizierten Slot-Reservierungen verwenden, um genügend Rechenleistung für große Aktualisierungen bereitzustellen.

Probleme mit BigLake-Tabellen und Metadaten-Caching

Symptome:

Materialisierte Ansichten über externe BigLake-Tabellen können nicht erstellt oder aktualisiert werden.

Ursache:

Für materialisierte Ansichten über externe Tabellen gelten bestimmte architektonische Anforderungen:

  • Materialisierte Ansichten werden nur für BigLake-Tabellen mit aktiviertem Metadaten-Caching unterstützt.
  • Der max_staleness-Wert der materialisierten Ansicht muss größer sein als der max_staleness-Wert der zugrunde liegenden BigLake-Basistabelle.
  • Eine materialisierte Ansicht kann auf externe BigLake-Tabellen oder von BigQuery verwaltete Speichertabellen verweisen, aber die Typen können nicht in einer einzelnen materialisierten Ansicht kombiniert werden.

Lösung:

  1. Achten Sie darauf, dass das Metadaten-Caching für alle zugrunde liegenden BigLake-Basistabellen aktiviert ist.
  2. Konfigurieren Sie max_staleness für die materialisierte Ansicht auf einen Wert, der höher ist als das Metadatencache-Intervall der Basistabellen. Wenn das Cache-Intervall der Basistabelle beispielsweise 30 Minuten beträgt, legen Sie max_staleness der materialisierten Ansicht auf mindestens 45 Minuten fest, um einen Puffer für die Aktualisierung zu schaffen.
  3. Mischen Sie keine externen Tabellen und verwalteten Tabellen in einer Definition für materialisierte Ansichten.

Probleme beim Aktualisieren beheben

In diesem Abschnitt werden häufige Ursachen für Aktualisierungsfehler und Leistungsverzögerungen bei materialisierten Ansichten beschrieben.

Änderungen am Basistabellenschema (invalidQuery)

Symptome:

In der Spalte last_refresh_status in INFORMATION_SCHEMA.MATERIALIZED_VIEWS wird ein invalidQuery-Fehler angezeigt und automatische Aktualisierungen werden nicht mehr ausgeführt.

Ursache:

Wenn sich das Schema einer Basistabelle ändert, z. B. wenn eine Spalte, auf die von der materialisierten Ansicht verwiesen wird, gelöscht, umbenannt oder der Datentyp einer Spalte geändert wird, wird die zugrunde liegende Abfrage, mit der die materialisierte Ansicht definiert wird, ungültig.

Lösung:

In BigQuery kann das Spaltenschema einer vorhandenen materialisierten Ansicht nicht geändert werden. So beheben Sie die Schemainvalidierung:

  1. Erstellen Sie die materialisierte Ansicht mit der Anweisung CREATE OR REPLACE MATERIALIZED VIEW neu:

    CREATE OR REPLACE MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
OPTIONS (
 enable_refresh = true,
 refresh_interval_minutes = 30
) AS
SELECT
 ...

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Das Projekt, das die materialisierte Ansicht enthält.
    • DATASET: das Dataset, das die materialisierte Ansicht enthält.
    • MATERIALIZED_VIEW: der Name der materialisierten Ansicht.

  2. Prüfen Sie, ob die neue Definition dem aktualisierten Schema der Basistabelle entspricht.

Ablauf, Kürzung oder DML-Änderungen von Basistabellenpartitionen

Symptome:

Aktualisierungen der materialisierten Ansicht schlagen fehl oder Abfragen für die materialisierte Ansicht greifen auf die Basistabelle zurück und werden langsam ausgeführt.

Ursache:

Die folgenden Basistabellenoperationen machen vorhandene Daten in materialisierten Ansichten ungültig:

  • Basistabelle oder Basistabellenpartition kürzen (TRUNCATE TABLE)
  • Ablauf von Partitionen in einer Basistabelle
  • DELETE- oder MERGE-DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) für nicht partitionierte Tabellen oder sekundäre verknüpfte Basistabellen

Wenn diese Vorgänge ausgeführt werden, werden die betroffenen Partitionen (oder die gesamte materialisierte Ansicht für nicht partitionierte Tabellen) als ungültig markiert.

Lösung:

  1. Lösen Sie manuell eine Aktualisierung aus, um die materialisierte Ansicht in einen gültigen Zustand zurückzusetzen:

    CALL BQ.REFRESH_MATERIALIZED_VIEW('PROJECT_ID.DATASET.MATERIALIZED_VIEW');

  2. Wenn Sie Batch-ETL-Pipelines ausführen, in denen regelmäßig DML-Anweisungen ausgeführt oder Daten gekürzt werden, deaktivieren Sie die automatische Aktualisierung und rufen Sie BQ.REFRESH_MATERIALIZED_VIEW am Ende Ihrer ETL-Pipeline auf. Weitere Informationen finden Sie unter Automatische Aktualisierung.

Aktualisierungsjobs, die das Zeitlimit überschreiten

Symptome:

Aktualisierungsjobs schlagen nach mehreren Stunden (bis zu 12 Stunden) mit einem Zeitüberschreitungsfehler fehl.

Ursache:

Wenn die Basistabellen größer werden, steigt das Datenvolumen, das während einer Aktualisierung verarbeitet wird. Wenn in der Abfrage für die materialisierte Ansicht keine Zeilen gefiltert werden oder die Ansicht aufgrund einer vollständigen Ungültigmachung keine inkrementellen Aktualisierungen ausführen kann, ist für jede Aktualisierung ein vollständiger Scan der Basistabellen erforderlich, wodurch die Slotzeit überschritten werden kann.

Lösung:

  • Fügen Sie der WHERE-Klausel der materialisierten Ansicht Filterkriterien hinzu, um unnötige Verlaufsdaten einzuschränken.
  • Achten Sie darauf, dass die materialisierte Ansicht an den Partitionen der Basistabelle ausgerichtet ist, damit nur geänderte Partitionen inkrementell aktualisiert werden.
  • Weisen Sie eine Slotreservierung mit ausreichender Kapazität für die Aktualisierungsarbeitslast zu.

Doppelte Aktualisierungsnachricht

Nachricht:

Materialized view is already being refreshed.

Ursache:

Wenn Basistabellen in einer JOIN-materialisierten Ansicht gleichzeitig aktualisiert werden oder wenn eine manuelle Aktualisierung ausgelöst wird, während eine automatische Aktualisierung bereits läuft, erkennt BigQuery die gleichzeitige Aktualisierung und bricht den doppelten Job ab.

Lösung:

Dieses Verhalten ist normal und vorübergehend. Der doppelte Job wird beendet, um eine redundante Verarbeitung zu verhindern. Ihnen wird der doppelte Aktualisierungsversuch nicht in Rechnung gestellt. Sie müssen nichts weiter tun.

Verzögerungen beim Aktualisieren von Streamingdaten (schreiboptimierter Speicher)

Symptome:

Abfragen für Basistabellen mit Streamingdaten mit hoher Geschwindigkeit werden nicht sofort in der materialisierten Ansicht angezeigt oder Abfragen greifen auf die Basistabelle zurück.

Ursache:

Mit der Storage Write API in BigQuery gestreamte Daten werden zuerst im schreiboptimierten Speicher (Streamingpuffer) gespeichert. Die Aktualisierungsjobs der materialisierten Ansicht verarbeiten Daten, nachdem sie übernommen und aus dem Streamingpuffer in den optimierten Spaltenspeicher konvertiert wurden.

Um die Echtzeitkonsistenz aufrechtzuerhalten, werden bei Abfragen, die aus der materialisierten Ansicht gelesen werden, committed Daten aus der materialisierten Ansicht und gleichzeitig das Delta direkt aus dem Streamingpuffer der Basistabelle gelesen.

Lösung:

  • Wenn eine Echtzeit-Lesekonsistenz für Streamingdaten erforderlich ist, kombiniert der Abfrageplaner automatisch Daten aus materialisierten Ansichten mit Deltas aus der Basistabelle.
  • Wenn keine Echtzeitkonsistenz erforderlich ist und Sie vermeiden möchten, dass der Streamingpuffer bei jeder Abfrage gescannt wird, legen Sie max_staleness für die materialisierte Ansicht fest (z. B. max_staleness = INTERVAL "15" MINUTE). Abfragen können dann direkt aus der vorab berechneten materialisierten Ansicht gelesen werden, ohne dass eine Deltaberechnung erforderlich ist.

Probleme mit der Abfrageleistung beheben und Smart Tuning verwenden

In diesem Abschnitt wird beschrieben, wie Sie Probleme mit Abfragen beheben, die langsamer als erwartet ausgeführt werden oder bei denen die automatische Optimierung nicht genutzt wird.

Nutzung der intelligenten Feinabstimmung prüfen

Wenn Sie eine Basistabelle abfragen, verwendet BigQuery die intelligente Abstimmung, um die Abfrage automatisch so umzuschreiben, dass eine verfügbare materialisierte Ansicht verwendet wird, wenn dadurch die Leistung verbessert und die Kosten gesenkt werden.

Wenn Sie prüfen möchten, ob für eine Abfrage eine materialisierte Ansicht verwendet wurde, sehen Sie sich das Feld materialized_view_statistics in den Details des Abfragejobs an oder fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS_BY_PROJECT ab:

SELECT
  job_id,
  total_slot_ms,
  total_bytes_billed,
  mv.table_reference.dataset_id,
  mv.table_reference.table_id,
  mv.chosen,
  mv.rejected_reason
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS_BY_PROJECT,
  UNNEST(materialized_view_statistics.materialized_view) AS mv
WHERE
  job_id = 'JOB_ID';

Ersetzen Sie Folgendes:

  • REGION: Die Region Ihres Datasets, z. B. us oder europe-west3.
  • JOB_ID: die ID des Abfragejobs.

Im materialized_view_statistics-Objekt enthält jeder Eintrag im materialized_view-Array die folgenden Felder:

  • table_reference: gibt den Kandidaten für die materialisierte Ansicht an.
  • chosen: Ein boolescher Wert, der angibt, ob der Query-Optimierer die materialisierte Ansicht für die Ausführung ausgewählt (true) oder abgelehnt (false) hat.
  • estimated_bytes_saved: die geschätzte Anzahl von Byte, die durch die Verwendung der materialisierten Ansicht nicht gescannt werden mussten.
  • rejected_reason: Wenn chosen false ist, wird der Grund angegeben, warum die materialisierte Ansicht vom Optimierungstool abgelehnt wurde.

Weitere Informationen zu Ablehnungsgründen und dem rejected_reason-Enum finden Sie unter Warum materialisierte Ansichten abgelehnt wurden.

Häufige Gründe für die Ablehnung einer materialisierten Ansicht

Wenn chosen gleich false ist, untersuchen Sie den Wert von rejected_reason, um die Ursache zu ermitteln:

rejected_reason Wert Beschreibung Lösung
NO_DATA Die materialisierte Ansicht enthält keine Daten im Cache, da sie noch nicht aktualisiert wurde oder die erste Aktualisierung fehlgeschlagen ist. Lösen Sie eine manuelle Aktualisierung mit CALL BQ.REFRESH_MATERIALIZED_VIEW(...) aus.
COST Der Abfrageoptimierer hat geschätzt, dass das Abfragen der Basistabelle (oder das Lesen aus dem Abfragecache) günstiger ist als das Abfragen der materialisierten Ansicht. Abfragefilter und ‑partitionen überprüfen Wenn bei der Abfrage der Basistabelle nur eine kleine Partition gescannt wird, während sich die materialisierte Ansicht über mehrere Partitionen erstreckt, kann es effizienter sein, die Basistabelle direkt abzufragen.
BASE_TABLE_DATA_CHANGE Durch Datenänderungen in einer oder mehreren Basistabellen wurden die im Cache gespeicherten Daten außerhalb des konfigurierten Zeitraums für veraltete Daten ungültig. Führen Sie eine manuelle Aktualisierung durch oder konfigurieren Sie max_staleness, damit Abfragen veraltete Daten lesen können, ohne auf Basistabellen zurückzugreifen.
BASE_TABLE_TRUNCATED Eine Basistabelle wurde gekürzt, wodurch alle Daten der materialisierten Ansicht ungültig wurden. Aktualisieren Sie die materialisierte Ansicht, nachdem die Daten neu eingefügt wurden.
BASE_TABLE_EXPIRED_PARTITION Eine Partition in der Basistabelle ist abgelaufen. Achten Sie darauf, dass die Einstellungen für den Partitionsablauf zwischen der Basistabelle und der materialisierten Ansicht übereinstimmen, und aktualisieren Sie die Ansicht.
BASE_TABLE_PARTITION_EXPIRATION_CHANGE Die Dauer des Partitionsablaufs einer Basistabelle wurde geändert. Aktualisieren Sie die materialisierte Ansicht, um die Metadaten zum Ablauf von Partitionen neu auszurichten.
BASE_TABLE_INCOMPATIBLE_METADATA_CHANGE Es wurde eine Metadatenänderung an einer Basistabelle vorgenommen, z. B. eine Schemaänderung. Erstellen Sie die materialisierte Ansicht mit CREATE OR REPLACE MATERIALIZED VIEW neu.
BASE_TABLE_TOO_STALE Die im Cache gespeicherten Metadaten einer Basistabelle (z. B. einer externen BigLake-Tabelle) sind älter als der zulässige Grenzwert. Aktualisieren Sie den Metadaten-Cache der externen Tabelle.
BASE_TABLE_FINE_GRAINED_SECURITY_POLICY Der abfragende Nutzer hat keinen Zugriff auf eine Basistabelle, die durch eine Zugriffssteuerungsrichtlinie auf Zeilen- oder Spaltenebene geschützt ist. IAM-Berechtigungen und Datenrichtlinienzuweisungen überprüfen.
TIME_ZONE Die Ansicht wurde mit einer anderen Zeitzone als der Zeitzone der aktuellen Abfrage aktualisiert. Stimmen Sie die Zeitzoneneinstellungen zwischen Ihrer Umgebung und den Aktualisierungsjobs ab.

Materialisierte Ansicht wird nicht berücksichtigt (Abfragestruktur stimmt nicht überein)

Wenn eine materialisierte Ansicht nicht in materialized_view_statistics aufgeführt ist, hat der Abfrageoptimierer während des Syntax-Parsings festgestellt, dass das Abfragemuster nicht mit der Definition der materialisierten Ansicht übereinstimmt.

Häufige Ursachen sind:

  1. Abweichung bei Aggregation oder Filter: Die Abfrage verwendet Aggregatfunktionen, Gruppierungsspalten oder Filterprädikate, die nicht aus den vorab berechneten Aggregationen in der materialisierten Ansicht berechnet werden können.
    • Auflösung: Richten Sie Aggregatfunktionen und Gruppierungen zwischen Ihren Abfragen und der Definition der materialisierten Ansicht aus.
  2. Nicht inkrementelle materialisierte Ansichten Ansichten, die mit allow_non_incremental_definition = true erstellt wurden, unterstützen keine intelligente Feinabstimmung.
    • Lösung: Fragen Sie nicht inkrementelle materialisierte Ansichten direkt ab, indem Sie den Ansichtsnamen in der FROM-Klausel angeben.
  3. Direkte Abfrage einer veralteten Ansicht: Wenn Sie eine materialisierte Ansicht mit dem Wert max_staleness direkt abfragen, werden bis zu max_staleness alte, vorab berechnete Ergebnisse zurückgegeben, ohne dass Deltas aus Basistabellen verarbeitet werden.

Fehler: Inkompatibler HyperLogLog-Sketch

Fehlermeldung:

Invalid or incompatible sketch in HLL_COUNT.MERGE_PARTIAL

Ursache:

Wenn Sie ungefähre Aggregatfunktionen wie HLL_COUNT.INIT und HLL_COUNT.MERGE_PARTIAL verwenden, werden in BigQuery HyperLogLog-Skizzen verwendet. Wenn der in der Abfrage angegebene Parameter „precision“ nicht mit dem in der materialisierten Ansicht definierten Parameter „precision“ übereinstimmt, schlägt der Vorgang zum Zusammenführen von Statistiken fehl.

Lösung:

Achten Sie darauf, dass der Parameter „precision“ (z. B. HLL_COUNT.INIT(x, 12)) sowohl in der Definition der materialisierten Ansicht als auch in den Abfragen, die auf die Ansicht verweisen oder in die Ansicht umgeschrieben werden, identisch ist.

Probleme mit Ansichtsänderungen und Schemaänderungen beheben

In diesem Abschnitt werden Probleme beschrieben, die beim Ändern des Schemas oder der Optionen einer materialisierten Ansicht auftreten können.

Schema der materialisierten Ansicht bearbeiten

Problem:

Wenn Sie versuchen, Spalten in einer materialisierten Ansicht mit ALTER TABLE oder der Google Cloud -Konsole hinzuzufügen oder zu ändern, tritt ein Fehler auf oder die Option Schema bearbeiten ist nicht verfügbar.

Ursache:

In BigQuery kann das Spaltenschema einer materialisierten Ansicht nicht direkt geändert werden.

Lösung:

  • Sie können Optionen für materialisierte Ansichten (z. B. enable_refresh, refresh_interval_minutes und max_staleness) mit der Anweisung ALTER MATERIALIZED VIEW SET OPTIONS ändern:

    ALTER MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
SET OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 20
);

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Das Projekt, das die materialisierte Ansicht enthält.
    • DATASET: das Dataset, das die materialisierte Ansicht enthält.
    • MATERIALIZED_VIEW: der Name der materialisierten Ansicht.

  • Wenn Sie die SQL-Abfragedefinition ändern, Spalten hinzufügen oder Spaltendatentypen ändern möchten, erstellen Sie die Ansicht mit CREATE OR REPLACE MATERIALIZED VIEW neu:

    CREATE OR REPLACE MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
AS SELECT
...

Nächste Schritte