Apache Iceberg REST-Katalogkonzepte

Dieses Dokument bietet einen Überblick über den Apache Iceberg REST Catalog von BigLake Metastore, einschließlich der Ressourcenhierarchie und der unterstützten Katalogtypen.

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

Ressourcenhierarchie

Ressource Beschreibung
Katalog Mit dem Container der obersten Ebene, einem Katalog, können Sie Namespaces und Tabellen in logischen Gruppen organisieren, indem Sie sie in verschiedene Kataloge aufteilen.
Namespace Eine logische Gruppierung, die zum Organisieren von Tabellen in einem Katalog verwendet wird. Sie 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. Wenn Daten auf mehrere Buckets verteilt sind, sind mehrere Kataloge erforderlich.
BigQuery-Föderation Ermöglicht die Verwendung des Iceberg-REST-Katalogs zum Verwalten und Abfragen von Tabellen, die für BigQuery sichtbar sind. Weitere Informationen finden Sie unter Katalogföderation mit BigQuery.

Warehouse-Details für den Katalog

Empfohlen

  • Cloud Storage-Bucket-Warehouse (gs://): Bei diesem Standardansatz werden Iceberg-Metadaten und ‑Datendateien direkt vom Katalog 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 BigLake-Tabellen für Apache Iceberg erstellen und verwalten.

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

Legacy

  • BigQuery-Föderation (bq://): Mit diesem Ansatz können Sie den Iceberg REST-Katalog 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.

Namensstruktur für P.C.N.T.

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

  • Project: Die Google Cloud Projekt-ID des Projekts, zu dem der Katalog gehört.
  • Catalog: Der Name des BigLake Metastore-Katalogs.
  • Namespace: Der Iceberg-Namespace (entspricht einem BigQuery-Dataset).
  • Tabelle: Der Name der Tabelle.

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

Katalogföderation mit BigQuery

Sie können die Iceberg-REST-Katalogoberfläche verwenden, um Tabellen zu verwalten und abzufragen, die für BigQuery sichtbar sind. Für BigQuery-Föderationskataloge müssen Sie keine Katalogressource erstellen. Sie können in jedem Projekt verwendet werden, in dem die BigQuery API aktiviert ist. Damit können Sie:

Da diese Ressourcen von BigQuery verwaltet werden, benötigen Sie die entsprechenden erforderlichen Berechtigungen. Die Bereitstellung von Anmeldedaten wird für föderierte Kataloge nicht unterstützt.

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