Caching von Metadaten

In diesem Dokument wird beschrieben, wie Sie mit dem Metadaten-Caching die Abfrageleistung für Objekttabellen und einige Arten von BigLake-Tabellen verbessern.

In Objekttabellen und einigen Arten von BigLake-Tabellen können Metadaten zu Dateien in externen Datenspeichern wie Cloud Storage im Cache gespeichert werden. Die folgenden Arten von BigLake-Tabellen unterstützen das Metadaten-Caching:

  • Amazon S3 BigLake-Tabellen
  • BigLake-Tabellen in Cloud Storage
Die Metadaten enthalten Dateinamen, Partitionierungsinformationen und physische Metadaten aus Dateien wie der Zeilenanzahl. Sie können auswählen, ob das Caching von Metadaten für eine Tabelle aktiviert werden soll. Abfragen mit einer großen Anzahl von Dateien und mit Hive-Partitionsfiltern profitieren am meisten vom Metadaten-Caching.

Wenn Sie das Caching von Metadaten nicht aktivieren, müssen Abfragen in der Tabelle die externe Datenquelle lesen, um Objektmetadaten abzurufen. Durch das Lesen dieser Daten erhöht sich die Abfragelatenz. Das Auflisten von Millionen von Dateien aus der externen Datenquelle kann einige Minuten dauern. Wenn Sie das Metadaten-Caching aktivieren, können Abfragen die Auflistung von Dateien aus der externen Datenquelle vermeiden und Dateien schneller partitionieren und bereinigen.

Sie können das Metadaten-Caching für eine BigLake- oder Objekttabelle beim Erstellen der Tabelle aktivieren. Weitere Informationen zum Erstellen von Objekttabellen finden Sie unter Cloud Storage-Objekttabellen erstellen. Weitere Informationen zum Erstellen von BigLake-Tabellen finden Sie in den folgenden Themen:

Einstellungen für das Caching von Metadaten

Es gibt zwei Attribute, die diese Funktion steuern:

  • Die maximale Veralterung gibt an, wann Abfragen im Cache gespeicherte Metadaten verwenden.
  • Der Metadaten-Cache-Modus gibt an, wie die Metadaten erhoben werden.

Wenn Sie das Caching von Metadaten aktiviert haben, geben Sie auch das maximale Intervall der Metadatenveralterung an, das für Vorgänge in Bezug auf die Tabelle akzeptabel ist. Wenn Sie beispielsweise ein Intervall von 1 Stunde angeben, verwenden die Vorgänge für die Tabelle im Cache gespeicherte Metadaten, wenn sie innerhalb der letzten Stunde aktualisiert wurden. Sind die im Cache gespeicherten Metadaten älter, werden für den Vorgang stattdessen Metadaten aus dem Datenspeicher (Amazon S3 oder Cloud Storage) abgerufen. Sie können ein Veralterungsintervall zwischen 30 Minuten und 7 Tagen festlegen.

Sie können den Cache entweder automatisch oder manuell aktualisieren:

  • Bei automatischen Aktualisierungen wird der Cache in einem systemdefinierten Intervall aktualisiert, in der Regel zwischen 30 und 60 Minuten. Das automatische Aktualisieren des Caches ist ein guter Ansatz, wenn die Objekte im Datenspeicher in zufälligen Intervallen hinzugefügt, gelöscht oder geändert werden. Wenn Sie den Zeitpunkt der Aktualisierung steuern müssen, z. B. um die Aktualisierung am Ende eines Extract-Transform-Ladejobs auszulösen, verwenden Sie die manuelle Aktualisierung.

  • Bei manuellen Aktualisierungen führen Sie das Systemverfahren BQ.REFRESH_EXTERNAL_METADATA_CACHE aus, um den Metadaten-Cache nach einem Zeitplan zu aktualisieren, der Ihren Anforderungen entspricht. Bei BigLake-Tabellen können Sie die Metadaten selektiv aktualisieren, indem Sie Unterverzeichnisse des Tabellendatenverzeichnisses angeben. So lässt sich unnötige Metadatenverarbeitung vermeiden. Das manuelle Aktualisieren des Caches ist ein guter Ansatz, wenn die Objekte im Datenspeicher in bekannten Intervallen hinzugefügt, gelöscht oder geändert werden, z. B. als Ausgabe einer Pipeline.

    Wenn Sie mehrere manuelle Aktualisierungen gleichzeitig ausführen, ist nur eine erfolgreich.

Der Metadaten-Cache läuft nach 7 Tagen ab, wenn er nicht aktualisiert wird.

Sowohl manuelle als auch automatische Cache-Aktualisierungen werden mit der Abfragepriorität INTERACTIVE ausgeführt.

Wenn Sie automatische Aktualisierungen verwenden möchten, empfehlen wir, eine Reservierung zu erstellen und dann eine Zuweisung mit dem Jobtyp BACKGROUND für das Projekt zu erstellen, in dem die Metadaten-Cache-Aktualisierungsjobs ausgeführt werden. Dadurch wird verhindert, dass die Aktualisierungsjobs mit Nutzerabfragen um Ressourcen konkurrieren und möglicherweise fehlschlagen, wenn nicht genügend Ressourcen verfügbar sind.

Sie sollten berücksichtigen, wie die Werte für Veralterung und Metadaten-Caching-Modus interagieren, bevor Sie sie festlegen. Betrachten Sie hierzu folgende Beispiele:

  • Wenn Sie den Metadaten-Cache für eine Tabelle manuell aktualisieren und das Veralterungsintervall auf 2 Tage festlegen, müssen Sie das Systemverfahren BQ.REFRESH_EXTERNAL_METADATA_CACHE alle 2 Tage oder weniger ausführen, wenn Sie Vorgänge wünschen. um die im Cache gespeicherten Metadaten zu verwenden.
  • Wenn Sie den Metadaten-Cache für eine Tabelle automatisch aktualisieren und das Veralterungsintervall auf 30 Minuten festlegen, ist es möglich, dass einige Vorgänge für die Tabelle aus dem Datenspeicher gelesen werden, wenn die Metadaten-Cache-Aktualisierung länger als die üblichen 30 bis 60 Minuten dauert.

Informationen zu Aktualisierungsjobs für Metadaten-Cache abrufen

Fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS ab, um Informationen zu Aktualisierungsjobs für Metadaten zu erhalten, wie im folgenden Beispiel gezeigt:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Vom Kunden verwaltete Verschlüsselungsschlüssel mit im Cache gespeicherten Metadaten verwenden

Im Cache gespeicherte Metadaten werden durch den vom Kunden verwalteten Verschlüsselungsschlüssel (Customer-Managed Encryption Key, CMEK) geschützt, der für die Tabelle verwendet wird, mit der die im Cache gespeicherten Metadaten verknüpft sind. Dies kann ein CMEK sein, der direkt auf die Tabelle angewendet wird, oder ein CMEK, den die Tabelle vom Dataset oder Projekt übernimmt.

Wenn ein Standard-CMEK für das Projekt oder Dataset festgelegt wurde oder wenn der vorhandene CMEK für das Projekt oder Dataset geändert wird, wirkt sich dies nicht auf vorhandene Tabellen oder ihre im Cache gespeicherten Metadaten aus. Sie müssen den Schlüssel für die Tabelle ändern, um den neuen Schlüssel sowohl auf die Tabelle als auch auf ihre im Cache gespeicherten Metadaten anzuwenden.

In BigQuery erstellte CMEKs gelten nicht für die Cloud Storage-Dateien, die von BigLake- und Objekttabellen verwendet werden. Für eine End-to-End-CMEK-Verschlüsselung müssen Sie für diese Dateien CMEKs in Cloud Storage konfigurieren.

Informationen zur Verwendung des Metadaten-Cache durch Abfragejobs abrufen

Um Informationen zur Verwendung des Metadaten-Cache für einen Abfragejob zu erhalten, rufen Sie die Methode jobs.get für diesen Job auf und sehen Sie sich das Feld MetadataCacheStatistics im Abschnitt JobStatistics2 der Job-Ressource an. Dieses Feld enthält Informationen dazu, welche Metadaten-Cache-fähigen Tabellen von der Abfrage verwendet wurden, ob der Metadaten-Cache von der Abfrage verwendet wurde und wenn nicht warum nicht.

Tabellenstatistiken

Bei BigLake-Tabellen, die auf Parquet-Dateien basieren, werden Tabellenstatistiken erfasst, wenn der Metadaten-Cache aktualisiert wird. Die Erfassung von Tabellenstatistiken erfolgt sowohl bei automatischen als auch manuellen Aktualisierungen und die Statistiken werden für denselben Zeitraum wie der Metadaten-Cache gespeichert.

Die erfassten Tabellenstatistiken umfassen Dateiinformationen wie die Anzahl der Zeilen, physische und unkomprimierte Dateigrößen und die Kardinalität von Spalten. Wenn Sie eine Abfrage für eine Parquet-basierte BigLake-Tabelle ausführen, werden diese Statistiken an das Abfrageoptimierungstool übergeben, um eine bessere Abfrageplanung zu ermöglichen und die Abfrageleistung bei einigen Abfragetypen möglicherweise zu verbessern. Eine gängige Abfrageoptimierung ist beispielsweise die dynamische Weitergabe von Einschränkungen, bei der die Abfrageoptimierung dynamisch Prädikate für die größeren Faktentabellen in einem Join aus den kleineren Dimensionstabellen ableitet. Diese Optimierung kann zwar Abfragen mithilfe normalisierter Tabellenschemas beschleunigen, erfordert aber genaue Tabellenstatistiken. Die durch Metadaten-Caching erfassten Tabellenstatistiken ermöglichen eine bessere Optimierung von Abfrageplänen in BigQuery und Apache Spark.

Beschränkungen

Für den Metadaten-Cache gelten die folgenden Beschränkungen:

  • Wenn Sie mehrere manuelle Aktualisierungen gleichzeitig ausführen, ist nur eine erfolgreich.
  • Der Metadaten-Cache läuft nach 7 Tagen ab, wenn er nicht aktualisiert wird.
  • Wenn Sie den Quell-URI für eine Tabelle aktualisieren, wird der Metadaten-Cache nicht automatisch aktualisiert. Nachfolgende Abfragen geben Daten aus dem veralteten Cache zurück. Um dies zu vermeiden, aktualisieren Sie den Metadaten-Cache manuell. Wenn der Metadaten-Cache der Tabelle automatisch aktualisiert wird, müssen Sie den Aktualisierungsmodus der Tabelle in "Manuell" ändern, die manuelle Aktualisierung ausführen und dann den Aktualisierungsmodus der Tabelle wieder auf "Automatisch" setzen.

  • Wenn Sie den Metadaten-Cache manuell aktualisieren und sich das Ziel-Dataset und der Cloud Storage-Bucket an einem regionalen Standort befinden, müssen Sie diesen Standort explizit angeben, wenn Sie den BQ.REFRESH_EXTERNAL_METADATA_CACHE-Prozeduraufruf ausführen. Sie haben dazu folgende Möglichkeiten:

    Console

    1. Rufen Sie die Seite BigQuery auf.

      BigQuery aufrufen

    2. Wählen Sie im Editor einen Tab aus.

    3. Klicken Sie auf Mehr und dann auf Abfrageeinstellungen.

    4. Heben Sie im Abschnitt Erweiterte Optionen die Auswahl des Kästchens Automatische Standortauswahl auf und geben Sie die Zielregion an.

    5. Klicken Sie auf Speichern.

    6. Führen Sie die Abfrage mit dem Prozeduraufruf BQ.REFRESH_EXTERNAL_METADATA_CACHE auf diesem Editor-Tab aus.

    bq

    Wenn Sie die Abfrage ausführen, die den Prozeduraufruf BQ.REFRESH_EXTERNAL_METADATA_CACHE enthält, mithilfe von bq query ausführen, müssen Sie das Flag --location angeben.

Nächste Schritte