BigQuery-Tabellen über den Apache Iceberg REST-Katalogendpunkt abfragen

Lakehouse bietet Interoperabilität mit BigQuery, indem Anfragen über den Apache Iceberg REST-Katalogendpunkt an den BigQuery-Katalog weitergeleitet werden. Mit dieser Funktion können Sie von BigQuery verwaltete Tabellen, z. B. von Iceberg verwaltete Tabellen, für externe Open-Source-Engines (OSS) wie Apache Spark und Trino freigeben.

Anstatt einen dedizierten Lakehouse-Katalogcontainer zum Speichern von Metadaten zu erstellen, fungiert der Apache Iceberg REST-Katalogendpunkt nur als Proxy-Gateway. Wenn externe Engines eine Verbindung mit dem Warehouse-Präfix bq:// herstellen, leitet das Gateway ihre Kataloganfragen direkt an den internen Katalog von BigQuery weiter. So können Sie Tabellen direkt in BigQuery mit Standard-BigQuery-DDL oder ‑APIs erstellen und verwalten und gleichzeitig externen OSS-Engines Lesezugriff gewähren, um diese Tabellen über den REST-Katalogendpunkt abzufragen.

So funktioniert das Abfragen von BigQuery-Tabellen über den REST-Katalogendpunkt

Wenn Sie Anfragen an den BigQuery-Katalog weiterleiten, können Sie BigQuery-Tabellen wie verwaltete Iceberg-Tabellen und BigQuery-Metastore-Tabellen über den Apache Iceberg REST-Katalogendpunkt des Lakehouse-Laufzeitkatalogs verfügbar machen.

Der Workflow funktioniert so:

  1. Tabelle im BigQuery-Katalog erstellen: Sie erstellen eine verwaltete Iceberg-Tabelle in BigQuery mit DDL-Anweisungen. Diese Tabelle ist im BigQuery-Katalog vorhanden, unterliegt BigQuery-Zugriffssteuerungslisten (ACLs) und fungiert als BigQuery-REST-Ressource.
  2. Aus dem Lakehouse-Laufzeitkatalog in das BigQuery-Warehouse föderieren: Mit der Apache Iceberg REST API des Lakehouse-Laufzeitkatalogs föderieren Sie in ein Warehouse, das durch das Warehouse-Pfadformat bq://projects/PROJECT_ID (oder die regionale Version bq://projects/PROJECT_ID/locations/LOCATION) angegeben ist. So können Sie über die Apache Iceberg REST Catalog API von Compute-Engines wie Apache Spark auf die BigQuery-Tabelle zugreifen. In dieser Konfiguration haben Sie in Spark nur Lesezugriff, in BigQuery aber Lese- und Schreibzugriff.

Hinweise

  • Da beim Weiterleiten von Anfragen an den BigQuery-Katalog keine dedizierte Lakehouse-Katalogressource erstellt wird, gelten andere Konzepte und Konfigurationen auf Katalogebene, z. B. die Ressourcenhierarchie, Bucket- und Katalogregionen sowie die vierteilige P.C.N.T-Namensstruktur, nicht für diese Methode. In der zugrunde liegenden API entspricht dies der CATALOG_TYPE_BIGQUERY-Konfiguration. Die Delegierung des Speicherzugriffs (Credential Vending) wird nicht unterstützt, wenn Anfragen an den BigQuery-Katalog weitergeleitet werden.

  • Das Bereitstellen von BigQuery-Tabellen über den REST-Katalogendpunkt unterscheidet sich vom Zugriff auf cloudübergreifende Daten. Während dieser Workflow Google Cloud-Tabellen für externe OSS-Engines verfügbar macht, verbindet Lakehouse Google Cloud mit Remote-Katalogen wie Databricks Unity Catalog, um Daten, die bei anderen Cloud-Anbietern gespeichert sind, direkt aus BigQuery und OSS-Engines abzufragen, ohne Daten migrieren zu müssen. Weitere Informationen zu diesem Workflow finden Sie unter Cloudübergreifender Datenzugriff.

Vergleich mit Tabellen, die vom Apache Iceberg REST-Katalogendpunkt verwaltet werden

Das Bereitstellen von BigQuery-Tabellen über den REST-Katalogendpunkt unterscheidet sich von Workflows, bei denen der Lakehouse-Laufzeitkatalog den Apache Iceberg REST-Katalogendpunkt verwendet, in folgenden Punkten:

  • Ressourcenverwaltung und Katalogspeicher: Tabellen im BigQuery-Katalog befinden sich dort als BigQuery-REST-Ressourcen und der Lakehouse-Laufzeitkatalog fungiert als Proxy-Gateway. Wenn der Lakehouse-Laufzeitkatalog den Apache Iceberg REST-Katalogendpunkt verwendet, um Tabellen direkt zu verwalten, werden diese Tabellen als Lakehouse REST-Ressourcen gespeichert.
  • Zugriffssteuerung: Für Tabellen im BigQuery-Katalog werden BigQuery-IAM-Berechtigungen und Zugriffssteuerungslisten (ACLs) verwendet. Tabellen, die direkt im Lakehouse-Laufzeitkatalog verwaltet werden, verwenden Lakehouse-ACLs.
  • Lese- und Schreibfunktionen der Engine: Iceberg-verwaltete Tabellen bieten Lese- und Schreibzugriff über BigQuery und schreibgeschützten Zugriff von externen Engines wie Spark. Tabellen, die direkt im Lakehouse-Laufzeitkatalog über den Apache Iceberg REST-Katalogendpunkt verwaltet werden, unterstützen Lese- und Schreibvorgänge sowohl von BigQuery als auch von externen Engines wie Spark.

Hinweis

  1. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud -Projekt aktiviert ist.

  2. Aktivieren Sie die BigLake API, falls sie noch nicht aktiviert ist.

    Erforderliche Rollen zum Aktivieren von APIs

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Inhaberrolle (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

    API aktivieren

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Abfragen von BigQuery-Tabellen über den Apache Iceberg REST-Katalogendpunkt benötigen:

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

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Wenn Sie externe Abfrage-Engines wie Managed Service for Apache Spark verwenden, um Namespaces zu erstellen oder Tabellen zu ändern, die von externen Engines erstellt wurden, weisen Sie diese Rollen dem Dienstkonto zu, das Jobs in dieser Engine ausführt. (Von Iceberg verwaltete Tabellen sind von externen Engines aus schreibgeschützt.)

Client für das BigQuery-Warehouse konfigurieren

Wenn Sie eine Verbindung zum BigQuery-Warehouse herstellen möchten, konfigurieren Sie Ihren Client (z. B. Apache Spark oder Trino) mit dem Warehouse-Format bq://projects/PROJECT_ID im Feld WAREHOUSE_PATH in den Beispielen für die Clientkonfiguration unter Clientanwendung konfigurieren.

Sie können auch einen BigQuery-Standort angeben, um zukünftige Anfragen auf einen einzelnen Standort im Format bq://projects/PROJECT_ID/locations/LOCATION zu beschränken.

Da diese Ressourcen von BigQuery verwaltet werden, benötigen Sie die entsprechenden erforderlichen Berechtigungen.

Namespaces im BigQuery-Warehouse erstellen

Nachdem Sie den Client konfiguriert haben, können Sie einen Namespace für Ihre Tabellen erstellen.

Spark

Wenn Sie einen Namespace im BigQuery-Warehouse erstellen möchten, fügen Sie die Klauseln LOCATION und DBPROPERTIES ein:

spark.sql("CREATE NAMESPACE IF NOT EXISTS NAMESPACE_NAME LOCATION 'gs://BUCKET_NAME/NAMESPACE_NAME' WITH DBPROPERTIES ('gcp-region' = 'LOCATION');")
spark.sql("USE NAMESPACE_NAME;")

Ersetzen Sie Folgendes:

  • NAMESPACE_NAME: ein Name für Ihren Namespace.
  • BUCKET_NAME: der Cloud Storage-Bucket, den Sie mit Ihrem Katalog verwenden.
  • LOCATION: Ein BigQuery-Standort. Der Standardwert ist der multiregionale Standort US.

Trino

Wenn Sie ein Schema im BigQuery-Warehouse erstellen möchten, fügen Sie die Attribute LOCATION und gcp-region ein:

CREATE SCHEMA IF NOT EXISTS  CATALOG_NAME.SCHEMA_NAME WITH ( LOCATION = 'gs://BUCKET_NAME/SCHEMA_NAME', "gcp-region" = 'LOCATION');
USE CATALOG_NAME.SCHEMA_NAME;

Ersetzen Sie Folgendes:

  • CATALOG_NAME: der Name Ihres Trino-Katalogs, der den Apache Iceberg REST-Katalogendpunkt verwendet.
  • SCHEMA_NAME: ein Name für Ihr Schema.
  • BUCKET_NAME: der Cloud Storage-Bucket, den Sie mit Ihrem Katalog verwenden.
  • LOCATION: Ein BigQuery-Standort. Der Standardwert ist der multiregionale Standort US.

Tabellen in BigQuery abfragen

Tabellen, die Sie im BigQuery-Warehouse erstellen, sind in BigQuery sichtbar und können direkt mit Standard-BigQuery-SQL abgefragt werden (ohne dass ein vierteiliger P.C.N.T-Name erforderlich ist):

SELECT * FROM `NAMESPACE_NAME.TABLE_NAME`;

Ersetzen Sie Folgendes:

  • NAMESPACE_NAME: Der Name Ihres Namespace.
  • TABLE_NAME: der Name der Tabelle.

Nächste Schritte