Apache Iceberg-Tabellen

Von BigQuery 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 Cloud de Confiance by S3NS. Verwaltete Iceberg-Tabellen bieten dieselbe vollständig verwaltete Umgebung wie Standard-BigQuery-Tabellen, speichern Daten jedoch in kundeneigenen Speicher-Buckets. Verwaltete Iceberg-Tabellen unterstützen das offene Spark-Tabellenformat für eine bessere Interoperabilität mit Open-Source- und Drittanbieter-Compute-Engines für eine einzelne Datenkopie.

Verwaltete Iceberg-Tabellen unterstützen die folgenden Funktionen:

• Tabellenmutationen mit der Datenbearbeitungssprache (Data Manipulation Language, DML) von GoogleSQL.
• Einheitliches Batch-Streaming und Streaming mit hoher Durchsatzleistung mit der BigQuery Storage Write API über Connectors wie Spark, Dataflow und andere Engines.
• Spark V2-Snapshot-Export und automatisches Aktualisieren bei jeder Tabellenänderung für den direkten Abfragezugriff mit Open-Source- und Drittanbieter-Abfrage-Engines.
• Schemaentwicklung: Sie können Spalten hinzufügen, entfernen und umbenennen, um sie an Ihre Anforderungen anzupassen. Mit dieser Funktion können Sie auch den Datentyp einer vorhandenen Spalte und den Spaltenmodus ändern. Weitere Informationen finden Sie unter Regeln für die Typkonvertierung.
• Automatische Speicheroptimierung, einschließlich adaptiver Dateigrößenanpassung, automatischer Clusterbildung, automatischer Speicherbereinigung und Metadatenoptimierung.
• Zeitreisen für den Zugriff auf Verlaufsdaten in BigQuery.
• Sicherheit auf Spaltenebene und Datenmaskierung.
• Transaktionen mit mehreren Anweisungen (Vorschau)
• Tabellenpartitionierung (Vorabversion)
• Tabellenerstellung in Dataform-Workflows

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.

Für verwaltete Iceberg-Tabellen wird der Lakehouse-Laufzeitkatalog als einheitlicher Laufzeitkatalog für alle Spark-Daten verwendet. Der Lakehouse-Laufzeitkatalog bietet eine zentrale Quelle für die Verwaltung von Metadaten aus mehreren Engines und ermöglicht die Interoperabilität von Engines.

Die Verwendung von Apache 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 Datendateien im Bucket werden automatisch komprimiert und geclustert. 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 Spark-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:

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

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

• Wählen Sie einen Namen aus, der eindeutig angibt, dass der Bucket nur für verwaltete Iceberg-Tabellen vorgesehen ist.

• Wählen Sie Cloud Storage-Buckets mit einzelner 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. Um die Kosten für die Datenspeicherung zu optimieren, können Sie Autoclass aktivieren, um die Umstellungen 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 zu verhindern, dass Spark-Daten in Ihrem Cloud Storage-Bucket versehentlich gelöscht oder beschädigt werden, 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 mit Ausnahme der von Ihnen angegebenen Nutzer ablehnen.

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

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

• Behalten Sie die Standardrichtlinie für vorläufiges Löschen (7‑tägige Aufbewahrung) bei, um sich vor versehentlichem Löschen zu schützen. Wenn Sie jedoch feststellen, dass Spark-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:

  • Hierarchische Namespaces
  • Objekt-ACLs (Access Control Lists)
  • Vom Kunden bereitgestellte Verschlüsselungsschlüssel
  • Objektversionsverwaltung
  • Objektsperre
  • Bucket-Sperre
  • Vorläufig gelöschte Objekte mit der BigQuery API oder der bq-Befehlszeile wiederherstellen

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

Spark-Tabellen-Workflows

In den folgenden Abschnitten wird beschrieben, wie Sie 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:

• So erstellen Sie verwaltete Iceberg-Tabellen:
  • BigQuery-Dateninhaber (roles/bigquery.dataOwner) für Ihr Projekt
  • BigQuery-Verbindungsadministrator (roles/bigquery.connectionAdmin) für Ihr Projekt
• So fragen Sie verwaltete Iceberg-Tabellen ab:
  • BigQuery-Datenbetrachter (roles/bigquery.dataViewer) für Ihr Projekt
  • BigQuery-Nutzer (roles/bigquery.user) für Ihr Projekt
• Weisen Sie dem Dienstkonto der Verbindung die folgenden Rollen zu, damit es Daten in Cloud Storage lesen und schreiben kann:
  • Storage Object User (roles/storage.objectUser) für den Bucket
  • Leser von Legacy-Storage-Buckets (roles/storage.legacyBucketReader) für den Bucket

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:

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

Verwaltete Iceberg-Tabellen erstellen

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

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');

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

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

Daten in verwaltete Iceberg-Tabellen importieren

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

Standard-Ladevorgang für Daten aus Flatfiles

Bei verwalteten Iceberg-Tabellen werden externe Dateien mit BigQuery-Ladejobs in verwaltete Iceberg-Tabellen geladen. Wenn Sie bereits eine Spark-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 Spark-Tabelle verwendet werden, wird stattdessen eine BigQuery-Tabelle erstellt.

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

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

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

Standard-Ladevorgang aus Apache Hive-partitionierten Dateien

Sie können Apache Hive-partitionierte Dateien mit standardmäßigen BigQuery-Ladejobs in Managed Iceberg-Tabellen laden. Weitere Informationen finden Sie unter Extern partitionierte Daten laden.

Streamingdaten aus Pub/Sub laden

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

Daten aus verwalteten Iceberg-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 Spark-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.

Snapshots von Spark-Tabellenmetadaten erstellen

So erstellen Sie einen Snapshot der Spark-Tabellenmetadaten:

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

2. Optional: Aktualisierung von Spark-Metadaten-Snapshots planen. Wenn Sie einen Spark-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 Spark-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. Bei jeder Aktualisierung 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 Spark-Tabellenmetadaten ansehen

Nachdem Sie den Spark-Tabellenmetadaten-Snapshot aktualisiert haben, finden Sie ihn im Cloud Storage-URI, in dem die Spark-Tabelle ursprünglich erstellt wurde. Der Ordner /data enthält die Parquet-Datei-Shards und der Ordner /metadata den Spark-Tabellen-Metadaten-Snapshot.

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 Spark-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 Version der Spark-Laufzeit. Laden Sie die aktuelle Version von Spark Releases herunter.
• CATALOG_NAME: Der Katalog, der auf Ihre Spark-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 Spark-Tabelle ändern möchten, folgen Sie der Anleitung unter Tabellenschemas ändern.

Transaktionen mit mehreren Anweisungen verwenden

Wenn Sie Zugriff auf Transaktionen mit mehreren Anweisungen für verwaltete Iceberg-Tabellen erhalten möchten, füllen Sie das Anmeldeformular aus.

Partitionierung verwenden

Wenn Sie auf die Partitionierung für Apache Iceberg-Tabellen zugreifen möchten, füllen Sie das Anmeldeformular aus.

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 Spalte vom Typ DATE, DATETIME oder TIMESTAMP wird als Spaltenpartitionierung nach Zeiteinheit bezeichnet. Sie können auswählen, ob die Partitionen stündlich, täglich, monatlich oder jährlich sein sollen.

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

Einschränkungen bei der Partitionierung

• Es gelten alle Einschränkungen für partitionierte BigQuery-Tabellen.
• Andere Partitionierungsspaltentypen als DATE, DATETIME oder TIMESTAMP werden nicht unterstützt.
• Der Ablauf von Partitionen wird nicht unterstützt.
• Partitionsentwicklung wird nicht unterstützt.

Partitionierte Spark-Tabelle erstellen

Wenn Sie eine partitionierte Spark-Tabelle erstellen möchten, folgen Sie der Anleitung zum Erstellen einer Standard-Spark-Tabelle und fügen Sie je nach Umgebung Folgendes ein:

• Die PARTITION BY-Klausel
• Die Flags --time_partitioning_field und --time_partitioning_type
• Das Attribut timePartitioning

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 Standard-Spark-Tabellen. BigQuery beschränkt den Job automatisch auf die richtigen Partitionen, ähnlich wie bei der verborgenen Partitionierung in Spark. 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 abfragen, genau wie standardmäßige verwaltete Iceberg-Tabellen. Wir empfehlen, Metadaten-Snapshots zu aktivieren, um die bestmögliche Leistung zu erzielen.

Zur Erhöhung der Sicherheit werden Partitionierungsinformationen für verwaltete Iceberg-Tabellen vom Datenpfad entkoppelt und vollständig von der Metadatenebene verwaltet.

Preise

Die Preise für Spark-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 Datenübertragung von 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 Verdichtung, 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) und in Sekundenschritten abgerechnet. Weitere Informationen finden Sie unter Preise für Apache 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:

• Speicheroptimierungsjobs
• EXPORT TABLE METADATA jobs

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ä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. 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:

• Verwaltete Iceberg-Tabellen unterstützen keine Umbenennungsvorgänge oder ALTER TABLE RENAME TO-Anweisungen.
  • Von Google verwaltete Iceberg-Tabellen unterstützen keine Tabellenkopien oder CREATE TABLE COPY-Anweisungen.
    • Von Google verwaltete Iceberg-Tabellen unterstützen keine Tabellenklone oder CREATE TABLE CLONE-Anweisungen.
      • Von Google verwaltete Iceberg-Tabellen unterstützen keine Tabellen-Snapshots oder CREATE SNAPSHOT TABLE-Anweisungen.
        • Verwaltete Iceberg-Tabellen unterstützen das folgende Tabellenschema nicht:
• Leeres Schema
  • Schema mit den Datentypen BIGNUMERIC, INTERVAL, JSON, RANGE oder GEOGRAPHY.
  • Schema mit Feldkollationen.
    • Schema mit Ausdrücken für Standardwerte.
• Verwaltete Iceberg-Tabellen unterstützen die folgenden Fälle der Schemaentwicklung nicht:
  • NUMERIC-zu-FLOAT-Typkoersionen
  • INT-zu-FLOAT-Typkoersionen
  • Neue verschachtelte Felder in vorhandene RECORD-Spalten einfügen
• Für verwaltete Iceberg-Tabellen wird eine Speichergröße von 0 Byte angezeigt, wenn sie über die Console oder APIs abgefragt werden.
• Von BigQuery verwaltete Iceberg-Tabellen unterstützen keine materialisierten Ansichten.
• Verwaltete Iceberg-Tabellen unterstützen keine autorisierten Ansichten, aber Zugriffssteuerung auf Spaltenebene wird unterstützt.
• Für verwaltete Iceberg-Tabellen werden keine Change Data Capture (CDC)-Updates unterstützt.
• Verwaltete Iceberg-Tabellen unterstützen keine verwaltete Notfallwiederherstellung.
• Verwaltete Iceberg-Tabellen unterstützen keine Sicherheit auf Zeilenebene.
• Von Google verwaltete Iceberg-Tabellen unterstützen keine Fail-Safe-Zeiträume.
• Für verwaltete Iceberg-Tabellen werden keine Extrahierungsjobs unterstützt.
• Die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE enthält keine Spark-Tabellen.
• Verwaltete Iceberg-Tabellen werden nicht als Ziel für Abfrageergebnisse unterstützt. Stattdessen können Sie 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 Apache Iceberg-Tabellen oder von verwalteten Iceberg-Tabellen durch Standardtabellen.
• Beim Batchladen und bei LOAD DATA-Anweisungen können Daten nur an vorhandene verwaltete Iceberg-Tabellen angehängt werden.
• Batch-Ladevorgä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 mit denselben Optionen zum Erstellen von Tabellen.
  • DELETE FROM table WHERE true
• Die Tabellenwertfunktion (Table-valued function, TVF) APPENDS unterstützt keine verwalteten Iceberg-Tabellen.
• Spark-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 Apache Iceberg-Tabellen nicht unterstützt.
• Für jede Spark-Tabelle wird nur eine gleichzeitige mutierende DML-Anweisung (UPDATE, DELETE und MERGE) ausgeführt. Zusätzliche mutierende DML-Anweisungen werden in die Warteschlange gestellt.