Apache Iceberg-REST-Katalogendpunkt – Konzepte

Der Lakehouse-Laufzeitkatalog bietet eine zentrale Metadatenverwaltung für Google Cloud Lakehouse. In diesem Dokument werden die Kernkonzepte des Lakehouse-Laufzeitkatalogs beschrieben, wobei der Schwerpunkt auf dem Endpunkt Apache Iceberg REST-Katalogendpunkt , seiner Ressourcenhierarchie und anderen unterstützten Katalogtypen liegt.

Ressourcenhierarchie

Der Apache Iceberg REST-Katalogendpunkt verwendet eine Hierarchie von Ressourcen, um Ihre Daten zu organisieren. Die folgende Tabelle bietet einen allgemeinen Überblick über diese Ressourcen:

Ressource Beschreibung
Katalog Als Container der obersten Ebene können Sie mit einem Katalog Namespaces und Tabellen in logischen Gruppen organisieren, indem Sie sie in verschiedene Kataloge aufteilen.
Namespace Eine logische Gruppierung zum Organisieren von Tabellen in einem Katalog, die funktioniert wie Datenbanken, Schemas oder Verzeichnisse.
Tabelle Tabellen enthalten Definitionen von Zeilen und Spalten, die abgefragt werden können.

Unterstützte Katalogtypen

Wenn Sie Ihren Client konfigurieren, geben Sie einen Warehouse-Standort an. Diese Auswahl bestimmt, wie Ihr Katalog funktioniert und in andere Google Cloud Dienste eingebunden wird. In der folgenden Tabelle werden die unterstützten Katalogtypen beschrieben:

Katalogtyp Beschreibung
Cloud Storage-Bucket Alle Daten in einem Katalog werden in einem einzelnen Cloud Storage-Bucket gespeichert; für Daten, die in mehreren Buckets freigegeben werden, sind mehrere Kataloge erforderlich.
BigQuery-Katalogföderation Ermöglicht Ihnen, den Apache Iceberg REST-Katalogendpunkt zu verwenden, um Tabellen zu verwalten und abzufragen, die für BigQuery sichtbar sind. Weitere Informationen finden Sie unter Katalogföderation mit BigQuery.

Warehouse-Details

Empfohlen

  • Cloud Storage-Bucket-Warehouse (gs://): Dies ist der Standardansatz, bei dem der Katalog Apache Iceberg-Metadaten und ‑Datendateien direkt in einem von Ihnen angegebenen Cloud Storage-Bucket verwaltet. Mit dieser Option haben Sie die direkte Kontrolle über Ihr Datenlayout und unterstützen Credential Vending für eine detaillierte Zugriffssteuerung. So können Sie Lakehouse Iceberg REST-Katalogtabellen erstellen und verwalten.

    Wenn Sie beispielsweise einen Bucket zum Speichern Ihres Katalogs erstellt und ihn iceberg-bucket genannt haben, sind sowohl der Katalogname als auch der Bucketname iceberg-bucket. Dies wird später verwendet, wenn Sie Ihren Katalog in BigQuery mit der P.C.N.T-Syntax abfragen. Beispiel: my-project.lakehouse-catalog-id.quickstart_namespace.quickstart_table.

Alternative

  • BigQuery-Katalogföderation (bq://): Mit diesem Ansatz können Sie den Apache Iceberg REST-Katalogendpunkt verwenden, um Tabellen zu verwalten und abzufragen, die für BigQuery sichtbar sind, ohne eine Katalogressource erstellen zu müssen. Weitere Informationen finden Sie unter Katalogföderation mit BigQuery.

Bucket- und Katalogregionen

Bei Cloud Storage-Bucket-Warehouses im Lakehouse-Laufzeitkatalog wählt das System die Katalogregion so aus, dass sie der Region des zugrunde liegenden Buckets entspricht:

  • Buckets mit einer einzelnen Region: Die Katalogregion entspricht genau der Bucket-Region.

  • Buckets mit zwei Regionen: Umfasst vordefinierte und benutzerdefinierte Dual-Regionen, wie ASIA1 und NAM4. Die Katalogregion entspricht den Dual-Regionen.

  • Buckets mit mehreren Regionen: Das System wählt regionale Standorte für den Katalog innerhalb der geografischen Domain der Multiregion aus. Standardmäßig stimmen diese Standorte möglicherweise nicht mit gängigen BigQuery-Standorten wie US und EU überein. Stattdessen sind es regionale Standorte innerhalb der geografischen Domain (z. B. us-central1 und us-east4 für einen US-Multiregion-Bucket).

Wenn BigQuery eine Abfrage für Tabellen in diesen Katalogen ausführt, leitet BigQuery die Abfrage an die Region in der primären Region des Katalogs weiter. Wenn Sie eine Abfrage in einer bestimmten virtuellen Region (z. B. US oder EU) ausführen und die Katalogmetadaten nicht an diesem Standort vorhanden sind, kann die Abfrage fehlschlagen.

Primäre Regionen für US- und EU-Multiregionen angeben

Bei Katalogen, die einen US- oder EU-Multiregion-Bucket verwenden, können Sie beim Erstellen des Katalogs die primäre Region angeben, damit BigQuery von den entsprechenden Regionen aus darauf zugreifen kann.

  • Cloud Storage-Multiregion „EU“: Geben Sie EU oder europe-west4 an.
  • Cloud Storage-Multiregion „US“: Geben Sie US oder us-central1 an.

Das System wählt beim Erstellen des Katalogs ein primäres Replikat aus. Sie können es jedoch dynamisch aktualisieren, indem Sie FailoverCatalog aufrufen. Weitere Informationen zum Definieren primärer Standorte finden Sie unter Apache Iceberg REST-Katalogendpunkt verwenden.

Kataloge abfragen

Wenn Sie Tabellen des Lakehouse-Laufzeitkatalogs in BigQuery abfragen, verwenden Sie eine vierteilige Namensstruktur, die oft als P.C.N.T bezeichnet wird:

  • Projekt: Die Google Cloud Projekt-ID, zu der der Katalog gehört.
  • Catalog: Der Name des Lakehouse-Laufzeitkatalogs.
  • Namespace: Der Apache Iceberg-Namespace (entspricht einem BigQuery-Dataset).
  • Table: Der Name der Tabelle.

Beispiel: my-project.lakehouse-catalog-id.my-namespace.my-table.

Katalogföderation mit BigQuery

Sie können die Apache Iceberg REST-Katalogendpunkt-Schnittstelle verwenden, um Tabellen zu verwalten und abzufragen, die für BigQuery sichtbar sind.

Für BigQuery-Katalogföderationskataloge müssen Sie keine Katalogressource erstellen. Sie können in jedem Projekt verwendet werden, in dem die BigQuery API aktiviert ist. So können Sie:

Da diese Ressourcen von BigQuery verwaltet werden, müssen Sie die entsprechenden erforderlichen Berechtigungen haben. Credential Vending wird für föderierte Kataloge nicht unterstützt.

Um die Föderation zu aktivieren, konfigurieren Sie Ihren Client mit dem bq://projects/PROJECT_ID Warehouse-Format im Feld WAREHOUSE_PATH in den Clientkonfigurationsbeispielen unter Apache Iceberg REST-Katalogendpunkt verwenden. Sie können auch einen BigQuery-Standort angeben, um zukünftige Anfragen mit dem bq://projects/PROJECT_ID/locations/LOCATION Format auf einen einzelnen Standort zu beschränken.

Weitere Informationen