Concepts du catalogue Apache Iceberg REST

Ce document présente le catalogue REST Apache Iceberg du metastore BigLake, y compris sa hiérarchie de ressources et les types de catalogues compatibles.

Le catalogue Apache Iceberg REST dans BigLake Metastore utilise une hiérarchie de ressources pour organiser vos données. Le tableau suivant offre une vue d'ensemble de ces ressources :

Hiérarchie des ressources

Ressource Description
Catalogue Un catalogue est un conteneur de premier niveau qui vous permet d'organiser les espaces de noms et les tables en groupes logiques en les divisant en différents catalogues.
Espace de noms Il s'agit d'un regroupement logique utilisé pour organiser les tables dans un catalogue. Il fonctionne comme des bases de données, des schémas ou des répertoires.
Table Les tables contiennent des définitions de lignes et de colonnes pouvant faire l'objet de requêtes.

Types de catalogues acceptés

Lorsque vous configurez votre client, vous spécifiez un emplacement d'entrepôt. Ce choix détermine le fonctionnement de votre catalogue et son intégration à d'autres services Google Cloud. Le tableau suivant décrit les types de catalogues compatibles :

Type de catalogue Description
Bucket Cloud Storage Toutes les données d'un catalogue sont stockées dans un seul bucket Cloud Storage. Si les données sont partagées entre plusieurs buckets, plusieurs catalogues sont nécessaires.
Fédération BigQuery Vous permet d'utiliser le catalogue REST Iceberg pour gérer et interroger les tables visibles par BigQuery. Pour en savoir plus, consultez Fédération de catalogues avec BigQuery.

Détails de l'entrepôt du catalogue

Recommandé

  • Entrepôt de buckets Cloud Storage (gs://) : il s'agit de l'approche standard, où le catalogue gère directement les métadonnées et les fichiers de données Iceberg dans un bucket Cloud Storage que vous spécifiez. Cette option vous permet de contrôler directement la mise en page de vos données et est compatible avec la distribution d'identifiants pour un contrôle des accès précis. Cela vous permet de créer et de gérer des tables BigLake pour Apache Iceberg.

    Par exemple, si vous avez créé votre bucket pour stocker votre catalogue et que vous l'avez nommé iceberg-bucket, le nom de votre catalogue et celui de votre bucket sont tous les deux iceberg-bucket. Vous l'utiliserez plus tard pour interroger votre catalogue dans BigQuery à l'aide de la syntaxe P.C.N.T. Par exemple : my-project.biglake-catalog-id.quickstart_namespace.quickstart_table.

Ancien

  • Fédération BigQuery (bq://) : cette approche vous permet d'utiliser le catalogue REST Iceberg pour gérer et interroger les tables visibles par BigQuery, sans avoir à créer de ressource de catalogue. Pour en savoir plus, consultez Fédération de catalogues avec BigQuery.

Structure de nommage des P.C.N.T

Lorsque vous interrogez des tables BigLake Metastore depuis BigQuery, vous utilisez une structure de nommage en quatre parties, souvent appelée P.C.N.T :

  • Projet : ID du projet Google Cloud propriétaire du catalogue.
  • Catalogue : nom du catalogue BigLake Metastore.
  • Namespace : espace de noms Iceberg (équivalent à un ensemble de données BigQuery).
  • Table : nom de la table.

Par exemple, my-project.biglake-catalog-id.my-namespace.my-table.

Fédération de catalogues avec BigQuery

Vous pouvez utiliser l'interface du catalogue REST Iceberg pour gérer et interroger les tables visibles par BigQuery. Les catalogues de fédération BigQuery ne vous obligent pas à créer une ressource de catalogue. Vous pouvez les utiliser dans n'importe quel projet pour lequel l'API BigQuery est activée. Cela vous permet :

Étant donné que ces ressources sont gérées par BigQuery, vous devez disposer des autorisations requises. La distribution d'identifiants n'est pas compatible avec les catalogues fédérés.

Pour activer la fédération, configurez votre client avec le format d'entrepôt bq://projects/PROJECT_ID dans le champ WAREHOUSE_PATH des exemples de configuration du client dans Utiliser le catalogue REST Iceberg. Vous pouvez également choisir d'inclure un emplacement BigQuery pour limiter les futures requêtes à un seul emplacement au format bq://projects/PROJECT_ID/locations/LOCATION.