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 aber in vom Kunden verwalteten Speicher-Buckets. Verwaltete Iceberg-Tabellen unterstützen das offene Iceberg-Tabellenformat für eine bessere Interoperabilität mit Open-Source- und Drittanbieter-Compute-Engines für eine einzelne Datenkopie.

Iceberg-Tabellen, die von Dataproc Metastore verwaltet werden, 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 verwalteten 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 Hintergrundoptimierungen des Speichers, z. B. DML-Anweisungen und Streaming.
  • Die Daten werden in den Dateien im Bucket automatisch komprimiert und gruppiert. Nach Ablauf des Zeitreisefensters werden Datendateien gelöscht. Wenn die Tabelle gelöscht wird, werden die zugehörigen Datendateien jedoch nicht automatisch gelöscht. Weitere Informationen finden Sie unter Speicher optimieren.

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 als PARQUET mit der Anweisung file_format = PARQUET an.
  • Geben Sie das Format der Open-Source-Metadatentabelle als ICEBERG mit der table_format = ICEBERG-Anweisung an.

Best Practices

Wenn Sie Dateien direkt im Bucket außerhalb von BigQuery ändern oder hinzufügen, kann dies zu Datenverlust oder nicht behebaren 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 bereinigt werden.
Um versehentliche Ergänzungen und Datenverluste zu vermeiden, empfehlen wir außerdem, die Schreibberechtigungen für externe Tools für Buckets mit verwalteten Iceberg-Tabellen einzuschränken.
Erstellen Sie eine neue verwaltete Iceberg-Tabelle in einem nicht leeren Präfix. Datenverlust:Vorhandene Daten werden nicht von BigQuery erfasst. Diese Dateien gelten daher als nicht erfasst und werden durch Hintergrundprozesse zur automatischen Speicherbereinigung gelöscht. Erstellen Sie neue verwaltete Iceberg-Tabellen nur in leeren Präfixen.
Datendateien für verwaltete Iceberg-Tabellen ändern oder ersetzen Datenverlust:Bei externer Änderung oder beim Austausch besteht die Tabelle die Konsistenzprüfung nicht und wird unlesbar. Abfragen für die Tabelle schlagen fehl.
Es gibt keine Selfservice-Methode, um die Daten ab diesem Punkt wiederherzustellen. 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 bereinigt werden.
Um versehentliche Ergänzungen und Datenverluste zu vermeiden, empfehlen wir außerdem, die Schreibberechtigungen für externe Tools für Buckets mit verwalteten Iceberg-Tabellen einzuschränken.
Erstellen Sie zwei verwaltete Iceberg-Tabellen mit denselben oder sich überschneidenden URIs. Datenverlust:BigQuery überbrückt keine identischen URI-Instanzen von Iceberg-verwalteten Tabellen. Bei der automatischen Speicherbereinigung für jede Tabelle werden die Dateien der anderen Tabelle als nicht verfolgt betrachtet und gelöscht, was zu Datenverlust führt. Verwenden Sie eindeutige URIs für jede von Iceberg verwaltete Tabelle.

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

Die Konfiguration Ihres Cloud Storage-Bucket und seine Verbindung mit BigQuery haben einen direkten Einfluss 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 Iceberg-verwaltete Tabellen vorgesehen ist.

  • Wählen Sie Cloud Storage-Buckets mit einzelner Region aus, die sich in derselben Region wie Ihr BigQuery-Dataset befinden. Durch diese Koordination wird die Leistung verbessert und die Kosten gesenkt, 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. Um die Datenspeicherkosten zu optimieren, können Sie Autoclass aktivieren, um die Umstellung der Speicherklasse automatisch zu verwalten. Autoclass beginnt mit der Speicherklasse „Standard Storage“ und verschiebt Objekte, auf die nicht zugegriffen wird, in immer niedrigere Klassen, um die Speicherkosten zu senken. Wenn das Objekt wieder gelesen wird, wird es zurück in die Standard-Klasse 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 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 außer den von Ihnen angegebenen ablehnen.

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

  • Aktivieren Sie Audit-Logging für betriebliche Transparenz, Fehlerbehebung und Überwachung des Datenzugriffs.

  • Behalten Sie die Standard-Richtlinie für vorläufiges Löschen (Aufbewahrung für 7 Tage) 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. Objekte, die außerhalb von BigQuery hinzugefügt oder geändert werden, werden nicht von BigQuery-Metadaten erfasst.

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

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

Sie können diese Best Practices umsetzen, 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 Ihren neuen Bucket

Workflows für verwaltete Iceberg-Tabellen

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

Hinweis

Bevor Sie verwaltete Iceberg-Tabellen erstellen und verwenden, müssen Sie eine Cloud-Ressourcenverbindung zu einem Speicher-Bucket einrichten. Ihre Verbindung benötigt Schreibberechtigungen für den Speicher-Bucket, wie im folgenden Abschnitt Erforderliche Rollen beschrieben. 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, 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 vom Befehl das Standardprojekt angenommen.
  • 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. Sie müssen Spalten der obersten Ebene sein, die nicht wiederholt werden.
  • CONNECTION_NAME: der Name der Verbindung. Beispiel: myproject.us.myconnection Wenn Sie eine Standardverbindung verwenden möchten, geben Sie DEFAULT anstelle des Verbindungsnamens 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 vom Befehl das Standardprojekt angenommen.
  • 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 Informationen in der Spalte.
  • CLUSTER_COLUMN_LIST (optional): Eine durch Kommas getrennte Liste mit bis zu vier Spalten. Sie müssen Spalten der obersten Ebene sein, 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, 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 Informationen in der Spalte.

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

Für verwaltete Iceberg-Tabellen werden BigQuery-Ladejobs verwendet, 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 Anweisungen ohne eine vorhandene von Iceberg verwaltete Tabelle verwendet werden, wird stattdessen eine BigQuery-Tabelle erstellt.

Toolspezifische Beispiele für Batch-Ladevorgänge in von Iceberg verwaltete Tabellen finden Sie hier:

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 voll qualifizierter Cloud Storage-URI oder eine durch Kommas getrennte Liste von URIs. Platzhalter werden ebenfalls unterstützt. Beispiel: gs://mybucket/table
  • FILE_FORMAT: das Format der Quelltabelle. 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 standardmäßigen BigQuery-Ladejobs in verwaltete Iceberg-Tabellen laden. Weitere Informationen finden Sie unter Extern partitionierte Daten laden.

Streamingdaten aus Pub/Sub laden

Sie können Streamingdaten in von Iceberg verwaltete Tabellen laden, indem Sie ein Pub/Sub-BigQuery-Abo verwenden.

Streamingdaten mit kontinuierlichen Abfragen laden

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

Bevor Sie die kontinuierliche Abfrage ausführen, müssen Sie dafür sorgen, dass die verwaltete Iceberg-Zieltabelle vorhanden ist und 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 von Iceberg verwalteten 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 EXPORT DATA-Anweisung 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 für eine von Iceberg verwaltete Tabelle:

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

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

  3. Optional: Aktivieren Sie die automatische Aktualisierung von Metadaten für Ihr Projekt, um den Metadaten-Snapshot Ihrer Iceberg-Tabelle bei jeder Tabellenänderung automatisch zu aktualisieren. Wenn Sie die automatische Aktualisierung von Metadaten aktivieren möchten, wenden Sie sich an bigquery-tables-for-apache-iceberg-help@google.com. Für jeden 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'

Metadaten-Snapshot 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 verwalteten Iceberg-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 und dann 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 mit den Tabellendateien. 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 genauso verwenden wie mit Standard-BigQuery-Tabellen. Transaktionen mit mehreren Anweisungen werden häufig verwendet, um Mutationen gleichzeitig an mehreren Tabellen oder in mehreren Phasen an einer einzelnen Tabelle vorzunehmen. 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 Tabellenpartitionierung mit von Iceberg verwalteten Tabellen ähnlich wie mit Standard-BigQuery-Tabellen 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

Das Partitionieren einer Tabelle anhand 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 sein sollen.

Von Iceberg verwaltete Tabellen unterstützen auch Clustering und das Kombinieren von geclusterten und partitionierten Tabellen.

Einschränkungen bei der Partitionierung

Partitionierte, von Iceberg verwaltete 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 Folgendes ein:

Sie können die Ablaufzeit von Partitionen auf dieselbe Weise festlegen und aktualisieren wie bei Standard-BigQuery-Tabellen. Abgelaufene Partitionen werden nach dem Zeitstempelfenster bereinigt. Wenn Sie einer abgelaufenen Partition Daten hinzufügen, laufen die Daten sofort ab.

Partitionierte verwaltete Iceberg-Tabellen ändern und abfragen

BigQuery-DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) und ‑Abfragen für partitionierte verwaltete Iceberg-Tabellen sind dieselben wie für verwaltete Iceberg-Standardtabellen. BigQuery beschränkt den Job automatisch auf die richtigen Partitionen, ähnlich wie bei der verborgenen Iceberg-Partitionierung. 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 bestmögliche Leistung zu erzielen.

Zur Verbesserung der Sicherheit werden Partitionierungsinformationen für von Iceberg verwaltete 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

In verwalteten Iceberg-Tabellen werden alle Daten in Cloud Storage gespeichert. Ihnen werden alle gespeicherten Daten in Rechnung gestellt, einschließlich der Daten aus dem Tabellenverlauf. Es können auch Gebühren für die Datenverarbeitung und Übertragungsgebühren für Cloud Storage anfallen. Einige Gebühren für Cloud Storage-Vorgänge werden möglicherweise für Vorgänge erlassen, die über BigQuery oder die BigQuery Storage API verarbeitet werden. Es fallen keine BigQuery-spezifischen Speichergebühren an. Weitere Informationen finden Sie unter Cloud Storage – Preise.

Speicheroptimierung

Bei verwalteten Iceberg-Tabellen erfolgt die automatische Tabellenverwaltung, 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 Zeitverlauf 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 der Preisgestaltung der Storage Write API enthalten und werden nicht als Hintergrundwartung in Rechnung gestellt. Weitere Informationen finden Sie unter Preise für die Datenaufnahme.

Wenn Sie die Logs und die Compute-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 BigQuery On-Demand-Preise verwenden, oder der Slot-Verbrauch (pro Slotstunde), wenn Sie die BigQuery-Kapazitätspreise 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. Das 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 diese Reservierungsslots bevorzugt für Lade- und Exportvorgänge 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 von Iceberg verwaltete Tabellen werden keine Tabellenkopien oder CREATE TABLE COPY-Anweisungen unterstützt.
  • Von Iceberg verwaltete Tabellen unterstützen keine Tabellenklone oder CREATE TABLE CLONE-Anweisungen.
  • Für verwaltete Iceberg-Tabellen werden keine Tabellensnapshots oder CREATE SNAPSHOT TABLE-Anweisungen unterstützt.
  • Die folgenden Tabellenschemas werden für verwaltete Iceberg-Tabellen nicht unterstützt:
  • Für verwaltete Iceberg-Tabellen werden die folgenden Fälle der Schemaentwicklung nicht unterstützt:
    • NUMERIC-zu-FLOAT-Typkoersionen
    • INT-zu-FLOAT-Typkoersionen
    • Neue verschachtelte Felder in vorhandene RECORD-Spalten mit SQL-DDL-Anweisungen einfügen
  • Für verwaltete Iceberg-Tabellen wird eine Speichergröße von 0 Byte angezeigt, wenn sie über die Console oder APIs abgefragt werden.
  • Für von Iceberg verwaltete Tabellen werden keine materialisierten Ansichten unterstützt.
  • Für verwaltete Iceberg-Tabellen werden keine autorisierten Ansichten unterstützt, aber Zugriffssteuerung auf Spaltenebene.
  • Verwaltete Notfallwiederherstellung wird für verwaltete Iceberg-Tabellen nicht unterstützt.
  • Für von Iceberg verwaltete Tabellen wird keine Sicherheit auf Zeilenebene unterstützt.
  • Verwaltete Iceberg-Tabellen unterstützen keine Fail-Safe-Zeiträume.
  • Für von Iceberg verwaltete Tabellen werden keine Extraktionsjobs unterstützt.
  • Die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE enthält keine von Iceberg verwalteten Tabellen.
  • Verwaltete Iceberg-Tabellen werden nicht als Ziel für Abfrageergebnisse unterstützt. Stattdessen können Sie die CREATE TABLE-Anweisung mit dem Argument AS query_statement verwenden, um eine Tabelle als Ziel des Abfrageergebnisses zu erstellen.
  • CREATE OR REPLACE unterstützt nicht das Ersetzen von Standardtabellen durch von Iceberg verwaltete Tabellen oder von von Iceberg verwalteten Tabellen durch Standardtabellen.
  • Beim Batch-Laden und bei LOAD DATA-Anweisungen wird nur das Anhängen von Daten an vorhandene verwaltete Iceberg-Tabellen unterstützt.
  • Batch-Laden und LOAD DATA-Anweisungen unterstützen keine Schemaaktualisierungen.
  • TRUNCATE TABLE unterstützt keine von Iceberg verwalteten Tabellen. Dafür gibt es zwei Alternativen:
  • Die Tabellenwertfunktion (TVF) APPENDS unterstützt keine von Iceberg verwalteten Tabellen.
  • Iceberg-Metadaten enthalten möglicherweise keine Daten, die in den letzten 90 Minuten mit der Storage Write API in BigQuery gestreamt wurden.
  • Der seitenweise Zugriff auf Datensätze mit tabledata.list wird für von Iceberg verwaltete Tabellen nicht unterstützt.
  • 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.