Verwaltete Apache Iceberg-Tabellen

Verwaltete Apache Iceberg-Tabellen (früher BigLake-Tabellen für Apache Iceberg in BigQuery) bilden die Grundlage für die Erstellung von Lakehouses im offenen Format auf Google Cloud. Verwaltete Iceberg-Tabellen bieten dieselbe vollständig verwaltete Umgebung wie Standard-BigQuery-Tabellen, speichern Daten jedoch in kundeneigenen Storage-Buckets. Verwaltete Iceberg-Tabellen unterstützen das offene Iceberg-Tabellenformat für eine bessere Interoperabilität mit Open-Source- und Drittanbieter-Compute-Engines auf einer einzigen Datenkopie.

Verwaltete Iceberg-Tabellen unterstützen die folgenden Funktionen:

Architektur

Mit verwalteten Iceberg-Tabellen können Sie die Ressourcenverwaltung von BigQuery auch für Tabellen in Ihren eigenen Cloud-Buckets nutzen. Sie können BigQuery und Open-Source-Compute-Engines für diese Tabellen verwenden, ohne die Daten aus den von Ihnen kontrollierten Buckets zu verschieben. Sie müssen einen Cloud Storage-Bucket konfigurieren, bevor Sie verwaltete Iceberg-Tabellen verwenden können.

Die Verwendung von verwalteten Iceberg-Tabellen hat die folgenden Auswirkungen auf Ihren Bucket:

  • BigQuery erstellt neue Datendateien im Bucket als Reaktion auf Schreibanfragen und Hintergrundspeicheroptimierungen, z. B. DML-Anweisungen und Streaming.
  • Die Datendateien im Bucket werden automatisch komprimiert und geclustert. Nach Ablauf des Zeitreisefensters werden Datendateien durch die automatische Speicherbereinigung gelöscht. Wenn die Tabelle jedoch gelöscht wird, werden die zugehörigen Datendateien nicht automatisch gelöscht. Weitere Informationen finden Sie unter Speicheroptimierung.

Das Erstellen einer verwalteten Iceberg-Tabelle ähnelt dem Erstellen von BigQuery-Tabellen. Da Daten in offenen Formaten in Cloud Storage gespeichert werden, müssen Sie Folgendes tun:

  • Geben Sie die Cloud-Ressourcenverbindung mit WITH CONNECTION an, um die Anmeldedaten für die Verbindung von BigQuery mit Cloud Storage zu konfigurieren.
  • Geben Sie das Dateiformat des Datenspeichers mit der Anweisung file_format = PARQUET als PARQUET an.
  • Geben Sie das Format der Open-Source-Metadatentabelle mit der Anweisung table_format = ICEBERG als ICEBERG an.

Best Practices

Wenn Sie Dateien direkt außerhalb von BigQuery im Bucket ändern oder hinzufügen, kann dies zu Datenverlusten oder nicht behebbaren Fehlern führen. In der folgenden Tabelle werden mögliche Szenarien beschrieben:

Vorgang Auswirkungen vermeiden
Fügen Sie dem Bucket außerhalb von BigQuery neue Dateien hinzu. Datenverlust: Neue Dateien oder Objekte, die außerhalb von BigQuery hinzugefügt werden, werden von BigQuery nicht erfasst. Nicht verfolgte Dateien werden durch Hintergrundprozesse zur automatischen Speicherbereinigung gelöscht. Daten ausschließlich über BigQuery hinzufügen So kann BigQuery die Dateien verfolgen und verhindern, dass sie durch die automatische Speicherbereinigung gelöscht werden.
Um versehentliche Hinzufügungen und Datenverluste zu vermeiden, empfehlen wir außerdem, die Schreibberechtigungen externer Tools für Buckets mit von Iceberg verwalteten Tabellen einzuschränken.
Erstellen Sie eine neue verwaltete Iceberg-Tabelle in einem nicht leeren Präfix. Datenverlust: Vorhandene Daten werden von BigQuery nicht erfasst. Diese Dateien gelten daher als nicht erfasst und werden von Hintergrundprozessen zur Speicherbereinigung gelöscht. Erstellen Sie neue verwaltete Iceberg-Tabellen nur in leeren Präfixen.
Datendateien von verwalteten Iceberg-Tabellen ändern oder ersetzen Datenverlust: Bei einer externen Änderung oder Ersetzung schlägt die Konsistenzprüfung der Tabelle fehl und sie wird unlesbar. Abfragen für die Tabelle schlagen fehl.
Es gibt keine Selfservice-Möglichkeit, das Problem zu beheben. Wenden Sie sich an den Support, um Unterstützung bei der Datenwiederherstellung zu erhalten.		 Daten ausschließlich über BigQuery ändern. So kann BigQuery die Dateien verfolgen und verhindern, dass sie durch die automatische Speicherbereinigung gelöscht werden.
Um versehentliche Hinzufügungen und Datenverluste zu vermeiden, empfehlen wir außerdem, die Schreibberechtigungen externer Tools für Buckets mit von Iceberg verwalteten Tabellen einzuschränken.
Erstellen Sie zwei verwaltete Iceberg-Tabellen mit denselben oder sich überschneidenden URIs. Datenverlust: BigQuery verbindet keine identischen URI-Instanzen von verwalteten Iceberg-Tabellen. Hintergrundprozesse für die automatische Speicherbereinigung für jede Tabelle betrachten die Dateien der jeweils anderen Tabelle als nicht verfolgt und löschen sie, was zu Datenverlust führt. Verwenden Sie für jede verwaltete Iceberg-Tabelle eindeutige URIs.

Best Practices für die Konfiguration von Cloud Storage-Bucket

Die Konfiguration Ihres Cloud Storage-Bucket und seine Verbindung mit BigQuery haben direkte Auswirkungen auf die Leistung, Kosten, Datenintegrität, Sicherheit und Governance Ihrer von Iceberg verwalteten Tabellen. Im Folgenden finden Sie Best Practices für diese Konfiguration:

  • Wählen Sie einen Namen aus, der deutlich macht, dass der Bucket nur für von Iceberg verwaltete Tabellen gedacht ist.

  • Wählen Sie Cloud Storage-Buckets mit einer einzelnen Region aus, die sich in derselben Region wie Ihr BigQuery-Dataset befinden. Diese Koordination verbessert die Leistung und senkt die Kosten, da keine Gebühren für die Datenübertragung anfallen.

  • Standardmäßig werden Daten in Cloud Storage in der Speicherklasse „Standard Storage“ gespeichert, die eine ausreichende Leistung bietet. Wenn Sie die Datenspeicherkosten optimieren möchten, können Sie Autoclass aktivieren, um die Umstellung der Speicherklassen automatisch zu verwalten. Autoclass beginnt mit der Speicherklasse „Standard Storage“ und verschiebt Objekte, auf die nicht zugegriffen wird, in immer kältere Klassen, um die Speicherkosten zu senken. Wenn das Objekt wieder gelesen wird, wird es zurück in die Standardklasse verschoben.

  • Aktivieren Sie den einheitlichen Zugriff auf Bucket-Ebene und die Verhinderung des öffentlichen Zugriffs.

  • Prüfen Sie, ob die erforderlichen Rollen den richtigen Nutzern und Dienstkonten zugewiesen sind.

  • Um ein versehentliches Löschen oder Beschädigen von Daten in Ihrem Cloud Storage-Bucket zu verhindern, sollten Sie die Schreib- und Löschberechtigungen für die meisten Nutzer in Ihrer Organisation einschränken. Dazu können Sie eine Bucket-Berechtigungsrichtlinie mit Bedingungen festlegen, die PUT- und DELETE-Anfragen für alle Nutzer ablehnen, mit Ausnahme der von Ihnen angegebenen Nutzer.

  • Wenden Sie von Google verwaltete oder vom Kunden verwaltete Verschlüsselungsschlüssel an, um sensible Daten zusätzlich zu schützen.

  • Aktivieren Sie das Audit-Logging für operative Transparenz, Fehlerbehebung und Monitoring des Datenzugriffs.

  • Behalten Sie die standardmäßige Richtlinie für vorläufiges Löschen (7 Tage Aufbewahrung) bei, um sich vor versehentlichem Löschen zu schützen. Wenn Sie jedoch feststellen, dass Daten gelöscht wurden, wenden Sie sich an den Support, anstatt Objekte manuell wiederherzustellen, da Objekte, die außerhalb von BigQuery hinzugefügt oder geändert werden, nicht von BigQuery-Metadaten erfasst werden.

  • Die adaptive Dateigröße, das automatische Clustering und die automatische Speicherbereinigung sind automatisch aktiviert und helfen bei der Optimierung der Dateileistung und der Kosten.

  • Vermeiden Sie die folgenden Cloud Storage-Features, da sie für verwaltete Iceberg-Tabellen nicht unterstützt werden:

Sie können diese Best Practices implementieren, indem Sie Ihren Bucket mit dem folgenden Befehl erstellen:

gcloud storage buckets create gs://BUCKET_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --enable-autoclass \
    --public-access-prevention \
    --uniform-bucket-level-access

Ersetzen Sie Folgendes:

  • BUCKET_NAME: der Name des neuen Buckets
  • PROJECT_ID: die Projekt-ID
  • LOCATION: der Speicherort für den neuen Bucket

Workflows für verwaltete Iceberg-Tabellen

In den folgenden Abschnitten wird beschrieben, wie Sie verwaltete Iceberg-Tabellen erstellen, laden, verwalten und abfragen.

Hinweis

Bevor Sie verwaltete Iceberg-Tabellen erstellen und verwenden, müssen Sie eine Cloud-Ressourcenverbindung zu einem Storage-Bucket einrichten. Ihre Verbindung benötigt Schreibberechtigungen für den Storage-Bucket, wie im folgenden Abschnitt Erforderliche Rollen angegeben. Weitere Informationen zu den erforderlichen Rollen und Berechtigungen für Verbindungen finden Sie unter Verbindungen verwalten.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie benötigen, damit BigQuery Tabellen in Ihrem Projekt verwalten kann:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die erforderlich sind, damit BigQuery Tabellen in Ihrem Projekt verwalten kann. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, damit BigQuery Tabellen in Ihrem Projekt verwalten kann:

  • Alle:
    • bigquery.connections.delegate für Ihr Projekt
    • bigquery.jobs.create für Ihr Projekt
    • bigquery.readsessions.create für Ihr Projekt
    • bigquery.tables.create für Ihr Projekt
    • bigquery.tables.get für Ihr Projekt
    • bigquery.tables.getData für Ihr Projekt
    • storage.buckets.get für Ihren Bucket
    • storage.objects.create für Ihren Bucket
    • storage.objects.delete für Ihren Bucket
    • storage.objects.get für Ihren Bucket
    • storage.objects.list für Ihren Bucket

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

Von Iceberg verwaltete Tabellen erstellen

Wählen Sie eine der folgenden Methoden aus, um eine verwaltete Iceberg-Tabelle zu erstellen:

SQL

CREATE TABLE [PROJECT_ID.]DATASET_ID.TABLE_NAME (
COLUMN DATA_TYPE[, ...]
)
CLUSTER BY CLUSTER_COLUMN_LIST
WITH CONNECTION {CONNECTION_NAME | DEFAULT}
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'STORAGE_URI');

Ersetzen Sie Folgendes:

  • PROJECT_ID: das Projekt, das das Dataset enthält. Wenn nicht definiert, wird das Standardprojekt verwendet.
  • DATASET_ID: ein vorhandenes Dataset.
  • TABLE_NAME: Der Name der Tabelle, die Sie erstellen.
  • DATA_TYPE: der Datentyp der Informationen, die in der Spalte enthalten sind.
  • CLUSTER_COLUMN_LIST (optional): Eine durch Kommas getrennte Liste mit bis zu vier Spalten. Es muss sich um Spalten der obersten Ebene handeln, die nicht wiederholt werden.
  • CONNECTION_NAME: der Name der Verbindung. Beispiel: myproject.us.myconnection Wenn Sie eine Standardverbindung verwenden möchten, geben Sie anstelle des Verbindungsnamens DEFAULT an.
  • STORAGE_URI: ein vollständig qualifizierter Cloud Storage-URI. Beispiel: gs://mybucket/table.

bq 

bq --project_id=PROJECT_ID mk \
    --table \
    --file_format=PARQUET \
    --table_format=ICEBERG \
    --connection_id=CONNECTION_NAME \
    --storage_uri=STORAGE_URI \
    --schema=COLUMN_NAME:DATA_TYPE[, ...] \
    --clustering_fields=CLUSTER_COLUMN_LIST \
    DATASET_ID.MANAGED_TABLE_NAME

Ersetzen Sie Folgendes:

  • PROJECT_ID: das Projekt, das das Dataset enthält. Wenn nicht definiert, wird das Standardprojekt verwendet.
  • CONNECTION_NAME: der Name der Verbindung. Beispiel: myproject.us.myconnection
  • STORAGE_URI: ein vollständig qualifizierter Cloud Storage-URI. Beispiel: gs://mybucket/table.
  • COLUMN_NAME: Der Name der Spalte.
  • DATA_TYPE: der Datentyp der in der Spalte enthaltenen Informationen.
  • CLUSTER_COLUMN_LIST (optional): Eine durch Kommas getrennte Liste mit bis zu vier Spalten. Es muss sich um Spalten der obersten Ebene handeln, die nicht wiederholt werden.
  • DATASET_ID: die ID eines vorhandenen Datasets.
  • MANAGED_TABLE_NAME: Der Name der Tabelle, die Sie erstellen.

API

Rufen Sie die Methode tables.insert mit einer definierten Tabellenressource auf, ähnlich wie im folgenden Beispiel:

{
"tableReference": {
  "tableId": "TABLE_NAME"
},
"biglakeConfiguration": {
  "connectionId": "CONNECTION_NAME",
  "fileFormat": "PARQUET",
  "tableFormat": "ICEBERG",
  "storageUri": "STORAGE_URI"
},
"schema": {
  "fields": [
    {
      "name": "COLUMN_NAME",
      "type": "DATA_TYPE"
    }
    [, ...]
  ]
}
}

Ersetzen Sie Folgendes:

  • TABLE_NAME: Der Name der Tabelle, die Sie erstellen.
  • CONNECTION_NAME: der Name der Verbindung. Beispiel: myproject.us.myconnection
  • STORAGE_URI: ein vollständig qualifizierter Cloud Storage-URI. Platzhalter werden ebenfalls unterstützt. Beispiel: gs://mybucket/table
  • COLUMN_NAME: Der Name der Spalte.
  • DATA_TYPE: der Datentyp der in der Spalte enthaltenen Informationen.

Daten in verwaltete Iceberg-Tabellen importieren

In den folgenden Abschnitten wird beschrieben, wie Sie Daten aus verschiedenen Tabellenformaten in von Iceberg verwaltete Tabellen importieren.

Standard-Ladevorgang für Daten aus Flatfiles

Verwaltete Iceberg-Tabellen verwenden BigQuery-Ladejobs, um externe Dateien in verwaltete Iceberg-Tabellen zu laden. Wenn Sie bereits eine verwaltete Iceberg-Tabelle haben, folgen Sie dem bq loadLeitfaden für die Befehlszeile oder dem LOAD SQL-Leitfaden, um externe Daten zu laden. Nach dem Laden der Daten werden neue Parquet-Dateien in den Ordner STORAGE_URI/data geschrieben.

Wenn die vorherigen Anleitungen ohne eine vorhandene verwaltete Iceberg-Tabelle verwendet werden, wird stattdessen eine BigQuery-Tabelle erstellt.

Im Folgenden finden Sie toolspezifische Beispiele für Batchladevorgänge in verwaltete Iceberg-Tabellen:

SQL

LOAD DATA INTO MANAGED_TABLE_NAME
FROM FILES (
uris=['STORAGE_URI'],
format='FILE_FORMAT');

Ersetzen Sie Folgendes:

  • MANAGED_TABLE_NAME: der Name einer vorhandenen verwalteten Iceberg-Tabelle.
  • STORAGE_URI: ein vollständig qualifizierter Cloud Storage-URI oder eine durch Kommas getrennte Liste von URIs. Platzhalter werden ebenfalls unterstützt. Beispiel: gs://mybucket/table
  • FILE_FORMAT: das Quelltabellenformat. Informationen zu unterstützten Formaten finden Sie in der Zeile format von load_option_list.

bq 

bq load \
  --source_format=FILE_FORMAT \
  MANAGED_TABLE \
  STORAGE_URI

Ersetzen Sie Folgendes:

  • FILE_FORMAT: das Format der Quelltabelle. Informationen zu unterstützten Formaten finden Sie in der Zeile format von load_option_list.
  • MANAGED_TABLE_NAME: der Name einer vorhandenen verwalteten Iceberg-Tabelle.
  • STORAGE_URI: ein vollständig qualifizierter Cloud Storage-URI oder eine durch Kommas getrennte Liste von URIs. Platzhalter werden ebenfalls unterstützt. Beispiel: gs://mybucket/table

Standard-Ladevorgang aus Apache Hive-partitionierten Dateien

Sie können Hive-partitionierte Dateien mit BigQuery-Standardladejobs in verwaltete Iceberg-Tabellen laden. Weitere Informationen finden Sie unter Extern partitionierte Daten laden.

Streamingdaten aus Pub/Sub laden

Sie können Streamingdaten mithilfe eines Pub/Sub-BigQuery-Abos in verwaltete Iceberg-Tabellen laden.

Streamingdaten mit kontinuierlichen Abfragen laden

Sie können Streamingdaten aus BigQuery kontinuierlich verarbeiten und in verwaltete Iceberg-Tabellen schreiben. Verwenden Sie dazu eine kontinuierliche BigQuery-Abfrage mit der DML-Anweisung INSERT. So können Sie in Ihrem Lakehouse mit offenem Format Echtzeit-Reverse-ETL, Datenanreicherung und Filterung durchführen.

Prüfen Sie vor dem Ausführen der kontinuierlichen Abfrage, ob die verwaltete Iceberg-Zieltabelle vorhanden ist und ob der Nutzer oder das Dienstkonto die erforderlichen Berechtigungen für die Tabelle, die zugehörige Google Cloud -Ressourcenverbindung und den zugrunde liegenden Cloud Storage-Bucket hat.

Eine Einrichtungsanleitung und SQL-Beispiele finden Sie unter Daten in eine von BigQuery oder Apache Iceberg verwaltete Tabelle schreiben.

Daten aus von Iceberg verwalteten Tabellen exportieren

In den folgenden Abschnitten wird beschrieben, wie Sie Daten aus verwalteten Iceberg-Tabellen in verschiedene Tabellenformate exportieren.

Daten in flache Formate exportieren

Wenn Sie eine verwaltete Iceberg-Tabelle in ein flaches Format exportieren möchten, verwenden Sie die Anweisung EXPORT DATA und wählen Sie ein Zielformat aus. Weitere Informationen finden Sie unter Daten exportieren.

Metadaten-Snapshots für verwaltete Iceberg-Tabellen erstellen

So erstellen Sie einen Metadaten-Snapshot einer verwalteten Iceberg-Tabelle:

  1. Exportieren Sie die Metadaten mit der SQL-Anweisung EXPORT TABLE METADATA in das Iceberg V2-Format.

  2. Optional: Aktualisierung des Iceberg-Metadaten-Snapshots planen. Wenn Sie einen Iceberg-Metadaten-Snapshot in einem bestimmten Zeitintervall aktualisieren möchten, verwenden Sie eine geplante Abfrage.

  3. Optional: Aktivieren Sie die automatische Aktualisierung von Metadaten für Ihr Projekt, damit der Metadaten-Snapshot Ihrer Iceberg-Tabelle bei jeder Tabellenänderung automatisch aktualisiert wird. Wenn Sie die automatische Aktualisierung von Metadaten aktivieren möchten, wenden Sie sich an bigquery-tables-for-apache-iceberg-help@google.com. Bei jedem Aktualisierungsvorgang fallen EXPORT METADATA-Kosten an.

Im folgenden Beispiel wird eine geplante Abfrage mit dem Namen My Scheduled Snapshot Refresh Query mithilfe der DDL-Anweisung EXPORT TABLE METADATA FROM mydataset.test erstellt. Die DDL-Anweisung wird alle 24 Stunden ausgeführt.

bq query \
    --use_legacy_sql=false \
    --display_name='My Scheduled Snapshot Refresh Query' \
    --schedule='every 24 hours' \
    'EXPORT TABLE METADATA FROM mydataset.test'

Snapshot der Metadaten einer verwalteten Iceberg-Tabelle ansehen

Nachdem Sie den Metadaten-Snapshot der verwalteten Iceberg-Tabelle aktualisiert haben, finden Sie den Snapshot im Cloud Storage-URI, in dem die verwaltete Iceberg-Tabelle ursprünglich erstellt wurde. Der Ordner /data enthält die Parquet-Dateidaten-Shards und der Ordner /metadata den Metadaten-Snapshot der von Iceberg verwalteten Tabelle.

SELECT
  table_name,
  REGEXP_EXTRACT(ddl, r"storage_uri\s*=\s*\"([^\"]+)\"") AS storage_uri
FROM
  `mydataset`.INFORMATION_SCHEMA.TABLES;

mydataset und table_name sind Platzhalter für Ihr tatsächliches Dataset und Ihre tatsächliche Tabelle.

Verwaltete Iceberg-Tabellen mit Spark lesen

Im folgenden Beispiel wird Ihre Umgebung für die Verwendung von Spark SQL mit Spark eingerichtet. Anschließend wird eine Abfrage ausgeführt, um Daten aus einer angegebenen verwalteten Iceberg-Tabelle abzurufen.

spark-sql \
  --packages org.apache.iceberg:iceberg-spark-runtime-ICEBERG_VERSION_NUMBER \
  --conf spark.sql.catalog.CATALOG_NAME=org.apache.iceberg.spark.SparkCatalog \
  --conf spark.sql.catalog.CATALOG_NAME.type=hadoop \
  --conf spark.sql.catalog.CATALOG_NAME.warehouse='BUCKET_PATH' \

# Query the table
SELECT * FROM CATALOG_NAME.FOLDER_NAME;

Ersetzen Sie Folgendes:

  • ICEBERG_VERSION_NUMBER: die aktuelle Laufzeitversion. Laden Sie die aktuelle Version von Iceberg-Releases herunter.
  • CATALOG_NAME: Der Katalog, der auf Ihre verwaltete Iceberg-Tabelle verweist.
  • BUCKET_PATH: der Pfad zum Bucket, der die Tabellendateien enthält. Beispiel: gs://mybucket/.
  • FOLDER_NAME: der Ordner, der die Tabellendateien enthält. Beispiel: myfolder

Verwaltete Iceberg-Tabellen ändern

Wenn Sie eine verwaltete Iceberg-Tabelle ändern möchten, folgen Sie der Anleitung unter Tabellenschemas ändern.

Transaktionen mit mehreren Anweisungen verwenden

Sie können Transaktionen mit mehreren Anweisungen mit verwalteten Iceberg-Tabellen auf dieselbe Weise wie mit Standard-BigQuery-Tabellen verwenden. Transaktionen mit mehreren Anweisungen werden häufig verwendet, um Mutationen in mehreren Tabellen gleichzeitig oder in einer einzelnen Tabelle in mehreren Phasen auszuführen. Transaktionen mit mehreren Anweisungen garantieren ACID-Eigenschaften und unterstützen die Snapshot-Isolation.

Es gelten die standardmäßigen Einschränkungen für Transaktionen mit mehreren Anweisungen.

Partitionierung verwenden

Sie können die Tabellenpartitionierung mit verwalteten Iceberg-Tabellen ähnlich wie mit BigQuery-Standardtabellen verwenden. Sie partitionieren eine Tabelle, indem Sie eine Partitionsspalte angeben, mit der die Tabelle segmentiert wird. Die folgenden Spaltentypen werden für verwaltete Iceberg-Tabellen unterstützt:

  • DATE
  • DATETIME
  • TIMESTAMP

Die Partitionierung einer Tabelle nach einer DATE-, DATETIME- oder TIMESTAMP-Spalte wird als Spaltenpartitionierung nach Zeiteinheit bezeichnet. Sie können auswählen, ob die Partitionen stündlich, täglich, monatlich oder jährlich sind.

Verwaltete Iceberg-Tabellen unterstützen auch Clustering und das Kombinieren von geclusterten und partitionierten Tabellen.

Einschränkungen bei der Partitionierung

Partitionierte verwaltete Iceberg-Tabelle erstellen

Wenn Sie eine partitionierte verwaltete Iceberg-Tabelle erstellen möchten, folgen Sie der Anleitung zum Erstellen einer standardmäßigen verwalteten Iceberg-Tabelle und fügen Sie je nach Umgebung eine der folgenden Optionen hinzu:

Sie können den Partitionsablauf auf dieselbe Weise festlegen und aktualisieren wie bei BigQuery-Standardtabellen. Abgelaufene Partitionen werden nach dem Zeitreisefenster durch die automatische Speicherbereinigung gelöscht. Wenn Sie Daten zu einer abgelaufenen Partition hinzufügen, laufen die Daten sofort ab.

Partitionierte verwaltete Iceberg-Tabellen ändern und abfragen

BigQuery-DML-Anweisungen (Datenbearbeitungssprache) und Abfragen für partitionierte verwaltete Iceberg-Tabellen sind mit denen für standardmäßige verwaltete Iceberg-Tabellen identisch. BigQuery beschränkt den Job automatisch auf die richtigen Partitionen, ähnlich wie bei der versteckten Partitionierung von Iceberg. Außerdem werden alle neuen Daten, die Sie der Tabelle hinzufügen, automatisch partitioniert.

Sie können partitionierte verwaltete Iceberg-Tabellen auch mit anderen Engines auf dieselbe Weise abfragen wie standardmäßige verwaltete Iceberg-Tabellen. Wir empfehlen, Metadaten-Snapshots zu aktivieren, um die beste Leistung zu erzielen.

Aus Sicherheitsgründen werden Partitionierungsinformationen für verwaltete Iceberg-Tabellen vom Datenpfad entkoppelt und vollständig von der Metadatenebene verwaltet.

Preise

Die Preise für verwaltete Iceberg-Tabellen setzen sich aus Speicher, Speicheroptimierung sowie Abfragen und Jobs zusammen.

Speicher

Verwaltete Iceberg-Tabellen speichern alle Daten in Cloud Storage. Ihnen werden alle gespeicherten Daten in Rechnung gestellt, einschließlich der Verlaufsdaten der Tabelle. Möglicherweise fallen auch Gebühren für die Datenverarbeitung und die Datenübertragung in Cloud Storage an. Für einige Cloud Storage-Vorgänge, die über BigQuery oder die BigQuery Storage API verarbeitet werden, können die Gebühren erlassen werden. Es fallen keine BigQuery-spezifischen Speichergebühren an. Weitere Informationen finden Sie unter Cloud Storage – Preise.

Speicheroptimierung

Verwaltete Iceberg-Tabellen führen eine automatische Tabellenverwaltung durch, einschließlich Komprimierung, Clustering, automatische Speicherbereinigung und Generierung/Aktualisierung von BigQuery-Metadaten, um die Abfrageleistung zu optimieren und die Speicherkosten zu senken. Die Nutzung von Rechenressourcen für die Tabellenverwaltung wird im Laufe der Zeit in Data Compute Units (DCUs) im Sekundentakt abgerechnet. Weitere Informationen finden Sie unter Preise für verwaltete Iceberg-Tabellen.

Datenexportvorgänge, die während des Streamings über die Storage Write API stattfinden, sind in den Preisen für die Storage Write API enthalten und werden nicht als Hintergrundwartung in Rechnung gestellt. Weitere Informationen finden Sie unter Datenaufnahme – Preise.

Wenn Sie die Logs und die Computing-Nutzung für diese Hintergrundvorgänge aufrufen möchten, fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS ab. Beispielabfragen finden Sie hier:

Abfragen und Jobs

Ähnlich wie bei BigQuery-Tabellen werden Ihnen Abfragen und gelesene Byte (pro TiB) in Rechnung gestellt, wenn Sie die On-Demand-Preise von BigQuery verwenden, oder der Slot-Verbrauch (pro Slot-Stunde), wenn Sie die BigQuery-Kapazitäts-Computing-Preise verwenden.

Die BigQuery-Preise gelten auch für die BigQuery Storage Read API und die Storage Write API.

Für Lade- und Exportvorgänge (z. B. EXPORT METADATA) werden Pay-as-you-go-Slots der Enterprise-Version verwendet. Dies unterscheidet sich von BigQuery-Tabellen, für die diese Vorgänge nicht in Rechnung gestellt werden. Wenn PIPELINE-Reservierungen mit Enterprise- oder Enterprise Plus-Slots verfügbar sind, werden für Lade- und Exportvorgänge stattdessen diese Reservierungsslots verwendet.

Beschränkungen

Für verwaltete Iceberg-Tabellen gelten die folgenden Einschränkungen:

  • Für verwaltete Iceberg-Tabellen werden keine Umbenennungsvorgänge oder ALTER TABLE RENAME TO-Anweisungen unterstützt.
  • Für verwaltete Iceberg-Tabellen werden keine Tabellenkopien und keine CREATE TABLE COPY-Anweisungen unterstützt.
  • Für verwaltete Iceberg-Tabellen werden keine Tabellenklone oder CREATE TABLE CLONE-Anweisungen unterstützt.
  • Verwaltete Iceberg-Tabellen unterstützen keine Tabellen-Snapshots oder CREATE SNAPSHOT TABLE-Anweisungen.
  • Verwaltete Iceberg-Tabellen unterstützen das folgende Tabellenschema nicht:
  • Verwaltete Iceberg-Tabellen unterstützen die folgenden Schemaentwicklungsfälle nicht:
    • Typumwandlungen von NUMERIC in FLOAT
    • Typumwandlungen von INT in FLOAT
    • Neue verschachtelte Felder mithilfe von SQL-DDL-Anweisungen zu vorhandenen RECORD-Spalten hinzufügen
  • Für verwaltete Iceberg-Tabellen wird eine Speichergröße von 0 Byte angezeigt, wenn sie über die Console oder APIs abgefragt werden.
  • Von Iceberg verwaltete Tabellen unterstützen keine materialisierten Ansichten.
  • Verwaltete Iceberg-Tabellen unterstützen keine autorisierten Ansichten, aber die Zugriffssteuerung auf Spaltenebene wird unterstützt.
  • Verwaltete Iceberg-Tabellen unterstützen keine verwaltete Notfallwiederherstellung.
  • Verwaltete Iceberg-Tabellen unterstützen keine Sicherheit auf Zeilenebene.
  • Verwaltete Iceberg-Tabellen unterstützen keine ausfallsicheren Zeitfenster.
  • Verwaltete Iceberg-Tabellen unterstützen keine Extraktionsjobs.
  • Die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE enthält keine von Iceberg verwalteten Tabellen.
  • Verwaltete Iceberg-Tabellen werden nicht als Ziele für Abfrageergebnisse unterstützt. Sie können stattdessen die Anweisung CREATE TABLE mit dem Argument AS query_statement verwenden, um eine Tabelle als Ziel für das Abfrageergebnis zu erstellen.
  • CREATE OR REPLACE unterstützt nicht das Ersetzen von Standardtabellen durch verwaltete Iceberg-Tabellen oder von verwalteten Iceberg-Tabellen durch Standardtabellen.
  • Batch-Ladevorgänge und LOAD DATA-Anweisungen unterstützen nur das Anhängen von Daten an vorhandene verwaltete Iceberg-Tabellen.
  • Batchladevorgänge und LOAD DATA-Anweisungen unterstützen keine Schemaaktualisierungen.
  • TRUNCATE TABLE unterstützt keine verwalteten Iceberg-Tabellen. Dafür gibt es zwei Alternativen:
    • CREATE OR REPLACE TABLE, wobei dieselben Optionen für die Tabellenerstellung verwendet werden.
    • DELETE FROM table WHERE true
  • Die Tabellenwertfunktion (TVF) APPENDS unterstützt keine verwalteten Iceberg-Tabellen.
  • Iceberg-Metadaten enthalten möglicherweise keine Daten, die in den letzten 90 Minuten von der Storage Write API an BigQuery gestreamt wurden.
  • Der datensatzbasierte paginierte Zugriff mit tabledata.list unterstützt keine verwalteten Iceberg-Tabellen.
  • Für jede von Iceberg verwaltete Tabelle wird nur eine gleichzeitige mutierende DML-Anweisung (UPDATE, DELETE und MERGE) ausgeführt. Zusätzliche mutierende DML-Anweisungen werden in die Warteschlange gestellt.