Einführung in BigLake-Tabellen

Dieses Dokument bietet einen Überblick über BigLake und setzt voraus, dass Sie sich mit Datenbanktabellen und Identity and Access Management (IAM) auskennen. Wenn Sie Daten abfragen möchten, die in den unterstützten Datenspeichern gespeichert sind, müssen Sie zuerst BigLake-Tabellen erstellen und dann mit der GoogleSQL-Syntax abfragen:

Sie können auch eine externe Tabelle auf BigLake aktualisieren. Weitere Informationen finden Sie unter Externe Tabelle auf BigLake aktualisieren.

Mit BigLake-Tabellen können Sie strukturierte Daten in externen Datenspeichern per Zugriffsdelegation abfragen. Durch die Zugriffsdelegation wird der Zugriff auf die BigLake-Tabelle vom Zugriff auf den zugrunde liegenden Datenspeicher entkoppelt. Für den Verbindungsaufbau zum Datenspeicher wird eine externe Verbindung verwendet, die mit einem Dienstkonto verknüpft ist. Da das Dienstkonto das Abrufen von Daten aus dem Datenspeicher übernimmt, müssen Sie Nutzern nur Zugriff auf die BigLake-Tabelle gewähren. So können Sie genaue Sicherheitsfunktionen auf Tabellenebene erzwingen, einschließlich Sicherheit auf Zeilen- und Spaltenebene. Für BigLake-Tabellen, die auf Cloud Storage basieren, können Sie auch die dynamische Datenmaskierung verwenden. Weitere Informationen zu Multi-Cloud-Analyselösungen unter Verwendung von BigLake-Tabellen mit Amazon S3- oder Blob Storage-Daten finden Sie unter BigQuery Omni.

Unterstützte Datenspeicher

Sie können BigLake-Tabellen mit folgenden Datenspeichern verwenden:

Unterstützung temporärer Tabellen

BigLake-Tabellen auf Basis von Cloud Storage können temporär oder dauerhaft sein. BigLake-Tabellen, die auf Amazon S3 oder Blob Storage basieren, müssen permanent sein.

Mehrere Quelldateien

Sie können eine BigLake-Tabelle auf Grundlage mehrerer externer Datenquellen erstellen, sofern diese Datenquellen das gleiche Schema haben.

Cloudübergreifende Joins

Mit cloudübergreifenden Joins können Sie Abfragen ausführen, die sich über Regionen in Google Cloud und BigQuery Omni erstrecken. Mit GoogleSQL-JOIN-Vorgängen können Sie Daten über viele verschiedene Speicherlösungen hinweg analysieren, z. B. AWS, Azure, öffentliche Datasets und andere Google Cloud-Dienste. Mit Cloud-Joins müssen Daten nicht mehr quellenübergreifend kopiert werden, bevor Abfragen ausgeführt werden.

Sie können BigLake-Tabellen an einer beliebigen Stelle in einer SELECT-Anweisung referenzieren, als ob es Standard-BigQuery-Tabellen wären. Sie können auch DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) und DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) nutzen, die Unterabfragen verwenden, um Daten abrufen. Sie können mehrere BigLake-Tabellen aus verschiedenen Clouds und BigQuery-Tabellen in derselben Abfrage verwenden. Alle BigQuery-Tabellen müssen aus derselben Region stammen.

Erforderliche Berechtigungen für cloudübergreifenden Join

Bitten Sie Ihren Administrator, Ihnen die Berechtigungen zu erteilen, die Sie für einen cloudübergreifenden Join benötigen, um Ihnen die IAM-Rolle BigQuery-Dateneditor (roles/bigquery.dataEditor) für das Projekt zu gewähren, in dem der Join ausgeführt wird. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die zum Ausführen eines cloudübergreifenden Joins erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind zum Ausführen eines cloudübergreifenden Joins erforderlich:

  • bigquery.datasets.create
  • bigquery.tables.create

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

Cloudübergreifende Joins erstellen Datasets mit dem Präfix __bigquery_xregion_sink_ und temporären Tabellen in diesen Datasets. Wenn Sie also nur Zugriff auf Ressourcen gewähren möchten, die von cloudübergreifenden Joins erstellt wurden, verwenden Sie die resource.name.startsWith-Bedingung für die Ressourcentypen Table und Dataset.

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

Kosten für cloudübergreifende Joins

Wenn Sie einen cloudübergreifenden Join-Vorgang ausführen, parst BigQuery die Abfrage in lokale und remote Teile. Der lokale Teil wird wie eine Standardabfrage in der BigQuery-Region behandelt. Der Remote-Teil wird in einen CREATE TABLE AS SELECT-Vorgang (CTAS) für die referenzierte BigLake-Tabelle in der BigQuery Omni-Region konvertiert, wodurch eine temporäre Tabelle in Ihrer BigQuery-Region erstellt wird. BigQuery verwendet diese temporäre Tabelle dann, um den cloudübergreifenden Join auszuführen. Die Tabelle wird nach acht Stunden automatisch gelöscht.

Es fallen Datenübertragungskosten für Daten in den referenzierten BigLake-Tabellen an. BigQuery hilft jedoch, diese Kosten zu reduzieren. Dazu werden nur die Spalten und Zeilen in der BigLake-Tabelle übertragen, auf die in der Abfrage verwiesen wird, und nicht die gesamte Tabelle. Wir empfehlen, einen möglichst kleinen Spaltenfilter anzugeben, um die Übertragungskosten weiter zu reduzieren. Der CTAS-Job wird in Ihrem Jobverlauf angezeigt und enthält Informationen wie die Anzahl der übertragenen Byte. Erfolgreiche Übertragungen verursachen auch dann Kosten, wenn der Hauptabfragejob fehlschlägt. Weitere Informationen finden Sie unter BigQuery Omni-Preise.

Betrachten Sie die folgende Abfrage als Beispiel:

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

Dieses Beispiel enthält zwei Übertragungen: eine aus einer Tabelle mit Mitarbeitern (mit einem Ebenenfilter) und eine aus einer Tabelle mit aktiven Mitarbeitern. Der Join wird nach der Übertragung in der BigQuery-Region durchgeführt. Wenn eine Übertragung fehlschlägt und die andere erfolgreich ist, werden die Datenübertragungsgebühren für die erfolgreiche Übertragung berechnet.

Cloudübergreifende Join-Einschränkungen

  • Cloudübergreifende Joins werden in der kostenlosen Stufe von BigQuery und in der BigQuery-Sandbox nicht unterstützt.
  • Joins mehrerer BigLake-Tabellen aus derselben Region werden nicht in die BigQuery Omni-Region verschoben.
  • Zusammenfassungen werden möglicherweise nicht in die BigQuery Omni-Regionen verschoben, wenn die Abfrage JOIN-Anweisungen enthält.
  • Jede temporäre Tabelle wird nur für eine einzelne cloudübergreifende Abfrage verwendet und auch dann nicht wiederverwendet, wenn dieselbe Abfrage mehrmals wiederholt wird.
  • Die maximale Übertragungsgröße beträgt 60 GB pro Übertragung. Wenn Sie einen Filter auf eine BigLake-Tabelle anwenden und das Ergebnis laden, muss dieses kleiner als 60 GB sein. Bei Bedarf können Sie ein höheres Kontingentlimit anfordern. Für gescannte Byte gibt es keine Begrenzung.
  • Cloudübergreifende Join-Abfragen verwenden ein internes Kontingent für die Rate der Abfragen. Wenn die Abfragerate das Kontingent überschreitet, erhalten Sie möglicherweise den Fehler All our servers are busy processing data transferred between regions. In den meisten Fällen sollte die Abfrage wiederholt werden. Wenden Sie sich an den Support, um das interne Kontingent zu erhöhen, um eine höhere Abfragerate zu unterstützen.
  • Cloudübergreifende Joins werden nur in BigQuery-Regionen mit den entsprechenden BigQuery Omni-Regionen und in den Multiregionen US und EU unterstützt. Cloudübergreifende Joins, die in den Multiregionen US oder EU ausgeführt werden, können nur auf Daten in BigQuery Omni-Regionen in den USA oder der EU zugreifen.
  • Wenn eine cloudübergreifende Join-Abfrage auf 10 oder mehr Datasets aus BigQuery Omni-Regionen verweist, schlägt der Vorgang möglicherweise mit dem Fehler Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region> fehl. Zur Vermeidung dieses Problems empfehlen wir die explizite Angabe eines Standorts, wenn Sie einen cloudübergreifenden Join ausführen, der auf mehr als zehn Datasets verweist. Wenn Sie explizit eine BigQuery-Region angeben und Ihre Abfrage nur BigLake-Tabellen enthält, wird Ihre Abfrage als cloudübergreifende Abfrage ausgeführt und verursacht Kosten für die Datenübertragung.
  • Sie können die Pseudospalte _FILE_NAME nicht mit cloudübergreifenden Joins abfragen.
  • Wenn Sie in einer WHERE-Anweisung auf die Spalten einer BigLake-Tabelle verweisen, können Sie die Literale NUMERIC, BIGNUMERIC, BYTES, TIME und INTERVAL nicht verwenden.
  • Cloudübergreifende Join-Jobs erfassen nicht die Anzahl der Byte, die von anderen Clouds verarbeitet und übertragen werden. Diese Informationen sind in den untergeordneten CTAS-Jobs verfügbar, die im Rahmen der cloudübergreifenden Abfrageausführung erstellt werden.
  • Autorisierte Ansichten und autorisierte Routinen, die auf BigQuery Omni-Tabellen oder -Ansichten verweisen, werden nur in BigQuery Omni-Regionen unterstützt.

Beispiele für cloudübergreifende Joins

Die folgende Abfrage verknüpft eine orders-Tabelle in einer BigQuery-Region mit einer lineitem-Tabelle in einer BigQuery Omni-Region:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Diese Abfrage wird in lokale und remote Teile unterteilt. Die folgende Abfrage wird zuerst an die BigQuery Omni-Region zur Ausführung gesendet. Das Ergebnis ist eine temporäre Tabelle in der BigQuery-Region. Sie können diesen CTAS-Job und seine Metadaten im Jobverlauf aufrufen.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Nachdem die temporäre Tabelle erstellt wurde, ist der JOIN-Vorgang abgeschlossen und die folgende Abfrage wird ausgeführt:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Als weiteres Beispiel betrachten Sie folgenden cloudübergreifenden Join:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
  SELECT c_mktsegment, c_name
  FROM aws_dataset.customer
  WHERE c_mktsegment = 'FURNITURE'
  LIMIT 10;

In dieser Abfrage wird die LIMIT-Anweisung nicht in die BigQuery Omni-Region übertragen. Alle Kunden im Marktsegment FURNITURE werden in die BigQuery-Region übertragen, bevor das Limit von 10 angewendet wird.

Connectors

Mit BigQuery-Connectors können Sie auf Daten in BigLake-Tabellen zugreifen, die auf Cloud Storage aus anderen Datenverarbeitungstools basieren. Sie können beispielsweise auf Daten in BigLake-Tabellen von Apache Spark, Apache Hive, TensorFlow, Trino oder Presto. Die BigQuery Storage API erzwingt Governance-Richtlinien auf Zeilen- und Spaltenebene für den gesamten Datenzugriff auf BigLake-Tabellen, auch den über Connectors.

Das folgende Diagramm zeigt beispielsweise, wie Nutzer mit der BigQuery Storage API auf autorisierte Daten zugreifen. Dazu verwenden sie Open-Source-Abfrage-Engines wie Apache Spark:

BigLake-Architektur.

Weitere Informationen zu den von BigQuery unterstützten Connectors finden Sie unter BigQuery-Connectors.

BigLake-Tabellen in Objektspeichern

Als Data-Lake-Administratoren können Sie mit BigLake Zugriffssteuerungen für Tabellen statt für Dateien festlegen, sodass Sie beim Festlegen von Nutzerzugriff auf Daten im Data Lake präzisere Optionen verwenden können.

Da BigLake-Tabellen die Zugriffssteuerung so vereinfachen, empfehlen wir die Verwendung von BigLake-Tabellen zum Erstellen und Verwalten von Verbindungen zu externen Objektspeichern.

Sie können externe Tabellen verwenden, wenn Governance keine Voraussetzung ist, oder für Ad-hoc-Datenerkennung und -Bearbeitung.

Beschränkungen

  • Alle Einschränkungen für externe Tabellen gelten für BigLake-Tabellen.
  • Für BigLake-Tabellen in Objektspeichern gelten die gleichen Einschränkungen wie für BigQuery-Tabellen. Weitere Informationen finden Sie unter Kontingente.

  • BigLake unterstützt keine herabgestuften Anmeldedaten aus der Persönliche Cluster Dataproc-Authentifizierung. Zur Umgehung dieses Problems müssen Sie zum Verwenden von Cluster mit persönlicher Clusterauthentifizierung Ihre Anmeldedaten mithilfe einer leeren Zugriffsgrenze für Anmeldedaten mit dem Flag --access-boundary=<(echo -n "{}") einfügen. Mit folgendem Befehl wird beispielsweise die Weitergabe von Anmeldedaten in einem Projekt namens myproject für den Cluster mycluster aktiviert: 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • BigLake-Tabellen sind schreibgeschützt. BigLake-Tabellen können nicht mit DML-Anweisungen oder anderen Methoden geändert werden.

  • BigLake-Tabellen unterstützen folgende Formate:

  • Sie können keine im Cache gespeicherten Metadaten mit Apache Iceberg BigLake-Tabellen verwenden. BigQuery verwendet bereits die von Iceberg in Manifestdateien erfassten Metadaten.

  • Die BigQuery Storage API ist in anderen Cloud-Umgebungen wie AWS und Azure nicht verfügbar.

  • Wenn Sie im Cache gespeicherte Metadaten verwenden, gelten die folgenden Einschränkungen:

    • Sie können nur im Cache gespeicherte Metadaten mit BigLake-Tabellen nutzen, die Avro-, ORC-, Parquet-, JSON- und CSV-Formate verwenden.
    • Wenn Sie Dateien in Amazon S3 erstellen, aktualisieren oder löschen, werden die aktualisierten Daten beim Abfragen der Dateien nicht zurückgegeben, bis der Metadaten-Cache aktualisiert wurde. Das kann zu unerwarteten Ergebnissen führen. Wenn Sie beispielsweise eine Datei löschen und eine neue Datei schreiben, enthalten Ihre Abfrageergebnisse möglicherweise weder die alten noch die neuen Dateien, je nachdem, wann die im Cache gespeicherten Metadaten zuletzt aktualisiert wurden.
    • Die Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) mit im Cache gespeicherten Metadaten wird für BigLake-Tabellen, die auf Amazon S3- oder Blob Storage-Daten verweisen, nicht unterstützt.

Sicherheitsmodell

Die folgenden Organisationsrollen sind in der Regel an der Verwaltung und Verwendung von BigLake-Tabellen beteiligt:

  • Data-Lake-Administratoren. Diese Administratoren verwalten normalerweise IAM-Richtlinien (Identity and Access Management) in Cloud Storage-Buckets und -Objekten.
  • Data-Warehouse-Administratoren. Diese Administratoren erstellen, löschen und aktualisieren in der Regel Tabellen.
  • Datenanalyst*innen. Die Analysten lesen normalerweise Daten und führen Abfragen aus.

Data-Lake-Administratoren sind dafür verantwortlich, Verbindungen zu erstellen und für Data-Warehouse-Administratoren freizugeben. Data-Warehouse-Administratoren erstellen wiederum Tabellen, legen geeignete Zugriffssteuerungen fest und geben die Tabellen für Datenanalysten frei.

Metadaten-Caching für bessere Leistung

Sie können im Cache gespeicherte Metadaten verwenden, um die Abfrageleistung bei einigen Arten von BigLake-Tabellen zu verbessern. Dies ist besonders hilfreich, wenn Sie mit einer großen Anzahl von Dateien arbeiten oder die Daten mit Hive partitioniert sind. 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 Metadaten-Caching nicht aktivieren, müssen Abfragen in der Tabelle die externe Datenquelle lesen, um Objektmetadaten abzurufen, wodurch die Abfragelatenz erhöht wird. 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 eine schnellere Partitionierung und Dateibereinigung erreichen.

Es gibt zwei Attribute, die diese Funktion steuern:

  • Maximale Veralterung, die steuert, wann Abfragen im Cache gespeicherte Metadaten verwenden.
  • Metadaten-Cache-Modus, der steuert, wie die Metadaten erfasst 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. Wenn Sie die Metadaten selektiv aktualisieren möchten, können Sie Unterverzeichnisse des Tabellendatenverzeichnisses angeben, um unnötige Metadatenverarbeitung zu 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.

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.

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;

Bei Cloud Storage BigLake-Tabellen, die auf Parquet-Dateien basieren, werden während der Metadaten-Cache-Aktualisierung Tabellenstatistiken erfasst und zur Verbesserung von Abfrageplänen verwendet.

Weitere Informationen finden Sie unter Caching von Metadaten.

Weitere Informationen zum Festlegen von Metadaten-Caching-Optionen finden Sie unter Amazon S3 BigLake-Tabellen erstellen oder BigLake-Tabellen in Cloud Storage erstellen.

Cache-fähige Tabellen mit materialisierten Ansichten

Sie können materialisierte Ansichten über BigLake-Metadaten-Cache-fähigen Tabellen verwenden, um die Leistung und Effizienz beim Abfragen strukturierter Daten zu verbessern, die in Cloud Storage oder 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.

Integrationen

BigLake-Tabellen sind über eine Reihe anderer BigQuery-Features und gcloud CLI-Dienste zugänglich, einschließlich der folgenden hervorgehobenen Dienste.

Analytics Hub

BigLake-Tabellen sind mit Analytics Hub kompatibel. Datasets, die BigLake-Tabellen enthalten, können als Analytics Hub-Einträge veröffentlicht werden. Analytics Hub-Abonnenten können diese Einträge abonnieren, die ein schreibgeschützten Dataset, das als verknüpftes Dataset bezeichnet wird, in ihrem Projekt bereitstellen. Abonnenten können alle Tabellen im verknüpften Dataset abfragen, einschließlich aller BigLake-Tabellen. Weitere Informationen finden Sie unter Einträge abonnieren.

BigQuery ML

Mit BigQuery ML können Sie Modelle in BigLake in Cloud Storage trainieren und ausführen.

Schutz sensibler Daten

Der Schutz sensibler Daten scannt Ihre BigLake-Tabellen, um sensible Daten zu identifizieren und zu klassifizieren. Wenn sensible Daten erkannt werden, können diese Daten durch Transformationen zur De-Identifikation im Rahmen des Schutzes sensibler Daten maskiert, gelöscht oder anderweitig verschleiert werden.

Kosten

Kosten fallen im Zusammenhang mit den folgenden Aspekten von BigLake-Tabellen an:

Wenn Sie Slot-Reservierungen haben, fallen für die Abfrage externer Tabellen keine Kosten an. Stattdessen werden für diese Abfragen Slots verwendet.

In der folgenden Tabelle sehen Sie, wie sich Ihr Preismodell darauf auswirkt, wie diese Kosten angewendet werden:


On-Demand-Preise.
Standard-, Enterprise- und Enterprise Plus-Versionen

Abfragen
Die von den Nutzerabfragen verarbeiteten Byte werden Ihnen in Rechnung gestellt.
Slots in Reservierungszuweisungen mit einem QUERY-Jobtyp werden während der Abfragezeit verbraucht.

Metadaten-Cache manuell aktualisieren.
Ihnen werden die verarbeiteten Byte in Rechnung gestellt um den Cache zu aktualisieren.
Slots in Reservierungszuweisungen mit einem QUERY-Jobtyp werden während der Cache-Aktualisierung genutzt.

Metadaten-Cache automatisch aktualisieren.
Ihnen werden die verarbeiteten Byte in Rechnung gestellt um den Cache zu aktualisieren.
Slots in Reservierungszuweisungen mit einem BACKGROUND-Jobtyp werden während der Cache-Aktualisierung verbraucht.

Wenn keine BACKGROUND-Reservierungen für die Aktualisierung des Metadaten-Cache verfügbar sind, verwendet BigQuery stattdessen automatisch Slots in QUERY-Reservierungen, wenn Sie die Enterprise- oder Enterprise Plus-Version verwenden.

Nächste Schritte